Dear

It means my DR server is not in sync with other two servers dc1 and dc2. but i am able to do successful search of last added user on all the servers.(which i added only on dc1 server)

On Mon, Jan 7, 2013 at 7:44 AM, Quanah Gibson-Mount quanah@zimbra.comwrote:

--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