public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bill Moran <[email protected]>
To: Sameer Kumar <[email protected]>
Cc: Thomas Harold <[email protected]>
Cc: Albe Laurenz <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PG replication across DataCenters
Date: Sun, 29 Dec 2013 12:08:46 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADp-Sm4YH6-0Qj8LeW==omZFaF4DAjB0vjF3PQk0uM_qsTb_Vw@mail.gmail.com>
References: <CAD7Ssm9S__ZQCOq2GEN0G0rrs_4U6aqXiLaX0hh0Ts8JH_LY2w@mail.gmail.com>
<A737B7A37273E048B164557ADEF4A58B17C5ED75@ntex2010i.host.magwien.gv.at>
<[email protected]>
<[email protected]>
<CADp-Sm5=PZjiUSkXBNDYC6ZEJgcXi0d4KWg+CGGJiwV1cxGpgQ@mail.gmail.com>
<[email protected]>
<CADp-Sm4YH6-0Qj8LeW==omZFaF4DAjB0vjF3PQk0uM_qsTb_Vw@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-general>
On Mon, 30 Dec 2013 00:15:37 +0800 Sameer Kumar <[email protected]> wrote:
> >> > * Quick and easy movement of the master to any of the database in
> >> >
> >> > the cluster without destroying replication.
> >> >
> >> > Again, which version? Re-mastering is made simple in v9.3.
>
> >> I'm not seeing that in the documentation. In fact, what I'm finding
> >> seems to suggest the opposite: that each node's master is configured
> >> in a config file, so in the case of a complicated replication setup,
> >> I would have to run around editing config files on multiple servers
> >> to move the master ... unless I'm missing something in the documentation.
>
> Well, the pain can be minimized if you can write some simple shell scripts
> for this. Or if you can have a floating/virtual IP.
This is probably the only point that we're not seeing eye to eye on.
Take a real scenario I have to maintain. There is a single master and 11
replicas spread across 2 datacenters. Some of these replicas are read-only
for the application, 1 is for analytics, another supports development,
another is a dedicated backup system. The rest are purely for DR..
Now, in a facility failure scenario, all is well, we just promote
the DR master in the secondary datacenter and go back to work -- this should
be equally easy with either Slony or streaming
What I don't see streaming working for is DR drills. I need to, in a
controlled manner, move the entire application to the secondary datacenter,
while keeping all the nodes in sync, make sure everything operates properly
from there (which means allowing database updates), then move it all back
to the primary datacenter, without losing sync on any slaves (this is a 2T
database, which I'm sure isn't the largest anyone has dealt with, but it
means that reseeding slaves is a multi-hour endeavour). With Slony, these
drills are easy: a single slonik command relocates the master to the DR
datacenter while keeping everything in sync, and when testing is complete,
another slonik command puts everything back the way it was, without any
data loss and with minimal chance for human error.
If you feel that the current implementation of streaming replication is
able to do that task, then I'll have to move up my timetable to re-evaluate
it. It _has_ been a few versions since I've taken a good look at it.
--
Bill Moran <[email protected]>
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
view thread (36+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: PG replication across DataCenters
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox