Hello, I would like to create a three nodes cluster with multi-master system, but when I go to define the agreements between nodes I get different results depending on the order in which I create the agreements. The nodes hostname are test-389-ds-1, test-389-ds-2 and test-389-ds-3. If I define the agreements in the following order, some replications fail after the last agreement creation: test-389-ds-1 -> test-389-ds-2 test-389-ds-2 -> test-389-ds-1 test-389-ds-1 -> test-389-ds-3 test-389-ds-3 -> test-389-ds-1 test-389-ds-2 -> test-389-ds-3
If I define the agreements in the following order, all is ok:
test-389-ds-1 -> test-389-ds-2 test-389-ds-2 -> test-389-ds-1 test-389-ds-1 -> test-389-ds-3 test-389-ds-2 -> test-389-ds-3 test-389-ds-3 -> test-389-ds-1 test-389-ds-3 -> test-389-ds-2
Error log test-389-ds-1 [10/Mar/2023:18:26:01.268922410 +0100] - ERR - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636) - clcache_load_buffer - Can't locate CSN 640b564b000100030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:26:01.272854351 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636): CSN 640b564b000100030000 not found, we aren't as up to date, or we purged [10/Mar/2023:18:26:01.273957365 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=agreement-test-389-ds-1-to-test-389-ds-2" (test-389-ds-2:636): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized.
Error log test-389-ds-2 [10/Mar/2023:17:14:47.939971206 +0100] - INFO - NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=agreement-test-389-ds-2-to-test-389-ds-3" (test-389-ds-3:636)". Sent 15 entries. [10/Mar/2023:18:13:11.579175020 +0100] - INFO - task_export_thread - Beginning export of 'userroot' [10/Mar/2023:18:13:11.581387379 +0100] - INFO - bdb_db2ldif - export userroot: Processed 17 entries (100%). [10/Mar/2023:18:13:11.582475585 +0100] - INFO - task_export_thread - Export finished.
Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged [10/Mar/2023:18:27:29.283542396 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized.
# ds-replcheck offline -b dc=test,dc=com -m tmp/test-389-ds-1.ldif -r tmp/test-389-ds-2.ldif --rid 1 ... Missing Entries =====================================================
Entries missing on Replica: - cn=repl keep alive 3,dc=test,dc=com (Created on Supplier at: Fri Mar 10 16:09:47 2023)
Entry Inconsistencies =====================================================
cn=repl keep alive 1,dc=test,dc=com ---------------------------------------- - Attribute 'keepalivetimestamp' is different: Supplier: - Value: 20230310171215Z - State Info: keepalivetimestamp;adcsn-640b64ef000000010000;vucsn-640b64ef000000010000: 20230310171215Z - Date: Fri Mar 10 18:12:15 2023
Replica: - Value: 20230310161215Z - State Info: keepalivetimestamp;adcsn-640b56df000000010000;vucsn-640b56df000000010000: 20230310161215Z - Date: Fri Mar 10 17:12:15 2023
Is there a method to know the correct sequence of definition of the agreements?
Regards, Alberto.
Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged
Is there a method to know the correct sequence of definition of the agreements?
Did you do full re-inits when you create from 1 -> 2 and 1 -> 3?
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
On 3/13/23 01:01, William Brown wrote:
Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged
Is there a method to know the correct sequence of definition of the agreements?
Did you do full re-inits when you create from 1 -> 2 and 1 -> 3?
I think so. I executed the following commands sequence:
# On test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=1 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=2 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-2.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-2
# On test-389-ds-2 - > test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-1
# On test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=3 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-3
# On test-389-ds-3 -> test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-3-to-test-389-ds-1
# On test-389-ds-2 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-3
Regards,
Alberto Crescente.
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 3/13/23 08:50, Alberto Crescente wrote:
On 3/13/23 01:01, William Brown wrote:
Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin
- changelog program - repl_plugin_name_cl -
agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged
Is there a method to know the correct sequence of definition of the agreements?
Did you do full re-inits when you create from 1 -> 2 and 1 -> 3?
I think so. I executed the following commands sequence:
# On test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=1 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=2 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-2.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-2
# On test-389-ds-2 - > test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-1
Hi Alberto,
You should not initialize ds2 from ds1 then ds1 from ds2. You need to select your "main" ds (e.g. ds1) then init ds1->ds2 and ds1->ds3. Then you are done, they are all (ds1, ds2, ds3) talking about the same object (database) and replication will work.
The consequence of an init (e.g. ds1->ds2) is that it clears the changelog of the target (ds2) it is likely why you are seeing those alarming message.
best regards theirry
# On test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=3 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-3
# On test-389-ds-3 -> test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-3-to-test-389-ds-1
# On test-389-ds-2 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-3
Regards,
Alberto Crescente.
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 3/13/23 09:23, Thierry Bordaz wrote:
On 3/13/23 08:50, Alberto Crescente wrote:
On 3/13/23 01:01, William Brown wrote:
Error log test-389-ds-3 [10/Mar/2023:18:27:29.275950935 +0100] - ERR - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636) - clcache_load_buffer - Can't locate CSN 640b564d000000030000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Mar/2023:18:27:29.277963218 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=agreement-test-389-ds-3-to-test-389-ds-1" (test-389-ds-1:636): CSN 640b564d000000030000 not found, we aren't as up to date, or we purged
Is there a method to know the correct sequence of definition of the agreements?
Did you do full re-inits when you create from 1 -> 2 and 1 -> 3?
I think so. I executed the following commands sequence:
# On test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=1 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=2 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-2 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-2.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-2
# On test-389-ds-2 - > test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-1
Hi Alberto,
You should not initialize ds2 from ds1 then ds1 from ds2. You need to select your "main" ds (e.g. ds1) then init ds1->ds2 and ds1->ds3. Then you are done, they are all (ds1, ds2, ds3) talking about the same object (database) and replication will work.
The consequence of an init (e.g. ds1->ds2) is that it clears the changelog of the target (ds2) it is likely why you are seeing those alarming message.
Hi Theirry, if I only initialize ds-2 and ds-3 with ds-01 I have 1 Supplier and two Consumer. But if I want 3 Supplier in MMR,
isn't it necessary to create the remaing agreements (ds-02->ds-01, ds-03->ds-01 ,ds-02->ds-03 and ds-03->ds-02)?
Regards,
Alberto.
best regards theirry
# On test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" replication enable --suffix="dc=test,dc=com" --role="supplier" --replica-id=3 --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx"
# On test-389-ds-1 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-1-to-test-389-ds-3
# On test-389-ds-3 -> test-389-ds-1 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-1.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-3-to-test-389-ds-1
# On test-389-ds-2 -> test-389-ds-3 dsconf Sezione -D "cn=Directory Manager" repl-agmt create --suffix="dc=test,dc=com" --host="test-389-ds-3.pd.infn.it" --port=636 --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" --bind-passwd="xxxx" --bind-method=SIMPLE --init agreement-test-389-ds-2-to-test-389-ds-3
Regards,
Alberto Crescente.
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi Theirry, if I only initialize ds-2 and ds-3 with ds-01 I have 1 Supplier and two Consumer. But if I want 3 Supplier in MMR,
isn't it necessary to create the remaing agreements (ds-02->ds-01, ds-03->ds-01 ,ds-02->ds-03 and ds-03->ds-02)?
Yes but you don't need full re-inits.
You do:
ds1 -> ds2 (full init) ds1 -> ds3 (full init) ds2 -> ds1 (agmt only) ds3 -> ds1 (agmt only)
ds2 -> ds3 (agmt only) ds3 -> ds2 (agmt only)
This will give you a "full mesh" and correct csn/data generations.
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
389-users@lists.fedoraproject.org
-
Alberto Crescente -
Thierry Bordaz -
William Brown