Quanah Gibson-Mount wrote:
It would be the remote server. It doesn't try and contact itself.
Okay, thanks.
Next questions:
When the replication is going through the refresh-present phase, am I correct in believing that the ADD entries are written only for entries that didn't previously exist in the consumer? So if there are, say, 20 ADD entries in the log, that means 20 entries that didn't exist at all in the the consumer database?
When I see the following in the log (this was immediately after a reboot):
Config: ** successfully added syncrepl "ldap://wwsv04.opus.co.nz" slapd starting syncrepl_entry: rid 123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 123 be_search (0) syncrepl_entry: rid 123 dc=example,dc=co,dc=nz syncrepl_entry: rid 123 be_modify (0) syncrepl_entry: rid 123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 123 be_search (0) syncrepl_entry: rid 123 uid=someuser,ou=People,dc=example,dc=co,dc=nz do_syncrep2: rid 123 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Should I take it to mean that the *entire* *tree* of dc=example,dc=co,dc=nz was previously missing? and it now contains only the one user "someuser"?
This would mean that the database was completely empty at that point. Surely it should immediately start doing about 9000 ADDs to get the rest of the database in sync - but it doesn't. It just remains in that state, until we take some action, either resetting the sync cookie or deleting the database and forcing it to rebuild.
This is still with version 2.3.32, I'm investigating a number of incidents looking for common factors and trying to determine exactly what happens.