Re: Multiple Slave Failover with PITR
Ken Brush <kbrush@gmail.com>
From: Ken Brush <kbrush@gmail.com>
To: Sergey Konoplev <gray.ru@gmail.com>
Cc: pgsql-general@postgresql.org
Date: 2012-04-11T16:12:00Z
Lists: pgsql-hackers, pgsql-general
On Wed, Apr 11, 2012 at 9:03 AM, Sergey Konoplev <gray.ru@gmail.com> wrote: > On Wed, Mar 28, 2012 at 11:35 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: >>> 1. Master dies :( >>> 2. Touch the trigger file on the most caught up slave > > If the master was stopped properly will the slaves be in sync to each other? I don't think you can guarantee that. Hence why you pick the most caught up slave, it will catch the other slaves up to it's state, once it becomes the master. >>> 3. Slave is now the new master. >>> 4. On the other slaves do the following: >>> 5. Shutdown postgres on the slave >>> 6. Delete every file in /data/pgsql/data/pg_xlog >>> 7. Modify the recovery.conf file to point to the new master and >>> include the line "recovery_target_timeline='latest'" >>> 8. Copy the history file from the new master to the slave (it's the >>> most recent #.history file in the xlog directory) > > It will work in the case of archive_command presence only and I will > need to sync the whole pg_xlog content if do not have archive_command > in recovery.conf, correct? The new master will sync out the WAL logs from pg_xlog that the slaves need. The wal sender/receiver system is what I rely on for this. Sincerely, -Ken