Rein Tollevik wrote:
Ryan Steele wrote:
I'm replicating both the config and backend databases between two boxes. Everything seems fine, but for some reason when I query them both for the contextCSN, the config database returns only one while the backend database returns two, as seen below:
The contextCSN attribute with any given sid is added to a database only after the server with that serverID modifies the database. The count of contextCSN values in a database does not need to reflect the number of master servers that could modify it, and it have no relation to the values in other databases.
In your example, all modifications to cn=config was probably made on the first server (assuming it have serverID 1 that is). The example db have been modified by both.
Rein
Thanks a lot for clarifying; I didn't realize that the contextCSN for each SID was added to a given database only after being modified by that SID. And yes, I do understand that the different databases (e.g., backend and config) will have different contextCSN's reflecting the last time they were written to, but my question was mostly about the same database on different nodes. Namely, I thought that verifying whether replication was complete was done by comparing the contextCSN's for the same database on each node (SID) in the replication group. That is, if replication is working, each server to whom the given database is being replicated should have the same contextCSN for that database, to verify that each received the same last write operation.
I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.:
contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20100126210305.876171Z#000000#002#000000
Or should both nodes agree about the timestamps for each SID independently? E.g.:
### ldap1 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
### ldap2 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
It would intuitively seem to me that each node (SID) to whom the database is being replicated should have the same contextCSN, so that one could verify the replication status by looking at the attribute values for each SID on one node, instead of querying each node to see if the timestamp for each individual SID matched on every node. But, which is correct? Thanks again for the insight.
Respectfully, Ryan
Ryan Steele wrote:
I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.:
contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20100126210305.876171Z#000000#002#000000
Or should both nodes agree about the timestamps for each SID independently? E.g.:
### ldap1 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
### ldap2 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
Ah, I think I understand, and if my understanding is correct, the second case is the true statement. That is, the backend database on each node should agree about the most recent timestamp made by SID 001, indicating that they all received the same (most current) write from SID 001. I guess the question that remains in my mind, then, is why keep more than one contextCSN per database? Aren't we only concerned with the last write made to it (in this case, SID 001's write)? Thanks again for the insight.
Respectfully, Ryan
Ryan Steele wrote:
Ryan Steele wrote:
I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.:
contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20100126210305.876171Z#000000#002#000000
Or should both nodes agree about the timestamps for each SID independently? E.g.:
### ldap1 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
### ldap2 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000
Ah, I think I understand, and if my understanding is correct, the second case is the true statement. That is, the backend database on each node should agree about the most recent timestamp made by SID 001, indicating that they all received the same (most current) write from SID 001. I guess the question that remains in my mind, then, is why keep more than one contextCSN per database? Aren't we only concerned with the last write made to it (in this case, SID 001's write)? Thanks again for the insight.
That's only true in single-master replication. (Which is why the sid field was always unused up till mirrormode was introduced in 2.4.)
Ryan Steele wrote:
I guess the question that remains in my mind, then, is why keep more than one contextCSN per database? Aren't we only concerned with the last write made to it (in this case, SID 001's write)? Thanks again for the insight.
It's for a multi-master setup.
So the database with the SID of 001 updates the relevant contextCSN - meanwhile database 002 is updating it's own contextCSN.
Later the DBs connect and exchange updates so database 001 compares it's last contextCSN value stored for 002 with the current value from 002. If they're different then it has data to transfer based on the differences in the timestamps. At the same time DB 002 is comparing the contectCSN it has stored for 001 with the current 001 value and transferring records amended there.
Hope that makes more sense.
Carl
openldap-software@openldap.org
-
Carl Johnstone -
Howard Chu -
Ryan Steele