At 16:53 21/11/2007, Robert Landrum wrote:
Jacques Caron wrote:
this just a limitation of slony? Or is there a workaround I've missed?
What other option would you imagine there could be?
Reject Master db connections. Dump Master. Load Master data onto
Slave. Start Master/Slave replication. Re-allow Master DB connections.
Well, that's basically what slony does, but without rejecting
connections on the master nor slave. The initial replication is quite
equivalent to a big pg_dump master | pgsql slave (a bunch of COPY TO
STDOUT's piped into COPY FROM STDIN's), just "synchronized" with the
start of the update collection (precisely so you can do it on a live
database...).
Note that you're not using the latest version of slony, so you might
have hit some instances where the replication is not as fast as it
could be because there was an issue in index creation deferral with
postgresql 8.2 which was fixed in 1.2.11. With the fix in, there's no
reason for it to be any longer than a dump + a restore (actually a
bit faster than that since the two operations are done in parallel,
so more like max(dump,restore)).
Jacques.
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
