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.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
