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