when I have disabled lastlogintime attiribute in "Account Policy
Plugin" (alwayrecord:yes) then I saw every thing normal replicaton
accured with succced.
so I think is there a problem for changelogdb management. becase I need
only last 90 days logs for lastlogintime information. and may be our system
is used ver fequrencly so the replication not complated during users loged
in with lastlogintime are recorded?
in ldap2 logs:
[29/May/2017:11:54:31.609920121 +0300] conn=4 fd=64 slot=64 connection from
172.16.54.180 to 172.16.54.181
[29/May/2017:11:54:31.610135409 +0300] conn=4 op=0 BIND dn="cn=replication
manager,cn=config" method=128 version=3
[29/May/2017:11:54:31.610658927 +0300] conn=4 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=replication manager,cn=config"
[29/May/2017:11:54:31.611037508 +0300] conn=4 op=1 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[29/May/2017:11:54:31.612070109 +0300] conn=4 op=1 RESULT err=0 tag=101
nentries=1 etime=0
[29/May/2017:11:54:31.612470105 +0300] conn=4 op=2 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[29/May/2017:11:54:31.614206652 +0300] conn=4 op=2 RESULT err=0 tag=101
nentries=1 etime=0
[29/May/2017:11:54:31.614628513 +0300] conn=4 op=3 EXT
oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[29/May/2017:11:54:31.615079610 +0300] conn=4 op=3 RESULT err=0 tag=120
nentries=0 etime=0
[29/May/2017:11:54:31.633632464 +0300] conn=4 op=4 MOD
dn="cn=20606764540,cn=Users,dc=sagliknet,dc=saglik,dc=gov,dc=tr"
[29/May/2017:11:54:31.635792553 +0300] conn=4 op=4 RESULT err=0 tag=103
nentries=0 etime=0 csn=592be1c9000000010000
[29/May/2017:11:54:31.635907086 +0300] conn=4 op=5 MOD
dn="cn=20606764540,cn=Users,dc=sagliknet,dc=saglik,dc=gov,dc=tr"
[29/May/2017:11:54:31.637579233 +0300] conn=4 op=5 RESULT err=0 tag=103
nentries=0 etime=0 csn=592be1c9000100010000
[29/May/2017:11:54:31.764759069 +0300] conn=4 op=6 EXT
oid="2.16.840.1.113730.3.5.5" name="replication-multimaster-extop"
[29/May/2017:11:54:31.765778342 +0300] conn=4 op=6 RESULT err=0 tag=120
nentries=0 etime=0
[29/May/2017:11:54:31.768032079 +0300] conn=4 op=7 EXT
oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[29/May/2017:11:54:31.768405286 +0300] conn=4 op=7 RESULT err=0 tag=120
nentries=0 etime=0
[29/May/2017:11:54:31.769224664 +0300] conn=4 op=8 EXT
oid="2.16.840.1.113730.3.5.5" name="replication-multimaster-extop"
[29/May/2017:11:54:31.770321529 +0300] conn=4 op=8 RESULT err=0 tag=120
nentries=0 etime=0
[29/May/2017:11:55:31.835062981 +0300] conn=4 op=9 UNBIND
[29/May/2017:11:55:31.835103451 +0300] conn=4 op=9 fd=64 closed - U1
2017-05-29 11:36 GMT+03:00 Alparslan Ozturk <alparslan.ozturk(a)gmail.com>:
I am tring to upgrade ldap2 server I saw this messages;
[29/May/2017:11:35:48.682669408 +0300] slapd shutting down - signaling
operation threads - op stack size 166 max work q size 135 max work q stack
size 135
[29/May/2017:11:35:48.690952202 +0300] slapd shutting down - closing down
internal subsystems and plugins
[29/May/2017:11:35:49.872175332 +0300] NSMMReplicationPlugin -
agmt="cn=mhrsldap2-mhrsldap1" (172:389): Warning: Attempting to release
replica, but unable to receive endReplication extended operation response
from the replica. Error -5 (Timed out)
[29/May/2017:11:35:50.060265381 +0300] Waiting for 4 database threads to
stop
[29/May/2017:11:35:51.008788537 +0300] All database threads now stopped
[29/May/2017:11:35:51.021523201 +0300] slapd shutting down - freed 135
work q stack objects - freed 166 op stack objects
[29/May/2017:11:35:51.974432991 +0300] slapd stopped.
[29/May/2017:11:35:54.648763978 +0300] check_and_set_import_cache:
pagesize: 4096, pages: 2001763, procpages: 2933
[29/May/2017:11:35:54.651378439 +0300] Import allocates 2860044KB import
cache.
[29/May/2017:11:35:54.652443493 +0300] Upgrade DN Format - NetscapeRoot:
Start upgrade dn format.
[29/May/2017:11:35:54.654011238 +0300] Upgrade DN Format - Instance
NetscapeRoot in /var/lib/dirsrv/slapd-mhrsldap/db/NetscapeRoot is
up-to-date
[29/May/2017:11:35:54.874089044 +0300] check_and_set_import_cache:
pagesize: 4096, pages: 2001763, procpages: 2934
[29/May/2017:11:35:54.876137518 +0300] Import allocates 2859732KB import
cache.
[29/May/2017:11:35:54.877121520 +0300] Upgrade DN Format - userRoot:
Start upgrade dn format.
[29/May/2017:11:35:54.878978734 +0300] Upgrade DN Format - Instance
userRoot in /var/lib/dirsrv/slapd-mhrsldap/db/userRoot is up-to-date
[29/May/2017:11:35:55.351168914 +0300] 389-Directory/1.3.5.10
B2017.145.2037 starting up
[29/May/2017:11:35:55.375878667 +0300] resizing db cache size: 20000000
-> 10000000
[29/May/2017:11:35:55.559740675 +0300] slapd started. Listening on All
Interfaces port 389 for LDAP requests
2017-05-29 1:16 GMT+03:00 William Brown <wibrown(a)redhat.com>:
> On Fri, 2017-05-26 at 11:44 +0300, Alparslan Ozturk wrote:
> > dn:
> > cn=mhrsldap2-mhrsldap1,cn=replica,cn=dc\3Dsagliknet\2Cdc\3Dsaglik\2Cdc
> ...
> > nsds5replicareapactive: 0
> > nsds5replicaLastUpdateStart: 20170522184536Z
> > nsds5replicaLastUpdateEnd: 19700101000000Z
>
> The answer is here: this replica has never been able to send a sucessful
> update to the ldap1 perhaps. You should check your error log, turn on
> replication logging, and generally check connectivity between these two
> masters,
>
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
>
>