Re: Initing a new replica

From: Cody Cutrer <cody(at)instructure(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Initing a new replica
Date: 2012-06-27 04:41:49
Message-ID: CA+=qeWt7oCApWXedEi2-j+iw3idgbnXOZ5gjTObLL0f5agJCwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)instructure(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Glyn Astill 2012-06-27 09:47:48 Type Name / Internal name returned by pg_catalog.format_type with/without prepended schema name?
Previous Message John R Pierce 2012-06-27 04:29:10 Re: Initing a new replica