Hi!
I think #1 is "presence".
AFAIK for #2, the log used for deltasyncrepl is actually another LDAP database. You would use "accesslog" I guess for #3
Ulrich
Mit freundlichen Grüßen Ulrich Windl
-----Original Message----- From: michael.miceli88@gmail.com michael.miceli88@gmail.com Sent: Tuesday, December 17, 2024 1:32 PM To: openldap-technical@openldap.org Subject: [EXT] Replication Specifics and Clarification
Hi, this is my first post to this mailing list, so I apologize if this is in the wrong location. I have recently started replicating our openLdap database and as part of that I combed through the admin guide to get a better understanding. I believe I have a decent grasp on replication now, but I had a few clarifying questions to ensure I understand.
- Firstly and least importantly, how is "present" in "present phase"
pronounced? Is it present as a noun, e.g. these are things that are present in the database, or is it present like a verb, e.g. I'm presenting all the things in the database? 2. Besides not needing to send the entire object in the delete phase, is it true that delta-syncrRepl provides an additional benefit of having a persisted session log store, e.g. the session store can survive an openLdap reboot? I didn't see that explicitly mentioned in the admin guide, but it would seem to be to be true. Is it true? 3. Does having a session log configured make sense if delta-syncrepl is being used? I saw a non-authoritative guides saying it's nice to have just in case a fallback to syncrepl happens, but the admin guide doesn't do this anywhere, nor does it make sense to me since even if a consumer provides a stale session cookie, a present phase must occur regardless of a session log. 4. I found in a non-authoritative document online saying during the refresh stage, that either present or delete or both phases can occur. In what situation would both a present and a delete phase occur? Or is that document wrong? 5. Does the phrase "delete phase" feel confusingly named? I spent significant time trying to figure out how data would be synchronized when a non-stale cookie was provided by the consumer since I assumed the delete phase only handled deletes. It wasn't until I read this paragraph carefully in the admin guide. In fact, no where in the admin guide can I find explicit mention that adds occur in the delete phase as well. However, it can be inferred in the last sentence of the following quote.
The transmission of the updated entries in the delete phase is the same as
in the present phase. The provider sends all the requested attributes of the entries updated within the search scope since the last synchronization to the consumer. In the delete phase, however, the provider sends a delete message for each entry deleted from the search scope, instead of sending present messages. The delete message consists only of the name of the entry and the synchronization control representing state delete. The new consumer copy can be determined by adding, modifying, and removing entries according to the synchronization control attached to the SearchResultEntry message.