On 10/29/2017 10:11 PM, Sergei
Gerasenko wrote:
Hi Mark,
Thank you for the quick response. I’m just beginning to unravel
the mysteries of replication
Easier said than done...
, so I
really appreciate an expert’s help.
As you can see in the screenshot,
There is no screenshot attached.
the max db csn is quite a bit ahead. Is that an
indication of a problem?
How far ahead? Is replication working or not? Was it ever
working? Were your replication agreements initialized?
Should the server not try to minimize the
difference?
Of course, but... All depends on what kind of replication are you
using? Regular or fractional? Are you replicating multiple
backends?
I’m theorizing that some of the changes that might
occur should not be replicated — causing the RUV maxcsn to
increase but not the agreement’s?
This depends on your setup. Are you using FreeIPA? Or is
replication broken?
I would verify replication is working by making an update and seeing
if that update gets replicated to the other replicas. Also check
the errors log.
Regards,
Mark
Also, the Last Modify Time column for some
servers shows “1/1/1970 00:00:00”. I’ve verified that that’s how
it comes from the search query. What’s that an indication of?
Thank you
Sergei
On Oct 29, 2017, at 4:59 PM,
Mark Reynolds <mareynol@xxxxxxxxxx>
wrote:
On 10/29/2017 03:20 PM, Sergei Gerasenko wrote:
My question now is: what’s
the difference between the maxcsn of the
agreement and the maxcsn in the RUV?
The maxcsn in the RUV is where the database is at, the
agreement maxcsn
is what the repl agreement has processed.
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
