We had our Streaming Rep Lab followup last night1. It was mostly successful: half of the new people got it up & running, and the people who’d been at the previous workshop got to experiment with almost everything on the agenda.
The cheatsheet is up on our git repo: https://github.com/pdxpug/cheatsheets 2.
We talked a bit about monitoring and messed around with some of the available functions (e.g. pg_last_xact_replay_timestamp), started looking at pg_xlogdump (for “educational purposes”, of course), checked out a packet capture between the master & standby, and finished up with breaking the link between the master & the standby: the standby cried a bit about not being able to reach the master, but as soon as we restored the link, everything was fine.
The overarching theme of the evening is that we need to come up with a more robust plot to make Postgres fail in an interesting way.
SELECT pg_last_xact_replay_timestamp(); will give you a WAL ID, but is only valid on a standby.
The function to translate it to a file name:
SELECT pg_xlogfile_name([id]); can only be run on the master. So that’s kinda weird and requires some puzzling out.
I started a wiki page of ideas for future labs, but we may be hung up on streaming rep & breaking it for a little while :)
Thanks to Emma for hosting & providing dinner!
1 – With a puppy.
2 – Yes, I know there is something wrong with the step numbering. It renders correctly in github’s md validator, but not when I upload it.