similar to: Why does geo-replication stop when a replica member goes down

Hello, I would like to find out the topology of an existing volume. For example, if I have a distributed replicated volume, what bricks are the replication partners? Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20121114/b203ea91/attachment.html>

Hi, I have created a proposal for the implementation of Geo Replication Hooks. See here: http://www.gluster.org/community/documentation/index.php/Features/Geo_Replication_Hooks Any comments, thoughts, etc would be great. Fred -------------- next part -------------- An HTML attachment was scrubbed... URL:

Adding Rahul and Kothresh who are SME on geo replication Thanks & Regards Karan Sandha On Sat, Jul 29, 2017 at 3:37 PM, mabi <mabi at protonmail.ch> wrote: > Hello > > To my two node replica volume I have added an arbiter node for safety > purpose. On that volume I also have geo replication running and would like > to stop it is status "Faulty" and keeps

Hello To my two node replica volume I have added an arbiter node for safety purpose. On that volume I also have geo replication running and would like to stop it is status "Faulty" and keeps trying over and over to sync without success. I am using GlusterFS 3.8.11. So in order to stop geo-rep I use: gluster volume geo-replication myvolume gfs1geo.domain.tld::myvolume-geo stop but it

I managed to force stopping geo replication using the "force" parameter after the "stop" but there are still other issues related to the fact that my geo replication setup was created before I added the additional arbiter node to my replca. For example when I would like to stop my volume I simply can't and I get the following error: volume stop: myvolume: failed: Staging

I have about 4 TB of data in a Gluster mirror configuration on top of ZFS, mostly consisting of 20KB files. I've added a georeplication target and the sync started ok. The target is using an SSH destination. It ran pretty quick for a while but it's taken over 2 weeks to sync just under 1 TB of data to the target server and it appears to be getting slower. The two servers are connected

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

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?

Hi Kotresh, I am expecting my hardware to show up next week. My plan is to run gluster version 3.12 on centos 7. Has the issue been fixed in version 3.12? Thanks a lot for your help! /Marcus On Fri, Mar 02, 2018 at 05:12:13PM +0530, Kotresh Hiremath Ravishankar wrote: > Hi Marcus, > > There are no issues with geo-rep and disperse volumes. It works with > disperse volume > being

Hi again, I made some more tests and the behavior I get is that if any of the slaves are down the geo-replication stops working. It this the way distributed volumes work, if one server goes down the entire system stops to work? The servers that are online do not continue to work? Sorry, for asking stupid questions. Best regards Marcus On Tue, Feb 06, 2018 at 12:09:40PM +0100, Marcus Peders?n

We are happy to help you out. Please find the answers inline. On Tue, Feb 6, 2018 at 4:39 PM, Marcus Peders?n <marcus.pedersen at slu.se> wrote: > Hi all, > > I am planning my new gluster system and tested things out in > a bunch of virtual machines. > I need a bit of help to understand how geo-replication behaves. > > I have a master gluster cluster replica 2 > (in

Thank you for your help! Just to make things clear to me (and get a better understanding of gluster): So, if I make the slave cluster just distributed and node 1 goes down, data (say file.txt) that belongs to node 1 will not be synced. When node 1 comes back up does the master not realize that file.txt has not been synced and makes sure that it is synced when it has contact with node 1 again? So

Venky Shankar, can you follow up on these questions? I too have this issue and cannot resolve the reference to '/nonexistent/gsyncd'. As Steve mentions, the nonexistent reference in the logs looks like the culprit especially seeing that the ssh command trying to be run is printed on an earlier line with the incorrect remote path. I have followed the configuration steps as documented in

Hello list, I'm toying with the idea of using Gluster as a user facing network share, and geo-replicating the data for backup purposes. At a bare minimum I'd like geo-replicate to not sync file deletions immediately to the slave, but instead queue those deletions for a configurable period of time (say 7 days). As an added bonus, moving a file would actually leave a copy behind with a

Hi, I am testing geo-replication 3.5.2 by following the instruction from https://github.com/gluster/glusterfs/blob/master/doc/admin-guide/en-US/markdown/admin_distributed_geo_rep.md All commands are executed successfully without returning any error, but no replication is done from master to the slave. Enclosed please find the logs when starting the geo-replication volume. At the end of the log,

Hi again, I have been testing and reading up on other solutions and just wanted to check if my ideas are ok. I have been looking at dispersed volumes and wonder if there are any problems running replicated-distributed cluster on the master node and a dispersed-distributed cluster on the slave side of a geo-replication. Second thought, running disperesed on both sides, is that a problem (Master:

Hi all! Today I have a small gluster replication on 2 machines. My plan is to scale this, I though need some feedback that how I plan things is in the right direction. First of all I have understood the need of an arbiter. When I scale this, say that I just have 2 replica and 1 arbiter, when I add another two machines can I still use the same physical machine as the arbiter? Or when I add

On 09/22/2017 02:25 AM, Kotresh Hiremath Ravishankar wrote: > The volume layout of geo-replication slave volume could be different > from master volume. > It's not mandatory that if the master volume is arbiter type, the > slave also needs to be arbiter. > But if it's decided to use the arbiter both at master and slave, then > the expansion rules is > applicable