Dear Ludwig,
Thank you for the explanations. Now I understand.
Strangely then, the problem csn was on the replica that we had to reinitialize.
How could such a csn disappear?
Thanks again for the help. Much appreciated.
Sent from my iPhone
> On 19 May 2017, at 08:47, Ludwig Krispenz
On 05/18/2017 05:35 PM, Christophe TREFOIS wrote:
Dear Ludwig,
Thanks for your help in IRC to guide me in running the right commands.
Here is the output, toto1 and toto2 are CA master, and toto3 and toto4
are non CA master. The problematic replica was toto3, and after
re-init, we haven’t
Dear Ludwig,
Thanks for your help in IRC to guide me in running the right commands.
Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 are non
CA master. The problematic replica was toto3, and after re-init, we haven’t
seen any errors in the log anymore.
Hi Ludwig,
Since we were scared, we did a full re-init of that specific replica from the
CA master, and it looks like the issue is not appearing anymore.
Is this sufficient, or should we still investigate ?
Thanks for your help!
Christophe
--
Dr Christophe Trefois, Dipl.-Ing.
Technical
hi,
there was a change that in the case of a missing csn ds would not
silently use a "close" one and continue, but log an error, backoff and
retry - after updates on other masters the staring csn coudl change and
replication continue.
Now, in your case the csn reported missing:
