does srv2 run 1.4.3.22 ?
/var/lib/dirsrv/slapd-xx/db/"__db.00*
or try a more recent 1.4.4.15 or 1.4.4.16
Thanks,
M.
On Tue, Jun 1, 2021 at 5:30 AM Marco Favero <m.faverof@xxxxxxxxx> wrote:
Hello,
I'm dealing with the update from 389-ds 1.3.9.1 to 1.4.3.22 in three multimaster servers:
- srv1
- srv2
- srv3
srv1 replicates to srv2 and srv3.
srv2 replicates to srv1 and srv3.
srv3 replicates to srv1 and srv2.
Let suppose I reinstall srv3 with 389ds 1.4.3.22, and I initialize it from srv1. This happens with success as expected. The replica is fine.
Then, I reinstall srv2, and I initialize it from srv3. This happens with success as expected, but just at the initialization end, the agreement from srv3 to srv1 stops to works.
In the console appears "Error (18) Can't acquire replica (Incremental update transient warning. Backing off, will retry update later.)" in the status of the agreements from srv3 to srv1. In the logs I see errors like
repl_plugin_name_cl - agmt="srv3 to srv1" (srv1:389): CSN 596c6868000075320000 not found, we aren't as up to date, or we purged
clcache_load_buffer - Can't locate CSN 596c6868000075320000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
The changelogdb Maximun Age is "7d", equals to the default nsDS5ReplicaPurgeDelay for the suffix.
This happens always, for every suffix.
To resolve the issue I have to re-initialize from srv3 to srv1 again and after the end of initialization from srv3 to srv2.
Resuming:
1) install srv2 OK
2) initialize srv1 to srv3 OK
3) initialize srv2 to srv3: the agreement srv1 to srv3 stops to work
4) initialize srv1 to srv3 again
I would like to know how to configure the Directory Server in order to avoid the above scenario.
The problem is very similar to
https://access.redhat.com/solutions/2690611
but that document says that the problem was already fixed in 389-ds-base-1.3.5.10-15.el7_3 or later.
Could you help me?
Thank you very much
Marco
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
