AWS, cascading replication and WAL archiving

Поиск
Список
Период
Сортировка
От Daniel Serodio (lists)
Тема AWS, cascading replication and WAL archiving
Дата
Msg-id 51D461E2.1070207@mandic.com.br
обсуждение исходный текст
Список pgsql-general
I currently have a working 9.2 master + hot standby setup, using
asynchronous replication and WAL archiving (via a shared NFS mount),
running in our colocated datacenter.

I need to migrate this to AWS, with as little downtime as possible. My
plan is to create two cascading standbys, "daisy-chained" like this:
master (M) <- primary standby (S1) <- secondary standby (S2) <- tertiary
standby (S3), and at migration time, promote S2 to master and then drop
both M and S1 (hope this explanation make sense).

WAL-E[1] seems like a perfect solution for WAL archiving on AWS, so I've
set the master's archive_command to archive both on NFS (so I don't
break the current setup) and on Amazon S3 (using WAL-E) so S2 and S3 can
restore from it.

Q1) Is this a good migration strategy?

Q2) Should I promote S2 before killing M, or should I kill M before
promoting S2?

Q2) Should S2 and S3 read from the same WAL archive, that's initially
written to from M and by S2 when it gets promoted to master; or should I
have two separate WAL archives to avoid conflicts

Q3) How should I set S2 and S3's recovery.conf so S3 automatically
follows S2 when promoted to master? "recovery_target_timeline = latest" ?


Thanks in advance,
Daniel Serodio



[1] https://github.com/wal-e/wal-e


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

Предыдущее
От: David Johnston
Дата:
Сообщение: Re: How to create a cursor that is independent of transactions and doesn't calculated when created ?
Следующее
От: pg noob
Дата:
Сообщение: odd locking behaviour