> On 6/17/21 10:55 AM, Marco Favero wrote:
> Hi Marco,
> good to know you fixed the issue. If I read you correctly you fixed it
> via setting nsDS5ReplicaHost=FQDN of the consumer host in the
> replication agreement supplier->consumer. What is surprising is that it
> was working before with a non fqdn and suddenly stopped working.
not really, sorry, maybe I didn't explain well. I set the "full_machine_name" in dscreate with the fqdn of the host runnig the 389ds in place of the fqdn of the balancer ip.
It's the nsslapd-localhost parameter, I suppose.
> With recent versions, this problem is either transient (a supplier does
> not know a CSN showed by the consumer but another supplier that knows
> this CSN will eventually update the consumer), either permanent (the
> consumer got offline longer than changelog maxage) and you may need to
> reinit the consumer.
I still have this issue. Are there conditions that determine this issue yet?
It's as you describe: the only way to exit from that situation is the reinitialization.
I have three multimaster each other:
rh has also a scheduled agreement to dr-rh1. So, dr-rh1 is a consumer from rh1.
All is working fine. When I initialize rh1 from rh5, then the replica rh1 --> dr-rh1 stops to work and says "Error (18) Can't acquire replica (Incremental update transient warning. Backing off, will retry update later.)". Log claims that can't find a CSN. All other replica are fine.
So I have to reinitialize rh1 --> dr-rh01.
Thank you very much
389-users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
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://firstname.lastname@example.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure