Re: Multiple Slave Failover with PITR

Поиск
Список
Период
Сортировка
От Ken Brush
Тема Re: Multiple Slave Failover with PITR
Дата
Msg-id CANCJzPasWWOUuob_5-G7n+OV2X251_WqjHA6E3s=q5pjG4T3Bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multiple Slave Failover with PITR  (Sergey Konoplev <gray.ru@gmail.com>)
Ответы Re: Multiple Slave Failover with PITR
Список 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

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Nolan
Дата:
Сообщение: Re: [HACKERS] [streaming replication] 9.1.3 streaming replication bug ?
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [streaming replication] 9.1.3 streaming replication bug ?