Re: Geo-rep failing initial sync

Wade Fitzpatrick <wade.fitzpatrick@xxxxxxxxxxxxxxxx> · Tue, 20 Oct 2015 15:44:39 +1000



    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
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users