Hide Forgot
After manually creating the directories: # gluster volume geo-replication rep ip-10-86-198-172::rep start Starting geo-replication session between rep & ip-10-86-198-172::rep has been successful
Steps taken to start geo-replication: Spawned two Gluster AMIs. On each: # yum update # gluster-app-migrate # gluster-repo-switch 3.2 Created a volume called "repo" on both servers. The two volumes are independent. Each server's volume only contains a single brick that is local. gluster volume geo-replication rep ip-10-124-129-140::rep start internal error, cannot startthe geo-replication session geo-replication command failed After doing some debugging with gdb, it looks like the command works if I manually create the following directories: /etc/glusterd/geo-replication /var/log/glusterfs/geo-replication
i do not believe we have this on the baremetal installation - only AMI. Eco can you please confirm?
Raising to P1- BLOCKER - we cannot get geo-rep to work in the AMI. This needs an immediate fix
(In reply to comment #3) > Raising to P1- BLOCKER - we cannot get geo-rep to work in the AMI. This needs > an immediate fix geo-replication works on the AMI. I have personally confirmed geo-replication to be sync'ing data across AWS regions just a few minutes back. The issue being seen here is essentially an upgrade issue, and not a geo replication issue as such. Here's the dissection of the problem - During a yum upgrade to 3.2 (performed as part of gluster-app-migrate), the way yum/rpm works is that the post-install script of glusterfs-core RPM is executed _before_ the installation of glusterfs-geo-replication RPM. This is preventing the creation of /etc/glusterd/geo-replication directory (which is basically that glusterd believes that geo-replication was chosen not be installed in this environment, and internally wouldn't have "activated" the geo-sync features). Now the same glusterd continues executing after the upgrade process (which still believes geo-replication is not installed in the system). But by the time we start executing geo-replication commands, we find that geo-replication is installed (presence of gsyncd.py binary) and glusterd would be in quasi-upgraded state. Workaround - "service glusterd restart" right after the gluster-app-migrate. This is just a one time workaround command which will fix the problem for good. Next step - we will work on restarting glusterd in the post-install of geo-replication RPM as well. This is _NOT_ a problem in the new 3.2 AMI as there is no upgradation involved. Avati
*** Bug 2900 has been marked as a duplicate of this bug. ***
PATCH: http://patches.gluster.com/patch/7378 in master (rpmbuild : restart glusterd after installing geo-replication rpm)
PATCH: http://patches.gluster.com/patch/7379 in release-3.2 (restart glusterd after installing geo-replication rpm)
tested with 3.2.1qa4. installing geo-replication now restart glusterd.