Hello,
I set up 10 OpenLDAP Servers in MirrorMode replication. (Using OpenLDAP 2.4.24)
syncrepl
[Server1] provider: server10, server2 [Server2] provider: server1, server3 [Server3] provider: server2, server4 [Server4] provider: server3, server5 [Server5] provider: server4, server6 [Server6] provider: server5, server7 [Server7] provider: server6, server8 [Server8] provider: server7, server9 [Server9] provider: server8, server10 [Server10] provider: server9, server1
(like the shape of a ring.)
When data was updated by Server1, the value was updated only by Server1 and Server3. (Reproducibility is low)
Question * How to investigate the cause which was not replicated?
* Although all the servers become a setup which serves both as a provider and a consumer, is there any problem?
* Is there the method(API) that can detect what was replicated?
Thanks. Hiro
Configuration
Server1 --------------------------------------------------------------- overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 1000
serverID 1
syncrepl rid=2 provider=ldap://server2 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
syncrepl rid=10 provider=ldap://server10 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
mirrormode on
---------------------------------------------------------------
Server2 --------------------------------------------------------------- overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 1000
serverID 2
syncrepl rid=1 provider=ldap://server1 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
syncrepl rid=3 provider=ldap://server3 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
mirrormode on
---------------------------------------------------------------
Server3 --------------------------------------------------------------- overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 1000
serverID 3
syncrepl rid=2 provider=ldap://server2 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
syncrepl rid=4 provider=ldap://server4 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
mirrormode on
---------------------------------------------------------------
....
Server10 --------------------------------------------------------------- overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 1000
serverID 10
syncrepl rid=9 provider=ldap://server9 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
syncrepl rid=1 provider=ldap://server1 bindmethod=simple binddn="cn=Manager,dc=my-domain,dc=com" credentials="secret" searchbase="dc=my-domain,dc=com" schemachecking=off type=refreshAndPersist retry="2 30 30 +"
mirrormode on
---------------------------------------------------------------
--On Tuesday, November 27, 2012 6:01 PM +0900 rocketdive5@yahoo.co.jp wrote:
Hello,
I set up 10 OpenLDAP Servers in MirrorMode replication. (Using OpenLDAP 2.4.24)
I would strongly advise you to read the CHANGES that have occurred since 2.4.24, then upgrade to a current release that fixes numerous issues in syncrepl.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Thanks advice.
I try upgrade.
I would like to know whether there is the API or plugin which can detect what was replicated.
-- Hiro
----- Original Message -----
From: Quanah Gibson-Mount quanah@zimbra.com To: rocketdive5@yahoo.co.jp; openldap-technical@openldap.org Cc: Date: 2012/11/27, Tue 18:31 Subject: Re: MirrorMode Replication Problem
--On Tuesday, November 27, 2012 6:01 PM +0900 rocketdive5@yahoo.co.jp wrote:
Hello,
I set up 10 OpenLDAP Servers in MirrorMode replication. (Using OpenLDAP 2.4.24)
I would strongly advise you to read the CHANGES that have occurred since 2.4.24, then upgrade to a current release that fixes numerous issues in syncrepl.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
On Tue, Nov 27, 2012 at 07:09:35PM +0900, rocketdive5@yahoo.co.jp wrote:
I would like to know whether there is the API or plugin which can detect what was replicated.
Not directly, though you could turn on 'stats' and 'stats2' logging which would show you the entries supplied by one server to another. If you have problems to diagnose then you will want at least that level of logging anyway.
It may be easier to find out what *was not* replicated. This script will show you the current state of each server:
------------------------------------------------------------ #!/bin/sh # # check-replication
PATH=/usr/local/bin:/usr/bin:/bin export PATH
SUFFIX=dc=example,dc=com
for host in host1.example.com host2.example.com host3.example.com ... do echo $host ldapsearch -LLL -x -H ldap://$host/ -b ${SUFFIX} -s base contextCSN done ------------------------------------------------------------
If everything is working then the set of contextCSN values you see should be the same on each server. The values look like this:
contextCSN: 20120127155755.195827Z#000000#001#000000 contextCSN: 20121129113523.045520Z#000000#003#000000
You can see an obvious date field at the start. The small integer near the end is the server ID of the server that initially received the update.
Given a contextCSN value you can find the entry that it relates to like this:
ldapsearch -x -H ldap://host1.example.com/ "(entryCSN=20121127112456.206198Z#000000#003#000000)"
You might want to try that against each server in the ring just to check that they all show you the latest entry.
If one server is lagging behind you will see an older datestamp in the contextCSN. You can then find the entries that it has not updated by querying the source server, something like this:
ldapsearch -x -H ldap://host2.example.com/ "(entryCSN>=20121127112456.206198Z#000000#003#000000)"
Note that I am making an assumption here that replication worked up to a given time and then stopped. This process will not tell you much about changes that got skipped due to bugs.
Before getting into this sort of detail I suggest you check that each server is actually making successful connections to those one each side when it comes up. Also, as Quanah says, make sure you are running a release that has the fewest possible number of known replication bugs.
Andrew
openldap-technical@openldap.org