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
