FAQ

FAQ

How do I recover from timeline X of the primary does not match recovery target timeline Y on the slave?

There are plenty of posts about this on the PostgreSQL mailing list, and the only way to recover from this is to resync the slave with the master. Luckily that's pretty easy now with our system up and running. All you need to do on the slave is to run: pg_ha.sh init-slave

Will this work with Django?

Unfortunately we had to disable the load-balancing (set 'load_balance_mode = false') on our production deployment of Django. Turns out the delay between the master and slave was significante enough to cause havoc with session keys. Maybe there's a workaround for this, but I'm yet to find it. In theory the solution would be to force time-sensitive queries, like the session table, to be read from the master.

What's a good 'advbase'-value?

First, let's start with what advbase is. According this article, advbase is simply the frequency (in seconds) of how often broadcasts will be sent out to determine the master. A slave will step up if it fails to receive notifications from the master 3*advbase (ie. if the value is set to 20 sec, that would be 60 seconds).

I started out with a value of 2 seconds as the advbase. That seemed to work at first, but eventually I ran into trouble with this. That would probably have been a good value for dedicated hardware, but not for a cloud deployment. I've now increased this to 20, but I don't think there's a magic number. This simply depends on your setup.