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.)