On Wed, Apr 11, 2012 at 9:03 AM, Sergey Konoplev <gray.ru@xxxxxxxxx> wrote: > On Wed, Mar 28, 2012 at 11:35 AM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
