Hi, after successfully setup a 4 node cascading replication and doing some load tests(thank you Quanah for your slamd templates) I wanted to switch to n-way replication, this time 2 nodes to start with. The result in short, ldapadding an initial dataset is synced either way, but any additional ldapadd is only kept local and not synced. -dsync shows successful synced entries:
,----[ successful synced entries ] | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 41551418-33d7-102d-94f3-e78d84b17a1f | syncrepl_entry: rid=002 be_search (32) | syncrepl_entry: rid=002 o=dkluenter | syncrepl_entry: rid=002 be_add (0) | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 41725ab4-33d7-102d-94f4-e78d84b17a1f | syncrepl_entry: rid=002 be_search (0) | syncrepl_entry: rid=002 cn=replicator,o=dkluenter | syncrepl_entry: rid=002 be_add (0) | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 4196ca66-33d7-102d-94f5-e78d84b17a1f | syncrepl_entry: rid=002 be_search (0) | syncrepl_entry: rid=002 cn=Administratoren,o=dkluenter | syncrepl_entry: rid=002 be_add (0) | do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE `----
On the second host, on which additional entries where created -dsync shows
Entry ou=people,o=dkluenter changed by peer, ignored Entry cn=foo bar,ou=people,o=dkluenter changed by peer, ignored syncprov_search_response: cookie=rid=001,sid=000,csn=20081021162117.597928Z#000000#000#000000
this entries have not been synced, but only kept local.
The more important line of my slapd.conf
,----[ slapd.conf on node-1, 192.168.110.30 ] | modulepath /opt/openldap-2.4/libexec/openldap | moduleload syncprov.la | | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | access to dn.base="" by * read | access to dn.base="cn=Subschema" by * read | | database config | rootdn "cn=config" | rootpw "xxx" | | database hdb | suffix "o=dkluenter" | rootdn "cn=admin,o=dkluenter" | rootpw hhdy01 | directory /opt/openldap-2.4/var/openldap-data | index objectClass eq | index entryUUID,entryCSN eq | index cn,sn,uid eq,sub | | access to dn.subtree="o=dkluenter" | by group.exact="cn=Administratoren,o=dkluenter" write | by users read | by * auth | syncrepl rid=002 provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | syncrepl rid=003 | provider=ldap://192.168.100.30:9004 | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | mirrormode on | overlay syncprov | syncprov-reloadhint true | syncprov-checkpoint 5 5 | | database monitor `----
,----[ slapd.conf node-2, 192.168.100.39 ] | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | syncrepl rid=001 | provider=ldap://192.168.100.30:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | syncrepl rid=004 | provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | mirrormode on | overlay syncprov | syncprov-reloadhint true | syncprov-checkpoint 5 5 `----
-Dieter
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
OpenLDAP 2.4.12 BerkeleyDB 4.6.21 + patch.4.6.21.1
Best Regards. Domen
-----Original Message----- From: openldap-software-bounces+d.mavric=iskratel.si@openldap.org [mailto:openldap-software-bounces+d.mavric=iskratel.si@openldap.org] On Behalf Of Dieter Kluenter Sent: Tuesday, October 21, 2008 7:45 PM To: openldap-software@openldap.org Subject: n-way replication question - [SPAM - Keyword] Found word(s) XXX in the Text body
Hi, after successfully setup a 4 node cascading replication and doing some load tests(thank you Quanah for your slamd templates) I wanted to switch to n-way replication, this time 2 nodes to start with. The result in short, ldapadding an initial dataset is synced either way, but any additional ldapadd is only kept local and not synced. -dsync shows successful synced entries:
,----[ successful synced entries ] | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 41551418-33d7-102d-94f3-e78d84b17a1f | syncrepl_entry: rid=002 be_search (32) | syncrepl_entry: rid=002 o=dkluenter | syncrepl_entry: rid=002 be_add (0) | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 41725ab4-33d7-102d-94f4-e78d84b17a1f | syncrepl_entry: rid=002 be_search (0) | syncrepl_entry: rid=002 cn=replicator,o=dkluenter | syncrepl_entry: rid=002 be_add (0) | syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) | syncrepl_entry: rid=002 inserted UUID 4196ca66-33d7-102d-94f5-e78d84b17a1f | syncrepl_entry: rid=002 be_search (0) | syncrepl_entry: rid=002 cn=Administratoren,o=dkluenter | syncrepl_entry: rid=002 be_add (0) | do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE `----
On the second host, on which additional entries where created -dsync shows
Entry ou=people,o=dkluenter changed by peer, ignored Entry cn=foo bar,ou=people,o=dkluenter changed by peer, ignored syncprov_search_response: cookie=rid=001,sid=000,csn=20081021162117.597928Z#000000#000#000000
this entries have not been synced, but only kept local.
The more important line of my slapd.conf
,----[ slapd.conf on node-1, 192.168.110.30 ] | modulepath /opt/openldap-2.4/libexec/openldap | moduleload syncprov.la | | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | access to dn.base="" by * read | access to dn.base="cn=Subschema" by * read | | database config | rootdn "cn=config" | rootpw "xxx" | | database hdb | suffix "o=dkluenter" | rootdn "cn=admin,o=dkluenter" | rootpw hhdy01 | directory /opt/openldap-2.4/var/openldap-data | index objectClass eq | index entryUUID,entryCSN eq | index cn,sn,uid eq,sub | | access to dn.subtree="o=dkluenter" | by group.exact="cn=Administratoren,o=dkluenter" write | by users read | by * auth | syncrepl rid=002 provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | syncrepl rid=003 | provider=ldap://192.168.100.30:9004 | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | mirrormode on | overlay syncprov | syncprov-reloadhint true | syncprov-checkpoint 5 5 | | database monitor `----
,----[ slapd.conf node-2, 192.168.100.39 ] | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | syncrepl rid=001 | provider=ldap://192.168.100.30:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | syncrepl rid=004 | provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=xxx | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 5" | mirrormode on | overlay syncprov | syncprov-reloadhint true | syncprov-checkpoint 5 5 `----
-Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E
Hi,
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
I have just modified test050 to meet my requirements and this seems to work. I will now pass this all over to slamd and do some testing.
-Dieter
"Dieter Kluenter" dieter@dkluenter.de writes:
Hi,
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
I have just modified test050 to meet my requirements and this seems to work. I will now pass this all over to slamd and do some testing.
I still have some issues with n-way replication. It seems that after a modification to the dataset contextCSN is not propagated to peers. With a standard syncrepl after a modifcation I see the propagation, but not with n-way replication.
,----[ log og standard syncprov replication ] | syncprov_sendresp: cookie=rid=001,csn=20081022161125.056721Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe20d40 20081022161125.056721Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161125.056721Z#000000#000#000000 | slap_queue_csn: queing 0x427f5280 20081022161245.349623Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe21760 20081022161245.349623Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161245.349623Z#000000#000#000000 | syncprov_sendresp: cookie=rid=001,csn=20081022161245.349623Z#000000#000#000000 `----
With n-way replication the contextCSN gets modified on the present master, but not on the peers:
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000
initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000
on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
I just wonder wether this is a new bug or is it silly me.
-Dieter
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Hi,
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
I have just modified test050 to meet my requirements and this seems to work. I will now pass this all over to slamd and do some testing.
I still have some issues with n-way replication. It seems that after a modification to the dataset contextCSN is not propagated to peers. With a standard syncrepl after a modifcation I see the propagation, but not with n-way replication.
,----[ log og standard syncprov replication ] | syncprov_sendresp: cookie=rid=001,csn=20081022161125.056721Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe20d40 20081022161125.056721Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161125.056721Z#000000#000#000000 | slap_queue_csn: queing 0x427f5280 20081022161245.349623Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe21760 20081022161245.349623Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161245.349623Z#000000#000#000000 | syncprov_sendresp: cookie=rid=001,csn=20081022161245.349623Z#000000#000#000000 `----
With n-way replication the contextCSN gets modified on the present master, but not on the peers:
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000
initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000
on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it should be the serverID of the server that received the write and propagated the modification).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Hello,
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000 initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000 on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it should be the serverID of the server that received the write and propagated the modification).
OK, than I presume that is a bug, unless I get other comments I will file an ITS.
-Dieter
Dieter Kluenter wrote:
Hello,
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000 initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000 on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it should be the serverID of the server that received the write and propagated the modification).
OK, than I presume that is a bug, unless I get other comments I will file an ITS.
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
Hello, Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Mavric Domen d.mavric@iskratel.si writes:
Hi,
[...]
on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it should be the serverID of the server that received the write and propagated the modification).
OK, than I presume that is a bug, unless I get other comments I will file an ITS.
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
,----[ Host 192.168.100.30 ] | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | syncrepl rid=002 provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=hhdy01 | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 3" | syncrepl rid=003 | provider=ldap://192.168.100.30:9004 | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=hhdy01 | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 3" | mirrormode on | overlay syncprov `----
,----[ Host 192.168.100.39 ] | serverID 1 ldap://192.168.100.30:9004/ | serverID 2 ldap://192.168.100.39:9004/ | | syncrepl rid=001 provider=ldap://192.168.100.30:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=hhdy01 | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 3" | syncrepl rid=004 provider=ldap://192.168.100.39:9004/ | bindmethod=simple | binddn="cn=admin,o=dkluenter" | credentials=hhdy01 | searchbase="o=dkluenter" | scope=sub | type=refreshAndPersist | retry="5 5 300 3" | mirrormode on | overlay syncprov `----
-Dieter
Hi,
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
Hello, Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Mavric Domen d.mavric@iskratel.si writes:
[...]
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000 initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000 on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000 I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it should be the serverID of the server that received the write and propagated the modification).
OK, than I presume that is a bug, unless I get other comments I will file an ITS.
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
-Dieter
Hi,
Dieter Kluenter wrote:
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
seems that I had exactly the same problem when setting up multimaster-repl. By trial and error I solved it by only defining one serverID on each host:
# master1 serverID 1
# master2 serverID 2
With this setting multimaster-repl seems to work correctly.
As I don't understand exactly how this statement affects multimaster-replication my question is, whether it is ok to do so or do I *need* to define all serverID as
serverID NUM URL
on all participating master.
Thanks, Holger
Holger Kaelberer Holger.Kaelberer@telefonica.de writes:
Hi,
Dieter Kluenter wrote:
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
seems that I had exactly the same problem when setting up multimaster-repl. By trial and error I solved it by only defining one serverID on each host:
# master1 serverID 1
# master2 serverID 2
With this setting multimaster-repl seems to work correctly.
As I don't understand exactly how this statement affects multimaster-replication my question is, whether it is ok to do so or do I *need* to define all serverID as
serverID NUM URL
on all participating master.
If one thinks about it, it is obvious that each participating peer has to be informed about its sid, as other peers are not participating prior to the initial setup, its only one sid. After starting all peers, they have to be informed about all particiating sids, that is prior to adding any data the sids have to be anounced. So my initial configuration was as you described above. After the initial setup I added all sids with a small shell script, copied from test050,
$LDAPMODIFY -x -D cn=config -H $HOST -w $CPW <<EOF dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URL1 olcServerID: 2 $URL2 EOF
Now the contextCSN looks like contextCSN: 20081022192158.873555Z#000000#001#000000 contextCSN: 20081022184543.202017Z#000000#002#000000 note the different sids 001, 002. ContextCSN, that is time + sid, indicate which peer modified the database last.
-Dieter
Dieter Kluenter wrote:
Holger Kaelberer Holger.Kaelberer@telefonica.de writes:
Hi,
Dieter Kluenter wrote:
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
seems that I had exactly the same problem when setting up multimaster-repl. By trial and error I solved it by only defining one serverID on each host:
# master1 serverID 1
# master2 serverID 2
With this setting multimaster-repl seems to work correctly.
As I don't understand exactly how this statement affects multimaster-replication my question is, whether it is ok to do so or do I *need* to define all serverID as
serverID NUM URL
on all participating master.
If one thinks about it, it is obvious that each participating peer has to be informed about its sid, as other peers are not participating prior to the initial setup, its only one sid. After starting all peers, they have to be informed about all particiating sids, that is prior to adding any data the sids have to be anounced. So my initial configuration was as you described above. After the initial setup I added all sids with a small shell script, copied from test050,
$LDAPMODIFY -x -D cn=config -H $HOST -w $CPW <<EOF dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URL1 olcServerID: 2 $URL2 EOF
Now the contextCSN looks like contextCSN: 20081022192158.873555Z#000000#001#000000 contextCSN: 20081022184543.202017Z#000000#002#000000 note the different sids 001, 002. ContextCSN, that is time + sid, indicate which peer modified the database last.
-Dieter
I pretty sure this is what test50 does at http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
When we add 1 $URL1 etc. it's after the server has already been bootstrapped.
I will rewrite this section. If using slapd.conf, would we need to add this after slapd has been started and restart the masters then?
Gavin Henry ghenry@OpenLDAP.org writes:
Dieter Kluenter wrote:
Holger Kaelberer Holger.Kaelberer@telefonica.de writes:
Hi,
Dieter Kluenter wrote:
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
seems that I had exactly the same problem when setting up multimaster-repl. By trial and error I solved it by only defining one serverID on each host:
# master1 serverID 1
# master2 serverID 2
With this setting multimaster-repl seems to work correctly.
As I don't understand exactly how this statement affects multimaster-replication my question is, whether it is ok to do so or do I *need* to define all serverID as
serverID NUM URL
on all participating master.
If one thinks about it, it is obvious that each participating peer has to be informed about its sid, as other peers are not participating prior to the initial setup, its only one sid. After starting all peers, they have to be informed about all particiating sids, that is prior to adding any data the sids have to be anounced. So my initial configuration was as you described above. After the initial setup I added all sids with a small shell script, copied from test050, $LDAPMODIFY -x -D cn=config -H $HOST -w $CPW <<EOF dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URL1 olcServerID: 2 $URL2 EOF Now the contextCSN looks like contextCSN: 20081022192158.873555Z#000000#001#000000 contextCSN: 20081022184543.202017Z#000000#002#000000 note the different sids 001, 002. ContextCSN, that is time + sid, indicate which peer modified the database last. -Dieter
I pretty sure this is what test50 does at http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
When we add 1 $URL1 etc. it's after the server has already been bootstrapped.
I will rewrite this section. If using slapd.conf, would we need to add this after slapd has been started and restart the masters then?
If you use slapd.conf, at the initial setup of each peer, only a single 'serverID' without URI has to be configured, after the start of all particating peers, you modify cn=config to add the other serverID plus adding URI, if applicable. You don't have to restart any participating server.
-Dieter
Dieter Kluenter wrote:
Gavin Henry ghenry@OpenLDAP.org writes:
Dieter Kluenter wrote:
Holger Kaelberer Holger.Kaelberer@telefonica.de writes:
Hi,
Dieter Kluenter wrote:
What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?
Solved it, silly me! The initial slapd.conf should only contain one serverID statement without any additional address, only after starting all peers the serverID has to be modified to include all participating peers.
seems that I had exactly the same problem when setting up multimaster-repl. By trial and error I solved it by only defining one serverID on each host:
# master1 serverID 1
# master2 serverID 2
With this setting multimaster-repl seems to work correctly.
As I don't understand exactly how this statement affects multimaster-replication my question is, whether it is ok to do so or do I *need* to define all serverID as
serverID NUM URL
on all participating master.
If one thinks about it, it is obvious that each participating peer has to be informed about its sid, as other peers are not participating prior to the initial setup, its only one sid. After starting all peers, they have to be informed about all particiating sids, that is prior to adding any data the sids have to be anounced. So my initial configuration was as you described above. After the initial setup I added all sids with a small shell script, copied from test050, $LDAPMODIFY -x -D cn=config -H $HOST -w $CPW <<EOF dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URL1 olcServerID: 2 $URL2 EOF Now the contextCSN looks like contextCSN: 20081022192158.873555Z#000000#001#000000 contextCSN: 20081022184543.202017Z#000000#002#000000 note the different sids 001, 002. ContextCSN, that is time + sid, indicate which peer modified the database last. -Dieter
I pretty sure this is what test50 does at http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
When we add 1 $URL1 etc. it's after the server has already been bootstrapped.
I will rewrite this section. If using slapd.conf, would we need to add this after slapd has been started and restart the masters then?
If you use slapd.conf, at the initial setup of each peer, only a single 'serverID' without URI has to be configured, after the start of all particating peers, you modify cn=config to add the other serverID plus adding URI, if applicable. You don't have to restart any participating server.
-Dieter
Obviously that's the way on the fly, but I meant for users who are still using slapd.conf and don't want to use cn=config (for whatever reasons).
Gavin Henry wrote:
Obviously that's the way on the fly, but I meant for users who are still using slapd.conf and don't want to use cn=config (for whatever reasons).
If they're using slapd.conf then obviously half of this discussion doesn't apply; there's no sense replicating cn=config if the changes aren't going to persist.
----- "Howard Chu" hyc@symas.com wrote:
Gavin Henry wrote:
Obviously that's the way on the fly, but I meant for users who are
still
using slapd.conf and don't want to use cn=config (for whatever
reasons).
If they're using slapd.conf then obviously half of this discussion doesn't apply; there's no sense replicating cn=config if the changes aren't going to persist.
Ah, of course. Forgot the part abotu replicating cn=config. Nevermind....
openldap-software@openldap.org
-
Dieter Kluenter -
Gavin Henry -
Holger Kaelberer -
Howard Chu -
Mavric Domen -
Pierangelo Masarati