Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


GlusterFS for replication?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

GlusterFS for replication?

I am wondering what are you guys using for your master-master failover scenarions.
Im currently working on a MySQL replication between two masters for the db and lsyncd for the files.

Im thinking of moving files to a GlusterFS but since my request is just replication, I feel that its outside of the scope, since it needs a server node and a client one. If server node goes down, Im afraid that I will have issues with the replicated files.

Im wondering if someone has done this already, for the scope of replication and if he can advise.

Comments

  • I haven't used it for this specific purpose, but I've used GlusteFS a lot

    Placing your MySQL data directory on Gluster would ensure it's generally available, but I don't think both masters could reasonably use the same set of data at the same time. It's been a long time since I've done any MySQL/MariaDB (and more-so for replication), so I'm unsure. I think it depends if you intend for them to both be active masters.

    If you have an IP that both instances can use, you could just failover to the other node by starting up MySQL on the other 'master' if one died. The data will already be there and should allow you to bring MySQL back.

    Generally it's recommended against doing two-node/brick replication. It's possible to encounter split-brain in that situation, and they recommend either doing replica 3 or adding an arbiter:

    https://docs.gluster.org/en/v3/Administrator Guide/arbiter-volumes-and-quorum/#why-arbiter

    Thanked by 1mfs
  • @jlay said:
    I haven't used it for this specific purpose, but I've used GlusteFS a lot

    Placing your MySQL data directory on Gluster would ensure it's generally available, but I don't think both masters could reasonably use the same set of data at the same time. It's been a long time since I've done any MySQL/MariaDB (and more-so for replication), so I'm unsure. I think it depends if you intend for them to both be active masters.

    If you have an IP that both instances can use, you could just failover to the other node by starting up MySQL on the other 'master' if one died. The data will already be there and should allow you to bring MySQL back.

    Generally it's recommended against doing two-node/brick replication. It's possible to encounter split-brain in that situation, and they recommend either doing replica 3 or adding an arbiter:

    https://docs.gluster.org/en/v3/Administrator Guide/arbiter-volumes-and-quorum/#why-arbiter

    Thanks for the response! Quite helpful!

    Ok, lets say that I move to Galera and use 3 nodes that each of them contain webfiles and dbs.

    What about my GlusterFS setup?
    I dont need to have a master and two slaves, just because if master fails, files wont be replicated.

  • jlayjlay Member
    edited September 2018

    @punkstar69 said:

    @jlay said:
    I haven't used it for this specific purpose, but I've used GlusteFS a lot

    Placing your MySQL data directory on Gluster would ensure it's generally available, but I don't think both masters could reasonably use the same set of data at the same time. It's been a long time since I've done any MySQL/MariaDB (and more-so for replication), so I'm unsure. I think it depends if you intend for them to both be active masters.

    If you have an IP that both instances can use, you could just failover to the other node by starting up MySQL on the other 'master' if one died. The data will already be there and should allow you to bring MySQL back.

    Generally it's recommended against doing two-node/brick replication. It's possible to encounter split-brain in that situation, and they recommend either doing replica 3 or adding an arbiter:

    https://docs.gluster.org/en/v3/Administrator Guide/arbiter-volumes-and-quorum/#why-arbiter

    Thanks for the response! Quite helpful!

    Ok, lets say that I move to Galera and use 3 nodes that each of them contain webfiles and dbs.

    What about my GlusterFS setup?
    I dont need to have a master and two slaves, just because if master fails, files wont be replicated.

    Sure thing!

    Sadly, I know even less about Galera - I set it up once, broke it, and walked away :smiley:

    I think it ultimately comes down to file locking on the shared volume - I don't believe two active masters could use the same directory (and files) on the same volume. If however, you had something data directories like '/gvol0/master1' and '/gvol0/master2' and they each use them respectively, then they could coexist on the same volume.

    In my experience, HA MySQL has been tough to accomplish without something third-party (eg: MMM: master-master-monitor, Galera, or Red Hat Cluster Suite). If I were to deploy MySQL now, I'd probably do it as a pod on Kubernetes (backed by GlusterFS to ensure the data is accessible everywhere). This would provide a consistent and predictable endpoint for MySQL and generally ensure it's alive.

  • Well my Galera went just fine in the past, fingers crossed for having it in the same state!

    Im looking forward to sync in real time, the www folder of the two machines, in order to provide failovers, in case one server goes down.

    Basically, im looking something simple, but not as simple as rsync. Lsyncd seems to be working fine for this job, but im not sure if its a quite pro solution. On the other hand, GlusterFS is too much for a folder replica. Any advices?

  • jlayjlay Member
    edited September 2018

    I've heard good things with Galera, but I have little personal experience :smile:

    Gluster will accomplish the realtime sync! Lsync is the closest alternative I'm aware of, but comparatively it's more resource expensive and I feel less dependable. I don't think Gluster is too much, personally - syncing www is a perfect use case in my opinion! I'd just be sure to use at least three nodes/bricks to avoid split-brain

  • punkstar69punkstar69 Member
    edited September 2018

    I was worried about two facts (or didnt I get it right?)

    a) GlusterFS needs a master. If master goes down, there is no replication for its downtime period, even if it come up later

    b) GlusterFS cannot sync folders, you have to move your folders in mounted points, after creating a volume, outside of your local disk

    Honestly, I still see advantages of tools like Syncthing - https://syncthing.net/ - for my case, which is nothing more than a replicated data of a specific directory. Whats your opinion?

  • punkstar69 said: a) GlusterFS needs a master. If master goes down, there is no replication for its downtime period, even if it come up later

    There is no master, only replicated and/or striped bricks. Ideally you use three to avoid issues (this has been stated before).

  • Oh, thanks for clarifying.

    Whats your opinion regarding Syncthing ? Does it sound to you like a better tool for my case aswell?

  • Database replication and File replication are entirely different stuff. For DB replication use galera/mysql replication. For files use Gluster/Unison/Unison+Lsyncd

    Thanked by 3Francisco Saahib dev077
Sign In or Register to comment.