Re: Streaming Replication 9.2

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: David Greco <David_Greco(at)harte-hanks(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Streaming Replication 9.2
Date: 2013-04-11 15:13:17
Message-ID: 5166D30D.5070801@optionshouse.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 04/11/2013 09:51 AM, David Greco wrote:

> I’ve setup streaming replication between two 9.2 servers, and have a
> few concerns/questions. I set it up with a very large
> wal_keep_segments, 17000, and do NOT ship the logs to the standby.

O_o

> When I failover to the slave, MUST the process for bringing back up the
> former master initially as a slave involve copying a base backup from
> the new master back to the former master?

There's actually been quite a long discussion about just this recently.
There doesn't seem to be a consensus, but currently the answer is yes.
In order for the old master to follow the new one, it has to be re-synced.

For geographical separation, rsync might not cut it depending on how
long replication has been going on. Various hint bits and MVCC would
result in basically every file being copied. I've played around with
this, and it seems to work splendidly for drastically cutting bandwidth
and time required to re-sync across vast distances:

On current master:

tar -C /path/to/pgdata -c . | lzop --fast | nc -l 9999

On replication subscriber:

mkdir /path/to/pgdata
nc MASTER-NODE 9999 | lzop -d | tar -C /path/to/pgdata -x

If you don't care how long it takes, you can replace lzop with lbzip2 or
something you can use in parallel. This will take 4-8x longer, but can
use up to 30% less bandwidth based on tests I've run.

Otherwise, I'd recommend just using pg_basebackup.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

In response to

Browse pgsql-general by date

  From Date Subject
Next Message ledwabakg 2013-04-11 15:13:19 Re: UPDATE .. JOIN?
Previous Message Tom Lane 2013-04-11 15:12:25 Re: Cost of initiating cursors