Well, that was helpful -- lol
This doesn't make any sense to me...and I'm wondering if this is the culprit for these errors.
In Section 18.3.3 N-Way Multi-Master
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 olcServerID: 3 $URI3 and dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
All Masters in the chain have the olcServerID's and olcSynRepl for itself and its partner? I can understand having each knowing about the others but why itself? It's replicating to itself?
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Thursday, January 30, 2014 4:40 PM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
--On Thursday, January 30, 2014 4:35 PM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:
Seeing the following in the logs:
Jan 30 16:28:41 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:28:41 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 30 16:33:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:33:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Sounds like you managed to break your system somehow.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration