[389-users] Replication agreements creation order

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.
_______________________________________________
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.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue