similar to: Possible to preload data on a georeplication target? First sync taking forever...

hi everybody, Have glusterfs released a feature named active-active georeplication? If yes, in which version it is released? If no, is it planned to have this feature? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20171024/0656b41f/attachment.html>

hi all, I want to know some more detail about glusterfs georeplication, more about syncdeamon, if 'file A' was mirorred in slave volume , a change happen to 'file A', then how the syncdeamon act? 1. transfer the whole 'file A' to slave 2. transfer the changes of file A to slave thx lot -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, No, gluster doesn't support active-active geo-replication. It's not planned in near future. We will let you know when it's planned. Thanks, Kotresh HR On Tue, Oct 24, 2017 at 11:19 AM, atris adam <atris.adam at gmail.com> wrote: > hi everybody, > > Have glusterfs released a feature named active-active georeplication? If > yes, in which version it is released?

thx for reply, that was so much interesting to me. How can I get these news about glusterfs new features? On Tue, Oct 24, 2017 at 5:54 PM, Vijay Bellur <vbellur at redhat.com> wrote: > > Halo replication [1] could be of interest here. This functionality is > available since 3.11 and the current plan is to have it fully supported in > a 4.x release. > > Note that Halo

Halo replication [1] could be of interest here. This functionality is available since 3.11 and the current plan is to have it fully supported in a 4.x release. Note that Halo replication is built on existing synchronous replication in Gluster and differs from the current geo-replication implementation. Kotresh's response is spot on for the current geo-replication implementation. Regards,

Thanks for your response (6 months ago!) but I have only just got around to following up on this. Unfortunately, I had already copied and shipped the data to the second datacenter before copying the GFIDs so I already stumbled before the first hurdle! I have been using the scripts in the extras/geo-rep provided for an earlier version upgrade. With a bit of tinkering, these have given me a file

I have a ~600tb distributed gluster volume that I want to start using geo replication on. The current volume is on 6 100tb bricks on 2 servers My plan is: 1) copy each of the bricks to a new arrays on the servers locally 2) move the new arrays to the new servers 3) create the volume on the new servers using the arrays 4) fix the layout on the new volume 5) start georeplication (which should be

Hi Alvin, Yes, geo-replication sync happens via SSH. Ther server port 24007 is of glusterd. glusterd will be listening in this port and all volume management communication happens via RPC. Thanks, Kotresh HR On Wed, Feb 7, 2018 at 8:29 PM, Alvin Starr <alvin at netvel.net> wrote: > I am running gluster 3.8.9 and trying to setup a geo-replicated volume > over ssh, > > It looks

We have an application that is storing an insane number of small files. We have run some tests with enabling geo-replication and letting it run but on our smallest data set it takes 10 days and our largest data set will likely take over 100 days. Would there be any way to take a copy of the data brick and convert that into a replicated image and then enable replication from the time of the

I am running gluster 3.8.9 and trying to setup a geo-replicated volume over ssh, It looks like the volume create command is trying to directly access the server over port 24007. The docs imply that all communications are over ssh. What am I missing? -- Alvin Starr || land: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin at netvel.net

Has anyone ever ran into a problem in which PHP's stat() call to a file on a Gluster-backed volume randomly fails, yet /usr/bin/stat never fails? Running strace against both reveals that the underlying system calls succeed. I realize this is probably a PHP problem since I cannot replicate with a non-PHP-based script; however, was hoping someone on this list might have seen this before. RHEL

Ccing glusterd team for information On Thu, Feb 8, 2018 at 10:02 AM, Alvin Starr <alvin at netvel.net> wrote: > That makes for an interesting problem. > > I cannot open port 24007 to allow RPC access. > > On 02/07/2018 11:29 PM, Kotresh Hiremath Ravishankar wrote: > > Hi Alvin, > > Yes, geo-replication sync happens via SSH. Ther server port 24007 is of >

That makes for an interesting problem. I cannot open port 24007 to allow RPC access. On 02/07/2018 11:29 PM, Kotresh Hiremath Ravishankar wrote: > Hi Alvin, > > Yes, geo-replication sync happens via SSH. Ther server port 24007 is > of glusterd. > glusterd will be listening in this port and all volume management > communication > happens via RPC. > > Thanks, >

Hello, I'm compiling glusterfs for a debian squeeze. When I do a make command, I see These parameter: GlusterFS configure summary =========================== FUSE client: yes Infiniband verbs: yes epoll IO multiplex: yes argp-standalone: no fusermount: no readline: no georeplication: yes I would like to create a package that can be used both as a client and a server. I'm not interested

Hello all, I'm trying to find a way to rotate the metadata changelogs. I've so far learned (by ndevos in #gluster) that changelog is needed for certain services, among those, georeplication, but not entirely sure about the extent. Is there a way to rotate these logs so that it takes up less space? This is not an entirely critical issue, but it seems kinda silly when we have a 3 GB volume

Hi, We are testing glusterfs. We have a setup like this: Site A: 4 nodes, 2 bricks per node, 1 volume, distributed, replicated, replica count 2 Site B: 2 nodes, 2 bricks per node, 1 volume, distributed georeplication setup: master: site A, node 1. slave:site B, node 1, ssh replicasets on Site A: node 1, brick 1 + node 3, brick 1 node 2, brick 1 + node 4, brick 1 node 2, brick 2 + node 3, brick

On Mon, May 7, 2018 at 9:19 PM, Kaleb S. KEITHLEY <kkeithle at redhat.com> wrote: > > See https://review.gluster.org/19974 Many thanks Kaleb. Your patch did the trick and I did manage to compile, however I get a Segmentation fault when trying to execute gluster. I'm using the following options to configure (taken from the glusterfs 3.11.1 port in the FreeBSD port repository):

Hi, I am trying to install glusterfs 3.3.1 from source code. At the time of configuration i am getting the following error * configure: error: python does not have ctypes support* On my system python version is: 2.4.3 Kindly advice on fixing the error. Thanks n Regards Neetu Sharma Bangalore -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 05/07/2018 04:29 AM, Roman Serbski wrote: > Hello, > > Has anyone managed to successfully compile the latest 3.13.2 under > FreeBSD 11.1? ./autogen.sh and ./configure seem to work but make > fails: See https://review.gluster.org/19974 3.13 reached EOL with 4.0. There will be a fix posted for 4.0 soon. In the mean time I believe your specific problem with 3.13.2 should be

This is belt and braces, because we've already added it to scsi_hostadapter. --- lib/Sys/VirtV2V/Converter/Linux.pm | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Sys/VirtV2V/Converter/Linux.pm b/lib/Sys/VirtV2V/Converter/Linux.pm index 375da48..d5a93a7 100644 --- a/lib/Sys/VirtV2V/Converter/Linux.pm +++ b/lib/Sys/VirtV2V/Converter/Linux.pm @@ -341,7 +341,7 @@