Hi

if you are using syncReply then its ideally contextcsn#rid#sid#00000#

also you can have a look at slap -c option you get some more idea about it.

Regards,
Pratik

On 19-Jan-2017 03:29, "Marc Franquesa" <mark@l3jane.net> wrote:
Hi all

I finally got working a new setup with 3-node multimaster replication
for both the main DIT and cn=config tree.

Now I'm trying to monitor the replication status or all the nodes so I
focused on examining the contextCSN value of the root of the DBs, and
although I googled and reviewed other posts on the mailing list I'm
still not sure to understand correctly its use.

As far as I understood (please correct me if I'm wrong):

- Each DB backend which is replicated will have its own and independent
contextCSN at the root of the replicated DN (so I have 2 DBs:
cn=config, and dc=domain,dc=net, each one will have its own contextCSN
attribute).
- Each master which is running as a sync provider will update one value
on the contextCSN values. So, as I have multi-master replication
between 3 nodes (3 providers), I should have 3 different values of
contextCSN in each DB.

... so, why I'm seeing 4 values (identical on all servers as they are
in sync):
contextcsn: 20170111084028.692133Z#000000#001#000000
contextcsn: 20161228225757.121969Z#000000#004#000000
contextcsn: 20160201102250.543748Z#000000#005#000000
contextcsn: 20150917152138.054326Z#000000#006#000000

In the past I migrated some server, added some other node so is
possible that a 'ghost' provider CSN is still on the DB ?

Another point is the syntax of that value... Has any special meaning?

It seems that the first part is a timestamp with milisecond resolution,
but I would like to know the meaning of the 3 digits between #xxx# Are
they the ServerId ? or the rid in the replication ?

Please enlight me
Thanks for any details