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.
1. 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.
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.
--On Tuesday, December 17, 2024 12:32 PM +0000 michael.miceli88@gmail.com wrote:
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?
See https://www.rfc-editor.org/rfc/rfc4533
- 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?
With OpenLDAP 2.5+ you can use the accesslog database as a persistent sessionlog (This is what I do). This is true regardless of standard or delta syncrepl.
- Does having a session log
configured make sense if delta-syncrepl is being used?
Yes. delta-syncrepl will fall back to standard syncrepl in some situations.
I do suggest reading the RFC noted above.
Also, with 2.6 at least, I just use standard syncrepl with the accesslog storing the sessionlog.
--Quanah
Also, with 2.6 at least, I just use standard syncrepl with the accesslog storing the sessionlog.
Can you show me where that is documented so I can configure that? I don't see any release notes on this page that mention that. https://www.openldap.org/software/release/changes.html
Additionally on the 2.6 version of the admin guide for replication (https://www.openldap.org/doc/admin26/replication.html) it explicitly says
The current design of the session log store is memory based, so the information contained in the session log is not persistent over multiple provider invocations
openldap-technical@openldap.org