On 07/25/2015 10:51 AM, Steve Singer wrote: > On Fri, 24 Jul 2015, David Fetter wrote: > >> Folks, >> >> While in the best of all possible worlds, we'd have planned out a >> replication strategy before we get tables whose initial sync via >> "SUBSCRIBE SET" will never finish, we aren't always given that much >> ability to plan that soon. >> >> CLONE is great when you want to light an Nth node for N > 2, but >> that's just adjusting an extant cluster, not creating one in the first >> place. >> >> What stands between the state of the slony code and being able to >> clone an origin node? > > My guess is that the hardest part of teaching slony how to do this would be > to figure out how to get the proper values in sl_setsync such that it knows > where to start replication from when it starts up as a subscriber.
Correct. The latest version of Slony uses that approach. The subscription process does store an sl_setsync entry according to the snapshot of copy_set with an empty action list. If there was a switch to pg_dump to somewhere save the txid_snapshot that it dumped, that would be a good starting point to artificially create the first replica. That said, pg_dump isn't that much faster than Slony's copy_set() so we'd need to find a way to reconstruct an sl_setsync entry from something like a binary base backup. That is not trivial. Regards, Jan -- Jan Wieck Senior Software Engineer http://slony.info _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general