Description of problem: When an active brick goes down and comes back, the gsyncd associated with it starts using xsync as change_detector Version-Release number of selected component (if applicable): glusterfs-3.4.0.44rhs-1 How reproducible: Happens every time Steps to Reproduce: 1.create and start a geo-rep relationship between master and slave. 2.create some data and let it sync to slave. 3.kill a master glusterfsd process of active node and after other node takes over do gluster v start <master> force 4.check the logs or gluster v geo <master> <slave-url> config change_detector on that active node Actual results: change_detector is xsync Expected results: it should be changelog. Additional info:
this is still happening in the build glusterfs-3.4.0.59rhs-1
Upstream patch sent to not to Fallback to XSync if Changelog failed. http://review.gluster.org/#/c/9758/ This BZ is related to BZ 1201712
Verified with the build: glusterfs-3.7.1-7.el6rhs.x86_64 change_detector is changelog as: [root@georep1 scripts]# gluster volume geo-replication master 10.70.46.101::slave config change_detector changelog [root@georep1 scripts]# Moving the bug to verified state.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1495.html