public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sameer Kumar <[email protected]>
To: Bill Moran <[email protected]>
Cc: Thomas Harold <[email protected]>
Cc: Albe Laurenz <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PG replication across DataCenters
Date: Tue, 24 Dec 2013 14:39:42 +0800
Message-ID: <CADp-Sm5=PZjiUSkXBNDYC6ZEJgcXi0d4KWg+CGGJiwV1cxGpgQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAD7Ssm9S__ZQCOq2GEN0G0rrs_4U6aqXiLaX0hh0Ts8JH_LY2w@mail.gmail.com>
<A737B7A37273E048B164557ADEF4A58B17C5ED75@ntex2010i.host.magwien.gv.at>
<[email protected]>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-general>
Though I will agree that slony is a nice and a great tool w.r.t.
replication (specifically selective replication). But I would dis-agree on
below points:
* Cascading replication chains (a really big deal when you want
multiple slaves in the secondary facility and don't want to hog
your bandwidth)
Really? which version of Postgres are we talking about? I think cascaded
replication facility is available since v9.2
http://www.postgresql.org/docs/9.2/static/warm-standby.html#CASCADING-REPLICATION
* 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.
* Seeding of new slaves without interrupting existing nodes (assuming
your hardware has a little free capacity)
AFAIK, streaming replication does not cause any interruption while you add
a new node.
* Selective replication of tables, potentially in complex arrangements
where some tables are replicated to only to A and some only to B
and some to A and B, etc, etc.
Agree.
In general I do not like trigger based (replication) solutions for huge
clusters [this is my personal opinion and does not necessarily indicate my
employer's opinion ;-)] and for databases which has huge write volume
specifically if you do bulk insert/delete/update operations.
I think if it's slony or streaming replication will depend on below factors:
1) The change-set that you want to replicate contributes how much of your
total change set? e.g. on a per minute basis if it's 70% or above, I will
recommend you to go for streaming replication
2) Do you have too many tables to be added to replication set? lets say
above 70% of your total tables needs to be replication (unless rest 30%
have high write operations), then go for streaming replication
3) Do you too many bulk operations happening on the tables which needs to
be replicated
4) To some extent your choice will be influenced by the motivation behind
replication, DR, HA, reporting application (esp if you are particular about
replicating only selective tables for reports)
There are few easier ways of managing a slony cluster:
1)
http://shoaibmir.wordpress.com/2009/08/05/setting-up-slony-cluster-with-perltools/<http://shoaibm...;
2) I think even pgadmin supports slony replication (not sure if its slony-I
or slony-II)
Regards
Sameer
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: <CADp-Sm5=PZjiUSkXBNDYC6ZEJgcXi0d4KWg+CGGJiwV1cxGpgQ@mail.gmail.com>
* 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