[clug] [tech] Postgres Replication

Daniel Pittman daniel at rimspace.net
Tue Sep 22 01:48:36 MDT 2009


Arjen Lentz <arjen at lentz.com.au> writes:
> ----- "Steve McInerney" <steve at stedee.id.au> wrote:
>> The others have mentioned slony, adding an additional "me too" there; Just
>> some gotchas to be aware of:
>>
>> * watch out for replication lag. We can and do get very large delays
>> when massive transaction updates go thru.
>
> This sounds similar to the original/first implementation of MySQL 3.23
> replication around 1999.  It had a single thread that both retrieved events
> from the master and executed them.  We found that with long-executing
> statements, the lag would add up to a point where it becomes impossible to
> catch up.

I think it is probably fair to say that the state of PostgreSQL replication is
somewhere between this and the MySQL 4.0 level, in so far as I can tell.

[...]

> Replication is used for many reasons, not just failover.
>
> It allows for read scaling, admin on live systems (with dual masters),
> purposely timelagged slaves to ease recovery from user errors, and so on.
> DRBD (mentioned earlier) has its use, but does not have this wide scope -
> also, if a system stuffs up in say the filesystem, DRBD will naturally give
> you a perfect copy of the stuffup.

*nod*  I use, and recommend, DRBD style replication for fail-over and
availability reasons, like I would use a SCSI, or FC, attached shared block
device.

Pleasantly, most of these other features of replication can work together with
DRBD availability solutions, which is nice.  The best, for us, of both worlds.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.


More information about the linux mailing list