On 05/23/2016 06:29 PM, thierry bordaz wrote:
On 05/23/2016 03:06 PM, Ludwig Krispenz wrote:
> This is the latest version of the "changelog buffer processing" fixes.
> The background for the fix is here, I would like to get feedback on
> this as well to clarify what is unclear
I have not yet reviewed the patch. I was looking at the design.
Regarding your note:
If you refer to this part:
Special case: RID of the consumer in the current replication session
If the consumer in the replication session is also a master its RID will
be contained at least in the consumerRUV. If it is also in the supplier
RUV the question is if it should be considered in the decision if
updates should be sent. Normally a master has the latest changes applied
to itself, so there would be no need to check and send updates for its
RID. But there can be scenarios where this is not the case: if the
consumer has been restored from an older backup the latest csn for its
own RID might be older than changes available on other servers.
|NOTE: The current implementation ignores anchorCSNs based on the consumer RID. If, by
chance, the anchor csn used is older than this csn, the changes will be sent, but they
also ca nbe lost.
this referres to the "current" implementation before the fix, the doc
started as a post-design doc, and it shoul dbe correctedd
with the fix the if the supplier has newer changes for the consumerRID
than the consumer it will be reflected in the anchor csn calculation.
It is said that the anchorCSN will not be the from the consumerRID.
What is the mechanism that guaranty that the consumer will receive all
the updates it was the originator ?
389-devel mailing list
Red Hat GmbH, http://www.de.redhat.com/
, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill