AWS, cascading replication and WAL archiving

From: "Daniel Serodio (lists)" <daniel(dot)lists(at)mandic(dot)com(dot)br>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: AWS, cascading replication and WAL archiving
Date: 2013-07-03 17:39:46
Message-ID: 51D461E2.1070207@mandic.com.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-general by date

  From Date Subject
Next Message David Johnston 2013-07-03 19:32:35 Feature Idea: Statement Echo in DO$$
Previous Message pg noob 2013-07-03 17:30:28 odd locking behaviour