[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: delta sync repl out of sync
Hi all,
While I still have no idea about the casue, following error are noted in slapd.log repeatedl and seems related to accesslog operations. Fyi.
Thanks again.
/ST Wong
------------------------------------ Consumer ----------------------------------------------
Dec 19 00:08:20 nss3 slapd[32000]: daemon: activity on 1 descriptor
Dec 19 00:08:20 nss3 slapd[32000]: daemon: activity on:
Dec 19 00:08:20 nss3 slapd[32000]: 20r
Dec 19 00:08:20 nss3 slapd[32000]:
Dec 19 00:08:20 nss3 slapd[32000]: daemon: read active on 20
Dec 19 00:08:20 nss3 slapd[32000]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Dec 19 00:08:20 nss3 slapd[32000]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Dec 19 00:08:20 nss3 slapd[32000]: connection_read(20): input error=-2 id=1183, closing.
Dec 19 00:08:20 nss3 slapd[32000]: connection_closing: readying conn=1183 sd=20 for close
Dec 19 00:08:20 nss3 slapd[32000]: connection_close: deferring conn=1183 sd=20
Dec 17 14:38:53 nss3 slapd[25471]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable"
Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on 1 descriptor
Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on:
Dec 17 14:38:53 nss3 slapd[25471]:
Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on 1 descriptor
Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on:
Dec 17 14:38:53 nss3 slapd[25471]: 44w
Dec 17 14:38:53 nss3 slapd[25471]:
Dec 17 14:38:53 nss3 slapd[25471]: daemon: write active on 44
Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Dec 17 14:38:53 nss3 slapd[25471]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable"
------------------------------------ Provider ----------------------------------------------
Dec 19 00:31:07 festival slapd[4001]: => bdb_search
Dec 19 00:31:07 festival slapd[4001]: bdb_dn2entry("cn=accesslog")
Dec 19 00:31:07 festival slapd[4001]: => access_allowed: search access to "cn=accesslog" "entry" requested
Dec 19 00:31:07 festival slapd[4001]: <= root access granted
Dec 19 00:31:07 festival slapd[4001]: => access_allowed: search access granted by manage(=mwrscxd)
Dec 19 00:31:07 festival slapd[4001]: search_candidates: base="cn=accesslog" (0x00000001) scope=1
Dec 19 00:31:07 festival slapd[4001]: => bdb_dn2idl("cn=accesslog")
Dec 19 00:31:08 festival slapd[4001]: <= bdb_dn2idl: id=45552 first=2 last=45553
Dec 19 00:31:08 festival slapd[4001]: => bdb_equality_candidates (objectClass)
Dec 19 00:31:08 festival slapd[4001]: => key_read
Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read: failed (-30988)
Dec 19 00:31:08 festival slapd[4001]: <= bdb_equality_candidates: id=0, first=0, last=0
Dec 19 00:31:08 festival slapd[4001]: => bdb_inequality_candidates (reqStart)
Dec 19 00:31:08 festival slapd[4001]: => key_read
Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read 1 candidates
Dec 19 00:31:08 festival slapd[4001]: => key_read
Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read 9 candidates
Dec 19 00:31:08 festival slapd[4001]: => key_read
[~4000 lines of "bdb_index_read <n> candidates, key_read" lines skipped]
Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read 13 candidates
Dec 19 00:31:10 festival slapd[4001]: => key_read
Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read 10 candidates
Dec 19 00:31:10 festival slapd[4001]: => key_read
Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read: failed (-30988)
Dec 19 00:31:10 festival slapd[4001]: <= bdb_inequality_candidates: id=28247, first=2, last=28248
------------------------------------ End ----------------------------------------------
________________________________
From: ST Wong (ITSC)
Sent: 12/12/2009 [Sat] 22:26
To: Quanah Gibson-Mount; openldap-software@openldap.org
Subject: RE: delta sync repl out of sync
Hi,
When I run that query, I got content of acess log, including those can't be updated to the consumer. The entry contains:
# 20091212000001.000002Z, accesslog
dn: reqStart=20091212000001.000002Z,cn=accesslog
objectClass: auditModify
reqStart: 20091212000001.000002Z
reqEnd: 20091212000001.000003Z
reqType: modify
reqSession: 165
reqAuthzID: cn=Manager,dc=my,dc=domain
reqDN: uid=1234567,dc=my,dc=domain
reqResult: 0
reqMod: visible:= yes
reqMod: modifiersName:= cn=root,dc=my,dc=domain
reqMod: modifyTimestamp:= 20091212000000Z
reqMod: entryCSN:= 20091212000001.260843Z#000000#001#000000
Is there anything wrong with the entry?
Thanks a lot.
/ST Wong
________________________________
--On Wednesday, December 09, 2009 11:58 PM +0800 "ST Wong (ITSC)"
<ST@itsc.cuhk.edu.hk> wrote:
> Oops, the space/line feed as caused by the "<-----" I typed in the
> posting. Original configuration file looks like this:
>
> [snipped]
> logbase="cn=accesslog"
> logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> syncdata=accesslog
> [snipped]
>
> BTW, just note that all 'pending' changes can be synchronized to
> consumer by restarting slapd.
And what happens if you run that query against the master as the syncrepl
DN?
I.e.,
ldapsearch -x -D "<syncrepl dn>" -W <syncrepl passwd> -b "cn=accesslog -H
ldap://<master> "(&(objectClass=auditWriteObject)(reqResult=0))"
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration