11:18 a.m.
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.
7:01 p.m.
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
2:50 a.m.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
3:23 a.m.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
3:49 a.m.
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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
3:56 a.m.
>
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
414
days inactive
415
days old
389-users@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Alberto Crescente -
Thierry Bordaz -
William Brown