2:20 p.m.
After looking at the code for a couple of days, I finally see how the difference is
calculated:
Delta = Max Consumer CSN - Max Agreement CSN
Thus, instead of the max CSN of the RUV, the agreement's maxcsn is used?
My question now is: what’s the difference between the maxcsn of the agreement and the
maxcsn in the RUV?
Thanks!
Sergei
On Oct 29, 2017, at 10:36 AM, Sergei Gerasenko
<gerases(a)gmail.com> wrote:
Hi,
I’m using the repl-monitor script and I’m not sure the output I’m getting is right. If
you look at the attached image, you will see that the supplier replica (122) is at
"10/28/2017 23:37:06”. The supplier column correctly lists the supplier. But the
Supplier Max CSN column doesn’t use the max CSN in the master header (10/28/2017
23:37:06). Instead it uses the Max CSN of the supplier local to the consumer?
According to the screenshot, the lag is 0 secs. But the lag is actually 10/28/2017
23:37:06 minus 10/27/2017 21:54:14?
Thanks,
Sergei
<Screen Shot 2017-10-29 at 10.26.42 AM.png>
4:59 p.m.
New subject: repl-monitor
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.
9:11 p.m.
New subject: repl-monitor
Hi Mark,
Thank you for the quick response. I’m just beginning to unravel the mysteries of
replication, so I really appreciate an expert’s help.
As you can see in the screenshot, the max db csn is quite a bit ahead. Is that an
indication of a problem? Should the server not try to minimize the difference? 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?
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(a)redhat.com> 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.
8:23 a.m.
New subject: repl-monitor
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(a)redhat.com
> <mailto:mareynol@redhat.com>> 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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
2363
days inactive
2364
days old
389-users@lists.fedoraproject.org
3 comments
2 participants
participants (2)
-
Mark Reynolds -
Sergei Gerasenko