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
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