On 10/17/19 5:32 PM, Aravinda Vishwanathapura Krishna Murthy wrote:
On Thu, Oct 17, 2019 at 12:54 PM Alexander Iliev
mailto:ailiev%2bglus...@mamul.org>> wrote:
Thanks, Aravinda.
Does this mean that my scenario is currently unsupported?
Please try by providing external IP while cre
On Thu, Oct 17, 2019 at 12:54 PM Alexander Iliev
wrote:
> Thanks, Aravinda.
>
> Does this mean that my scenario is currently unsupported?
>
Please try by providing external IP while creating Geo-rep session. We will
work on the enhancement if it didn't work.
> It seems that I need to make sure
Thanks, Aravinda.
Does this mean that my scenario is currently unsupported?
It seems that I need to make sure that the nodes in the two clusters can
see each-other (some kind of VPN would work I guess).
Is this be documented somewhere? I think I've read the geo-replication
documentation seve
On Wed, Oct 16, 2019 at 11:36 PM Strahil wrote:
> By the way,
>
> I have been left with the impresssion that data is transferred via
> 'rsync' and not via FUSE.
> Am I wrong ?
>
Rsync syncs data from Master FUSE mount to Slave/Remote FUSE mount.
>
> Best Regards,
> Strahil NikolovOn Oct
Got it.
Geo-replication uses slave nodes IP in the following cases,
- Verification during Session creation - It tries to mount the Slave volume
using the hostname/IP provided in Geo-rep create command. Try Geo-rep
create by specifying the external IP which is accessible from the master
node.
- On
By the way,
I have been left with the impresssion that data is transferred via 'rsync'
and not via FUSE.
Am I wrong ?
Best Regards,
Strahil NikolovOn Oct 16, 2019 19:59, Alexander Iliev
wrote:
>
> Hi Aravinda,
>
> All volume brick on the slave volume are up and the volume seems functiona
Hi Aravinda,
All volume brick on the slave volume are up and the volume seems functional.
Your suggestion about trying to mount the slave volume on a master node
brings up my question about network connectivity again - the GlusterFS
documentation[1] says:
> The server specified in the mount
Hi Alexander,
Please check the status of Volume. Looks like the Slave volume mount is
failing because bricks are down or not reachable. If Volume status shows
all bricks are up then try mounting the slave volume using mount command.
```
masternode$ mkdir /mnt/vol
masternode$ mount -t glusterfs :
Hi all,
I ended up reinstalling the nodes with CentOS 7.5 and GlusterFS 6.5
(installed from the SIG.)
Now when I try to create a replication session I get the following:
> # gluster volume geo-replication store1 ::store2 create
push-pem
> Unable to mount and fetch slave volume details. Pleas
Hi all,
Sunny, thank you for the update.
I have applied the patch locally on my slave system and now the
mountbroker setup is successful.
I am facing another issue though - when I try to create a replication
session between the two sites I am getting:
# gluster volume geo-replicati
Thank you for the explanation Kaleb.
Alexander,
This fix will be available with next release for all supported versions.
/sunny
On Mon, Sep 2, 2019 at 6:47 PM Kaleb Keithley wrote:
>
> Fixes on master (before or after the release-7 branch was taken) almost
> certainly warrant a backport IMO t
Fixes on master (before or after the release-7 branch was taken) almost
certainly warrant a backport IMO to at least release-6, and probably
release-5 as well.
We used to have a "tracker" BZ for each minor release (e.g. 6.6) to keep
track of backports by cloning the original BZ and changing the Ve
Hi Strahil,
Yes, this might be right, but I would still expect fixes like this to be
released for all supported major versions (which should include 6.) At
least that's how I understand https://www.gluster.org/release-schedule/.
Anyway, let's wait for Sunny to clarify.
Best regards,
alexande
Hi Sunny,
Thank you for the quick response.
It's not clear to me however if the fix has been already released or not.
The bug status is CLOSED NEXTRELEASE and according to [1] the
NEXTRELEASE resolution means that the fix will be included in the next
supported release. The bug is logged again
Hi Alexander,
Thanks for pointing that out!
But this issue is fixed now you can see below link for bz-link and patch.
BZ - https://bugzilla.redhat.com/show_bug.cgi?id=1709248
Patch - https://review.gluster.org/#/c/glusterfs/+/22716/
Hope this helps.
/sunny
On Fri, Aug 30, 2019 at 2:30 AM Ale
Hello dear GlusterFS users list,
I have been trying to set up geo-replication between two clusters for
some time now. The desired state is (Cluster #1) being replicated to
(Cluster #2).
Here are some details about the setup:
Cluster #1: three nodes connected via a local network (172.31.35.0/
16 matches
Mail list logo
