Andrew Sullivan wrote:
On Wed, Jan 28, 2009 at 07:08:05PM -0500, Geoffrey wrote:
We have determined that we will have to shutdown slony in order to add
tables to our databases. This is because we have code that stops all
triggers from firing, thus we've had to set our Slony triggers to
'enable always'.
Sounds like you ought to fix your code ;-)
I'm working on that, but there's a difference in philosophy here. I've
just got to convince them I'm right and their wrong. ;(
That being said, would it be possible to add a table to our master
database while slony is active without causing problems to our
replication?
Yes. Slony cares about what's in its sets, not about tables it knows
nothing about. Add the table and start using it; just remember that
it won't be copied.
Awesome, as I thought.
Further, would it then be possible to add the changes to our slave at a
later time and permit slony to properly 'catch up' on that table, while
simply picking up where it left off on the others?
Maybe. I'm not sure I understand what you mean. But what you do,
when you're ready to make the change, is create a new set, add the
table to it, and let it sync up with the replica. When it's caught up
more or less, then you can merge set if you want.
Actually, I think you do. ;)
So I would not add it to an existing set, I would simply create a new
set, with that table in it? That really is a better approach then I was
considering.
So, the fact that I use the altperl scripts and the slon_tools.conf
configuration file approach to my databases, I can simply add a new set
to my existing configuration and then run the appropriate commands to
get that table to sync?
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
