Thanks Saravana, that is starting to make sense. The change_detector was
already set to changelog (automatically). I updated it to xsync and the
volume successfully replicated to the remote volume, however I then
deleted all the data from the master and have not seen those changes
replicated yet even after pausing, resuming, stopping and starting the
geo-rep session.
I think somehow it prematurely switched to CHANGELOG mode before the
initial sync had completed.
We have 6 identical servers across 3 sites. The 2 at site A are one
stripe, mirrored to site B, and those 4 servers are all in the same
logical network; but we also want the data to be replicated to site C,
1000km away, where our developers can access it read-only.
We chose a Stripe volume to distribute the I/O load and to increase the
available capacity for bricks at each site, as each server has only one
nVME disk in it.
Regards,
Wade.
On 19/10/2015 7:07 pm, Saravanakumar Arumugam wrote:
Hi Wade,
There seems to be some issue in syncing the existing data in the
volume using Xsync crawl.
( To give some background: When geo-rep is started it goes to
filesystem crawl(Xsync) and sync all the data to slave, and then the
session switches to CHANGELOG mode).
We are looking in to this.
Any specific reason to go for Stripe volume? This seems to be not
extensively tested with geo-rep.
Thanks,
Saravana
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users
