From: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Slony v. DBMirror |
Date: | 2005-05-06 13:38:50 |
Message-ID: | 427B736A.3040303@ca.afilias.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Peter Wilson wrote:
> Grant McLean wrote:
>
>> On Thu, 2005-05-05 at 14:16 -0400, Jeff - wrote:
>>
>>> One of the biggest things for Slony is that you can install slony,
>>> set things up and it will bring the slave(s) "up to speed". You
>>> don't need to do an initial data dump (I think you still need to
>>> load the schema on the slaves, but not the data). That is a BIG
>>> win for us folks who can't take a machine down while pg_dump runs
>>> (and while it is restored on hte slave)
>>
>>
>>
>> Why would you need to take anything down to run pg_dump? And surely
>> bringing a slave up to speed using Slony would be much slower than
>> dump/restore?
>>
> You don't need to take Postgres down to use pg_dump - it works just fine.
>
> The problem with replication (with DBmirror at least) is that you have
> to create a backup in a very specific order to make sure your new
> backup ends up in sync and transactions are neither replicated more
> than once, or not replicated at all:
Not the case with Slony. When you subscribe a new set, it it does a
copy of the data up to the the point in time when you've issued the
subscribe command. While it's copying date, events to the node are
being logged. Once the copy is completed, the events are applied, in
the proper order, to bring the set up to date.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2005-05-06 13:40:37 | Re: Extracting date from timestamp |
Previous Message | Michael Fuhr | 2005-05-06 13:37:49 | Re: Extracting date from timestamp |