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.
Hi Thierry,
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:
rh1
rh2
rh5
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
Warm Regards
Marco