From: | Bill Moran <wmoran(at)potentialtech(dot)com> |
---|---|
To: | Thomas Harold <thomas-lists(at)nybeta(dot)com> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG replication across DataCenters |
Date: | 2013-12-10 11:37:42 |
Message-ID: | 20131210063742.86b78bf34f9fbb968454fed3@potentialtech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-general |
On Mon, 09 Dec 2013 11:09:21 -0500 Thomas Harold <thomas-lists(at)nybeta(dot)com> wrote:
> On 11/22/2013 5:57 AM, Albe Laurenz wrote:
> > Kaushal Shriyan wrote:
> >> I have read on the web that Postgresql DB supports replication
> >> across data centers. Any real life usecase examples if it has been
> >> implemented by anyone.
> >
> > Well, we replicate a 1 TB database between two locations. It is a
> > fairly active OLTP application, but certainly not pushing the limits
> > of what PostgreSQL can do in transactions per second.
> >
>
> Something that section 25 in the pgsql documentation is not clear about
> for hot-standby with WAL log shipping using the built-in streaming:
>
> Can you choose which databases / tables on the master server get
> streamed to the hot-standby read-only server at the remote site? If
> not, I suspect we'll have to go with either Slony or Bucardo.
Go with Slony. Trust me.
People seem to shy away from the comlexity of slony, only to realize
later that they're hurting because the solution they chose instead
doesn't have the features they need. Keep in mind some things that
slony does that aren't yet available with streaming:
* Cascading replication chains (a really big deal when you want
multiple slaves in the secondary facility and don't want to hog
your bandwidth)
* Quick and easy movement of the master to any of the database in
the cluster without destroying replication.
* Seeding of new slaves without interrupting existing nodes (assuming
your hardware has a little free capacity)
* 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.
I was about to go on and type more, but really, those three things
make a huge difference in day to day operations, when problems occur,
and when the unexpected (but joyful) "we never expected this much
activity" happens.
Streaming replication is great, but unless you're 100% sure you'll
be OK with the restrictions it imposes, I recommend taking the time
to learn how to manage slony, as the advantages far outweigh the
additional management overhead.
--
Bill Moran <wmoran(at)potentialtech(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2013-12-10 14:00:35 | Re: PG replication across DataCenters (section 25 in the manual) |
Previous Message | Bruce Momjian | 2013-12-09 21:13:30 | Re: pgcrypto docs |
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2013-12-10 11:49:01 | Re: Q: regarding backends |
Previous Message | Wojciech Skaba | 2013-12-10 11:35:43 | Bitmap Heap Scan slowdown |