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@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
