Hi,
I think you cannot understand it by using the concept of CSN alone, you
need also to be aware of RUV (replication update vector) and URP (update
resolution protocol).
A CSN is generated with each externally applied modification, not for a
replicated operation, it cantains a time stamp and the replica ID, so
the CSNs are totally ordered. The CSN will be stored in the attribute
value which was modified and at som etime will be purged.
The RUV is a vector of CSNs for all replicaids a specific replica has
seen, in your example where alle replicas are in sync, the RUV on all
replicas might be (97A,98B, 98C, 99D, 98E). Now you get simultaneous
updates on all replicas at timestamp 100 and CSNs 100A,...100E will be
generated. Before replication taking place all RUVs will be updated
with the local change. So on replica C, the RUV will become (97A,98B,
100C, 99D, 98E). When a replication session C-->A will start it detects
that it has updates to send, it will position at 98C in the changelog an
start sending newer changes (eg 100C), A will process and apply this
update and also update its RUV to (100A,98B, 100C, 99D, 98E). Since
there will be other replication connections this will finally update all
replica and RUVs to (100A,100B, 100C, 100D, 100E) and all replicas are
in sync again.
Now assume that the updates 100x have been conflicting, eg an D an
attribute was replaced by XXX and on by by YYY. The update resolution
ensures that on all replicas the latest update (by CSN, not received)
wins. sind D>B all attributes will finally have th valus XXX. This
contains an atrificial decison on ordering CSNs but ensures that finally
all replicas will hav the same data.
Hope this helps,
Ludwig
On 15.11.23 20:02, William Faulk wrote:
>> it isn't necessary to keep track of a list of CSNs
> If it doesn't keep track of the CSNs, how does it know what data needs to be replicated?
>
> That is, imagine replica A, whose latest CSN is 48, talks to replica B, whose latest CSN is 40. Clearly replica A should send some data to replica B. But if it isn't keeping track of what data is associated with CSNs 41 through 48, how does it know what data to send?
>
>> by asking the other node for its current ruv
>> can determine which if any of the changes it has need to be propagated to the peer.
> In addition, the CSNs are apparently a timestamp and replica ID. So imagine a simple ring topology of replicas, A-B-C-D-E-(A), all in sync. Now imagine simultaneous changes on replicas A and C. C has a new CSN of, say, 100C, and it replicates that to B and D. At the same time, A replicates its new CSN of 100A to B and E. Now E has a new CSN. Is it 100A or 101E?
>
> If E's new max CSN is 100A, then when it checks with D, D has a latest CSN of 100C, which is greater than 100A, so the algorithm would seem to imply that there's nothing to replicate and the change that started at A doesn't get replicated to D.
>
> If E's max CSN is 101E, then, when D checks in with its 101D, it thinks it doesn't have anything to send. I suppose in this scenario that the data would get there coming from the other direction. But if E's max CSN is 101E, eventually it's going to check in with A, which has a max CSN of 100A, so it would think that it needed to replicate that same data back to A, but it's already there. This is an obvious infinite loop.
>
> I'm certain I'm missing something or misunderstanding something, but I don't understand what, and these details are what I'm trying to unravel.
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment