Hi,
on the provider server there are 3 databases glued together with one sync provider in the top level database:
... overlay glue overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
one consumer replicates two of the three database, each to a database, each database has its own synrepl statement with an own searchbase to get only the entries of this tree/database from the provider. Each database has its own rid: 401 and 402.
When something changes in database 1 ou=humans, rid=401, the change is replicated. When something changes in database 2 ou=linux, rid=402, it is not. Only after a restart of the consumer changes apply.
Now I saw this in the log: 1. change in ou=humans (rid=401) 2. change in ou=linux (rid=402) 3. change in ou=linux (rid=402)
Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=402 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=402 NEW_COOKIE: rid=402,csn=20101201165315.347441Z#000000#000#000000 Dec 1 17:53:15 tfas099 slapd[12318]: do_syncrep2: rid=401 cookie=rid=401,csn=20101201165315.347441Z#000000#000#000000 Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 be_search (0) Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 employeeNumber=0,ou=humans,ou=foo Dec 1 17:53:15 tfas099 slapd[12318]: syncrepl_entry: rid=401 be_modify employeeNumber=0,ou=humans,ou=foo (0) ... Dec 1 17:53:28 tfas099 slapd[12318]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:28 tfas099 slapd[12318]: do_syncrep2: rid=401 NEW_COOKIE: rid=401,csn=20101201165328.955051Z#000000#000#000000 ... Dec 1 17:53:42 tfas099 slapd[12318]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - NEW_COOKIE Dec 1 17:53:42 tfas099 slapd[12318]: do_syncrep2: rid=401 NEW_COOKIE: rid=401,csn=20101201165342.175128Z#000000#000#000000
As you can see, on all three changes rid=401 is mentioned, never rid=402.
When I restart, I can see this:
Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=401 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 inserted UUID 9cd2cfc4-9005-102f-9517-d54a6b53d2d0 Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 be_search (0) Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 ou=accounts,ou=linux,ou=steuer,o=landesverwaltung niedersachsen,c=de Dec 1 18:06:35 tfas099 slapd[15676]: syncrepl_entry: rid=402 be_modify ou=accounts,ou=linux,ou=steuer,o=landesverwaltung niedersachsen,c=de (0) Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=402 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Dec 1 18:06:35 tfas099 slapd[15676]: do_syncrep2: rid=402 cookie=rid=402,csn=20101201165342.175128Z#000000#000#000000
I get the rid=402 changes!
Is this a configuration error on my side? Provider is 2.4.23, consumer is 2.4.20.
Marc
Marc Patermann hans.moser@ofd-z.niedersachsen.de writes:
Hi,
on the provider server there are 3 databases glued together with one sync provider in the top level database:
... overlay glue overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
one consumer replicates two of the three database, each to a database, each database has its own synrepl statement with an own searchbase to get only the entries of this tree/database from the provider. Each database has its own rid: 401 and 402.
When something changes in database 1 ou=humans, rid=401, the change is replicated. When something changes in database 2 ou=linux, rid=402, it is not. Only after a restart of the consumer changes apply.
Now I saw this in the log:
- change in ou=humans (rid=401)
- change in ou=linux (rid=402)
- change in ou=linux (rid=402)
[...]
I get the rid=402 changes!
Is this a configuration error on my side? Provider is 2.4.23, consumer is 2.4.20.
most likely an error on your side :-) you didn't provide the relevant configuration examples so I have to make a guess: is there a syncprov parameter declared for database 2?
-Dieter
Hi,
Dieter Kluenter schrieb am 01.12.2010 19:27 Uhr:
Marc Patermann hans.moser@ofd-z.niedersachsen.de writes:
on the provider server there are 3 databases glued together with one sync provider in the top level database:
... overlay glue overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
most likely an error on your side :-) you didn't provide the relevant configuration examples so I have to make a guess: is there a syncprov parameter declared for database 2?
OK, I changed the config on the provider to one syncprov per database each. Seams to work better now.
Marc
openldap-technical@openldap.org