Peter Wilson wrote:
> Andrew Sullivan wrote:
>
>> On Thu, May 05, 2005 at 03:35:27PM +0100, Peter Wilson wrote:
>>
>>> Looking at Slony now, can someone tell me what the benefits of Slony
>>> are over DBmirror? As far as I can see:
>>> + both are async Master->multiple slaves
>>> + both (I think) can do cascaded replication
>>
>>
>>
>> This isn't really true of dbmirror. You can do it, but if you lose
>> the intermediate system, you also lose the cascaded ones (the
>> downstream one doesn't know about the state of the top-level origin).
>> Slony is designed to cover that case (it was one of several criteria
>> we had to satisfy).
>
>
> That's true. The alternative is to simply replicate from master to
> both slaves, but this places an additional load on the master.
>
>>
>>
>>> + neither replicate schema changes
>>
>>
>>
>> This is sort of false, too. Slony has a facility for injecting the
>> schema changes at just the right spot in the replication sets, so
>> that you really can push your schema changes through Slony. (This
>> isn't to say you should regularly do this -- it's designed for
>> production systems, where schema changes should be relatively rare.)
>>
> I got the lack of schema changes from the Slony documentation. I guess
> there must be some manual intervention though to say 'make these
> schema chagnes now'?
This is what you'd want to look at for schema changes:
http://gborg.postgresql.org/project/slony1/genpage.php?slonik_commands#stmt_ddl_script
You want to be absolutly, 100% sure that the schema changes are going to
work on all nodes before firing them through this, because you only get
one shot. The accepted best practice for doing this is to put the
schema changes in a transacation block that rolls back, and run them via
psql against all the nodes, and make sure nothing breaks.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.