Red Hat Bugzilla – Bug 1032445
Dist-geo-rep : When an active brick goes down and comes back, the gsyncd associated with it starts using xsync as change_detector
Last modified: 2015-07-29 00:30:18 EDT
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-18.104.22.168rhs-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.
this is still happening in the build glusterfs-22.214.171.124rhs-1
Upstream patch sent to not to Fallback to XSync if Changelog failed.
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
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.