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