<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
I think somehow it prematurely switched to CHANGELOG mode before the
initial sync had completed.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Wade.<br>
<div class="moz-signature">
<style type="text/css"> body {font-family: sans-serif;}</style><br>
</div>
<div class="moz-cite-prefix">On 19/10/2015 7:07 pm, Saravanakumar
Arumugam wrote:<br>
</div>
<blockquote cite="mid:5624B2C2.5040209@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hi Wade,<br>
<br>
There seems to be some issue in syncing the existing data in the
volume using Xsync crawl.<br>
( 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).<br>
<br>
We are looking in to this.<br>
<br>
Any specific reason to go for Stripe volume? This seems to be not
extensively tested with geo-rep.<br>
<br>
Thanks,<br>
Saravana<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>