[Gluster-users] Glusterfs as databse store

[Alex K]

HI Strahil,

Thanx for your feedback.
I had already received your feedback which seems to be very useful.
You had pointed at /var/lib/glusterd/groups/db-workload profile which
includes recommended gluster volume settings for such work-loads (includes
direct IO).
I will be testing this setup though I expect no issues apart from slower
performance then native setup.

On Sun, Oct 25, 2020 at 9:45 PM Strahil Nikolov <hunter86_bg at yahoo.com>
wrote:

> Hey Alex,
>
> sorry for the late reply - seems you went to the SPAM dir.
>
> I think that a DB with direct I/O won't have any issues with Gluster.As a
> second thought , DBs know their data file names , so even 1 file per table
> will work quite OK.
>

> But you will need a lot of testing before putting something into
> production.
>
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В понеделник, 12 октомври 2020 г., 21:10:03 Гринуич+3, Alex K <
> rightkicktech at gmail.com> написа:
>
>
>
>
>
>
>
> On Mon, Oct 12, 2020, 19:24 Strahil Nikolov <hunter86_bg at yahoo.com> wrote:
> > Hi Alex,
> >
> > I can share that oVirt is using Gluster as a HCI solution and many
> people are hosting DBs in their Virtual Machines.Yet, oVirt bypasses any
> file system caches and uses Direct I/O in order to ensure consistency.
> >
> > As you will be using pacemaker, drbd is a viable solution that can be
> controlled easily.
> Thank you Strahil. I am using ovirt with glusterfs successfully for the
> last 5 years and I'm very happy about it. Though the vms gluster volume has
> sharding enabled by default and I suspect this is different if you run DB
> directly on top glusterfs. I assume there are optimizations one could apply
> at gluster volumes (use direct io?, small file workload optimizations, etc)
> and was hoping that there were success stories of DBs on top glusterfs.  I
> might go with drbd as the latest version is much more scalable and
> simplified.
> >
> > Best Regards,
> > Strahil Nikolov
> >
> >
> >
> >
> >
> >
> >
> > В понеделник, 12 октомври 2020 г., 12:12:18 Гринуич+3, Alex K <
> rightkicktech at gmail.com> написа:
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 12, 2020 at 9:47 AM Diego Zuccato <diego.zuccato at unibo.it>
> wrote:
> >> Il 10/10/20 16:53, Alex K ha scritto:
> >>
> >>> Reading from the docs i see that this is not recommended?
> >> IIUC the risk of having partially-unsynced data is is too high.
> >> DB replication is not easy to configure because it's hard to do well,
> >> even active/passive.
> >> But I can tell you that a 3-node mariadb (galera) cluster is not hard to
> >> setup. Just follow one of the tutorials. It's nearly as easy as setting
> >> up a replica3 gluster volume :)
> >> And "guarantees" consinstency in the DB data.
> > I see. Since I will not have only mariadb, then I have to setup the same
> replication for postgresql and later influxdb, which adds into the
> complexity.
> > For cluster management I will be using pacemaker/corosync.
> >
> > Thanx for your feedback
> >
> >>
> >> --
> >> Diego Zuccato
> >> DIFA - Dip. di Fisica e Astronomia
> >> Servizi Informatici
> >> Alma Mater Studiorum - Università di Bologna
> >> V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
> >> tel.: +39 051 20 95786
> >>
> > ________
> >
> >
> >
> > Community Meeting Calendar:
> >
> > Schedule -
> > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
> > Bridge: https://bluejeans.com/441850968
> >
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > https://lists.gluster.org/mailman/listinfo/gluster-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20201026/835f9a56/attachment.html>