[Bucardo-general] Replacing ontimecopy with cloning for b5

[Greg Sabino Mullane]

On Tue, Oct 15, 2013 at 10:02:43AM -0700, David E. Wheeler wrote:
...
> It will also need to deactivate any other kids associated with the tables 
> to be copied, and then re-activate them when it’s done.

Yes, I've gone back and forth on this. First, it should only do so when 
its copies of tables and dbgroups matches a sync exactly. Second, I'm 
not sure there is a need to - the delta syncs should be very short, and 
I think MVCC will take care of everything. The truncates may cause issue 
though. I'll think about this some more. We would need a smooth way to 
handle the kids too - it may be enough to simply kill the kid, let 
clone slip in, and then the CTL resurrects the kid who gets in line 
behind the clone process?

> Does onetimecopy even work in the 5.0 branch?

No.

> > For more than one source, we'll simply assume that there is no overlap 
> > and the sources will copy to each other, but will not truncate. So 
> > for example, with databases A:source, B:source, and C:target, a 
> > clone command will do the following:
> > 
> > C: TRUNCATE TABLE foo;
> > A: COPY * FROM foo => B: COPY FROM STDIN
> > A: COPY * FROM foo => C: COPY FROM STDIN
> > B: COPY * FROM foo => A: COPY FROM STDIN
> > B: COPY * FROM foo => C: COPY FROM STDIN
> 
> I don’t think that’s a good idea. If A and B are both sources, I would 
> *expect* there to be a lot of overlap. A better choice, IMO, would be to 
> require that only one source be used for the clone, and either truncate 
> and clone only to targets, or optionally also truncate and clone to 
> other sources.

I should be more clear - the above scenario only happens when people 
explicitly request it. In which case, caveat emptor. A use case for 
that is a swap sync with alternating sequences that needs to be brought 
online.

I have in mind that the CLI will complain if you try to clone a 
multi-source sync, and demand you pick a "winner" or give it the 
go ahead and do the above.

I'm also envisioning a pretty print out and final confirmation before 
all clone events, as it is a pretty major dropped row "are you sure?" 
moment.

As always, appreciate the feedback.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Digital signature
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20131015/170bb56d/attachment-0001.sig>