Replication agreements creation order

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux