Dave Price wrote:
> Christopher,
>
> Thank you for your response.
>
> As this has a test setup anyway, I abandoned my 'by hand' scripts, and
> tried setting up the simple single-table replica using your perl tool.
> This worked ver well, once I removed all the stuff about setting up
> the user in psql.
>
> I have now been successful in running my (rather large) test case on a
> test box as well as the production server which has the real database
> we want to replicate.
>
> I must say, I am amazed at how fast the slony-replication created the
> copy - faster than a backup and restore!
As of 1.1.5, that should indeed be the case.
It should only be a slight improvement; the improvement from
dump/restore is that with Slony-I, the indexes are regenerated
immediately after loading table data, which should give you some
"cacheing wins." With dump/restore, indexes are added later, in a
seemingly somewhat haphazard order. (Mumble, mumble, topological
ordering based partially on creation times...)
> The production server has 'on insert' triggers which populate a couple
> of tables with initial data when a new row is added to (one of ) the
> main data collection tables. Should these triggers be present on the
> replica? My understanding is that they should be, and can fire
> without creating duplicate records on the slaves Is this true?
You should set up the subscriber *initially* to have those triggers.
Those triggers will get hidden, by Slony-I, when it sets up the node as
a subscriber, so they won't fire.
If that subscriber gets promoted to origin ("master"), the triggers will
get unhidden, so they will fire, then. And the triggers on the
ex-origin will get hidden so they don't fire anymore.
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
