💾 Archived View for ldapguy.smol.pub › contextcsn-2022-02-21 captured on 2024-03-21 at 15:07:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
OpenLDAP uses `syncrepl` replication. It is a form of "Pull" where the replicas pull a stream of changes since there last check-in. There is also a "search-and-persist" mode that stays connected constantly ... the most popular form. `syncrepl` has two more modes, simple where whole entries are returned for the search and delta where only the changes are returned. Simple is simpler but, obviously, costly. Delta is more complicated and much more popular. These days the OpenLDAP Project and Symas recommend `delta-syncrepl`.
With `syncrepl` Context State Numbers (CSNs) are used to keep track of the date of the last change for entries and the server as a whole. In entries an "operational attribute" is maintained containing the entryCSN (the last time it was changed and by which master). The directory overall has a contextCSN keeping state from all of the activity in the server AND the most recent contextCSNs from servers it has gotten updates from ... EVER.
Both the entryCSNs and the contextCSNs have exactly the same format. This is a contextCSN attribute from a server in one of our test clusters:
contextCSN: 20081226173429.931124Z#000000#001#000000
The value starts with a date-time stamp followed by a hash-mark. After that comes a field no longer needed but is retained for compatability. Also followed by a hash mark. The next is a three digit number followed by a hash. That is the system ID of the master server originally making the update. The remainder of the record is also vestigial and is zeroes.
Between two servers, if the contextCSNs for a given server ID don't match, the one with the earlier date-time is "behind" in replication.