Re: Replication status

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Monday, January 07, 2013 5:24 AM +0530 anil beniwal 
<beni.anil@gmail.com> wrote:

> Hi
>
> We are having 3 openldap 2.4.33 servers on rhel 6.3 in MMR, below is my
> replication status for all of them.
> We have imported all the data on one server and copied same data to other
> 2 servers.

> DR
> contextCSN: 20130101132757.303803Z#000000#000#000000
> contextCSN: 20130102093855.341468Z#000000#001#000000
> contextCSN: 20130102050153.147891Z#000000#002#000000
> contextCSN: 20130102135821.337371Z#000000#003#00000

#000# is the CSN created before MMR was set up, so there were no servers 
with any server ID, i.e., one server with a server ID of zero.  This 
context CSN will never update.

#001# is the CSN of the server with ServerID 1.
#002# is the CSN of the server with ServerID 2.
#003# is the CSN of the server with ServerID 3.

The 001 through 003 CSNs will reflect the last time any of those servers 
had a direct *not replicated* update.  For testing if a server is up to 
date, you want to compare all the CSNs to one another between the two 
servers.

I.e., you want CSN 001 to match CSN 001 on both servers.  CSN 002 to match 
CSN 002 on both servers.  CSN 003 to CSN 003 on both servers.  I wrote a 
rather fun perl script for Zimbra to do this across a MMR setup.

I will note that delta-syncrepl MMR remains the best option for configuring 
MMR, as it is the least likely to end up with conflicts, unless you run 
purely in MirrorMode.  It also retains the bandwidth and write throughput 
advantages it has with provider/replica replication as well.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration