[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