Initing a new replica
I've got a few questions about initing a new replica. We have a
modestly large DB cluster with a master and two replicas running with
streaming replication. We tend to switch which one is the master
fairly often, shuffling hardware, upgrading kernels, etc. However,
every time we fail over, we have to re-init the old master as a new
replica from scratch using pg_basebackup. pg_basebackup's
documentation mentions copying the basebackup from one replica to
another, but doesn't really go into details. So I'm wondering if any
of the following would be valid ways to get the old master acting as a
replica against the new master more quickly:
* Assuming the old master stops prior to the new master exiting
recovery, and there is no timeline divergence, simply copying the
.history file from pg_xlogs, creating a recovery.conf, and starting
postgres (this is similar to how we change the non-participating
replica to stream from the new master instead of the old master - copy
the .history file, alter recover.conf, and restart postgres)
* Instead of using pg_basebackup, manually call pg_start_backup and
pg_stop_backup against the new master, and rsync the data over, since
presumably little has changed since a timeline divergence
* Instead of using pg_basebackup, manually call pg_start_backup and
pg_stop_backup (against the new master? or the non-participating
slave? not necessary?), and rsync or raw copy the data over from the
non-participating slave, reducing load on the new master.
Thanks for any help,
Cody Cutrer
On 06/26/12 9:04 PM, Cody Cutrer wrote:
* Instead of using pg_basebackup, manually call pg_start_backup and
pg_stop_backup against the new master, and rsync the data over, since
presumably little has changed since a timeline divergence
I believe thats the correct method.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
After thinking some more, an expansion on the third possibility:
* Call pg_start_backup on the master. Checkpoint the
non-participating replica. Copy data dirs from non-participating
replica. Copy xlogs from master. Call pg_stop_backup on the master.
Copy final xlogs from master. This would move the bulk of the I/O to
the non-participating replica, while still doing the "critical" parts
of the backup against the master.
Cody Cutrer
Show quoted text
On Tue, Jun 26, 2012 at 10:04 PM, Cody Cutrer <cody@instructure.com> wrote:
I've got a few questions about initing a new replica. We have a
modestly large DB cluster with a master and two replicas running with
streaming replication. We tend to switch which one is the master
fairly often, shuffling hardware, upgrading kernels, etc. However,
every time we fail over, we have to re-init the old master as a new
replica from scratch using pg_basebackup. pg_basebackup's
documentation mentions copying the basebackup from one replica to
another, but doesn't really go into details. So I'm wondering if any
of the following would be valid ways to get the old master acting as a
replica against the new master more quickly:* Assuming the old master stops prior to the new master exiting
recovery, and there is no timeline divergence, simply copying the
.history file from pg_xlogs, creating a recovery.conf, and starting
postgres (this is similar to how we change the non-participating
replica to stream from the new master instead of the old master - copy
the .history file, alter recover.conf, and restart postgres)
* Instead of using pg_basebackup, manually call pg_start_backup and
pg_stop_backup against the new master, and rsync the data over, since
presumably little has changed since a timeline divergence
* Instead of using pg_basebackup, manually call pg_start_backup and
pg_stop_backup (against the new master? or the non-participating
slave? not necessary?), and rsync or raw copy the data over from the
non-participating slave, reducing load on the new master.Thanks for any help,
Cody Cutrer