Hi, Now that https://fedorahosted.org/389/ticket/48755 is merged, I would like to discuss the way we handle CSN with relation to this master. As I'm not an expert on this topic, I want to get the input of everyone about this. Following this document: http://www.port389.org/docs/389ds/design/changelog-processing-in-repl-state-sending-updates.html As I understand it, after a full online init, the replica that consumed the changes does not set it's CSN to match the CSN of the master that sent the changes. As a result, after the online init, this causes a number of changes to be replicated from the sending master to the consumer. These are ignored by the URP, and we continue. However, in a number of cases these are *not* ignored, and have caused us some bugs in replication in the past. We also have some failing changes that are skipped, which could in certain circumstance lead to inconsistency in replicas. We have gone to a lot of effort to be able to skip changes, to handle the case above. The reason was is that if there was a modrdn performed, and the entry ID of the entry that was moved was less than the new parent ID, this *had* to be skipped, so that after the online init the modrdn change was replayed and applied to the consumer. Since 48755 which sorts based on the parent ID, this seems to no longer be an issue. So we don't need to have the master replay it's changelog out to the consumer, because the consumer is now a literal clone of the data. So, is there a reason for us to leave the CSN of the consumer low to allow this replay to occur? Or can we alter the behaviour of the consumer to set it's CSN to the CSN of the sending master, so that we don't need to replay these changes? -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
