[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Missing CSN in do_syncrep2 cookie log line
- To: openldap-technical@openldap.org
- Subject: Missing CSN in do_syncrep2 cookie log line
- From: Sean Burford <unix.gurus@gmail.com>
- Date: Fri, 24 Apr 2009 08:49:45 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=nhWg2ApbfKjgwW8Fz0PzwwkkOuw2jE7CZDlKmLRipHY=; b=ApzkFGPB94pIOCM/XHKup0GXtkUxM7jXbDBuiiLQK61kA9x5GhyqJaSzJKcARcZ1dF kGVslFVFzJLkdxfrCs0xyaMpdV4f+DSCDkTATBw07NIsA+X12wU1mwKOjFtSDspW93Kz iMoRHcNlnrCqrcRkYZ/fAU+Mi/LZtAJ6G8t5A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=RgAsyvsAhqyILPc6eCO1of+asDND0FuE2r7tJwY6oYngguFfug9adXC6pmMHfmQ7BB OIixxtjxf++nKDeyW+gDuSKdoIVaXYjPlUEoCw3JKNBCJleqsjxHdnGx1SSRQZB4C69p EDdxzWyXud0ewigtZdkXvKHCrpqqIwbCoof3c=
Hi,
I'm new to 2.4 (2.4.16) and I don't know if empty CSNs are expected. The provider restarted and the syncrepl consumer kept sync, however part way through the reconnection the consumer got an empty CSN and decided to do an additional reconnect. This may be a side effect of the provider running 2.3.39.
The provider has a syncrepl accesslog and an auditlog that both agree with the CSNs below (no changes were skipped by the sync). The accesslog database has syncprov-nopresent and syncprov-reloadhint set to TRUE. The main database has these values set to FALSE (syncprov-reloadhint will be toggled to TRUE shortly on the main database).
At 13:20:42 username1 has an attribute removed. The change is replicated at that time. This is the last entry replicated before the provider is shut down:
do_syncrep2: cookie=csn=20090424132042Z#000000#00#000000,rid=100
slap_queue_csn: queing 0xf966560 20090424132042Z#000000#00#000000
slap_graduate_commit_csn: removing 0x155621b8 20090424132042Z#000000#00#000000
syncrepl_message_to_op: rid=100 be_modify uid=username1,dc=example,dc=com (0)
slap_queue_csn: queing 0xd2f6cf8 20090424132042Z#000000#00#000000
slap_graduate_commit_csn: removing 0xec0a758 20090424132042Z#000000#00#000000
At 13:25:18 slapd on the syncrepl provider is shut down and the consumer notices:
do_syncrep2: rid=100 (-1) Can't contact LDAP server
do_syncrepl: rid=100 rc -1 retrying
At 13:26:12 slapd on the replication provider is restarted. The consumer connects 6 seconds later and receives the same attribute delete again (I assume it isn't an entry delete since there are no entry deletes in the hours bracketing this log):
do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
do_syncrep2: cookie=csn=20090424132042Z#000000#00#000000,rid=100
do_syncrep2: cookie=csn=,rid=100
do_syncrepl: rid=100 rc -1 retrying
At 13:27:18 slapd on the replication consumer reconnects and receives the same attribute delete again before continuing normal replication a little later when another user is modified:
do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
do_syncrep2: cookie=csn=20090424132042Z#000000#00#000000,rid=100
do_syncrep2: cookie=csn=20090424133119Z#000000#00#000000,rid=100
slap_queue_csn: queing 0xc9fdb67 20090424133119Z#000000#00#000000
slap_graduate_commit_csn: removing 0xf610488 20090424133119Z#000000#00#000000
syncrepl_message_to_op: rid=100 be_modify uid=username2,dc=example,dc=com (0)
--
Thanks,
Sean Burford