[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Syncrepl logging question
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.
--
Lesley Walker
Linux Systems Administrator
Opus International Consultants Ltd
Email lesley.walker@opus.co.nz
Tel +64 4 471 7002, Fax +64 4 473 3017
http://www.opus.co.nz
Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343
Wellington, New Zealand