--On Friday, January 26, 2018 8:23 PM +0000 hyc(a)symas.com wrote: Hi Howard, When reinstalling a 4-way MMR system from scratch, we still end up in REFRESH mode. In the database I'm loading, there are 4 contextCSN values, one per active master: contextCSN: 20171203010043.825769Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 When I start up the first master (serverID 4 in this case), a contextCSN value is properly written for it to the underlying db: Jan 29 10:06:06 anvil4 slapd[1949]: slapd starting Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 But when I start the other 3 masters, they do not write an entry for their CSN, and since there's no CSN value for them on the other masters either, they all fall back to REFRESH_DELETE: Jan 29 10:06:26 anvil4 slapd[1949]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Even worse, they do this for every master that comes online. I think the code needs to add an entry to the accesslog for every contextCSN value, not just the final contextCSN? I'll continue testing for the other half of the fix (Deleting all but the most recent entry from the accesslog during purge) Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>