Hi,
The explanation below looks excellent to me. You may also have a look at
Regarding the initial concern "having regular problems with missed
replications". A key element is that there is no synchronous
replication, an update is not sync immediately to all replicas. A LDAP
client req an update on one replica (original replica) that will
propagate the update to others replicas (themselves will be able to
propagate it to a next replica ("hops")). So there may be a delay
(replication lag) between the original update and the time the last
replica will receive it. Usually the delay is few seconds but may depend
on may factors.
As you noticed, updates are identified with CSN that are logged in
access log. If you suspect that an update is missing, you need to check
if the related CSN is present in the remote replicas access log files.
note that access logs are buffered.
best regards
thierry
On 11/15/23 18:12, David Boreham wrote:
I'm not sure about doc, but the basic idea iirc is that a vector
clock[1] (called replica update vector) is constructed from the
sequence numbers from each node. Therefore it isn't necessary to keep
track of a list of CSNs, only compare them to determine if another
node is caught up with, or behind the state for the sending node.
Using this scheme, each node connects to each other and 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. These are sent as
(almost) regular LDAP operations: add, modify, delete. The consumer
server then decides how to process each operation such that
consistency is preserved (all nodes converge to the same state). e.g.
it might skip an update because the current state for the entry is
ahead of the update. It's what nowadays would be called a CDRT scheme,
but that term didn't exist when the DS was devloped.
[1]
https://en.wikipedia.org/wiki/Vector_clock
On Wed, Nov 15, 2023, at 9:59 AM, William Faulk wrote:
> I am running a RedHat IdM environment and am having regular problems
> with missed replications. I want to understand how it's supposed to
> work better so that I can make reasonable hypotheses to test, but I
> cannot seem to find any in-depth documentation for it. Every time I
> think I start to piece together an understanding, experimentation
> makes it fall apart. Can someone either point me to some
> documentation or help me understand how it works?
>
> In particular, IdM implements multimaster replication, and I'm
> initially trying to understand how changes are replicated in that
> environment. What I think I understand is that changes beget CSNs,
> which are comprised of a timestamp and a replica ID, and some sort of
> comparison is made between the most recent CSNs in order to determine
> what changes need to be sent to the remote side. Does each replica
> keep a list of CSNs that have been sent to each other replica? Just
> the replicas that it peers with? Can I see this data? (I thought it
> might be in the nsds5replicationagreement entries, but the nsds50ruv
> values there don't seem to change.) But it feels like it doesn't keep
> that data, because then what would be the point of comparing the CSN
> values be? Anyway, these are the types of questions I'm looking to
> understand. Can anyone help, please?
>
> --
> William Faulk
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam, report it:
>
https://pagure.io/fedora-infrastructure/new_issue
>
_______________________________________________
389-users mailing list --389-users(a)lists.fedoraproject.org
To unsubscribe send an email to389-users-leave(a)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.fe...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue