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 <[email protected]> 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 < > [email protected]> написа: > > > > > > > > On Mon, Oct 12, 2020, 19:24 Strahil Nikolov <[email protected]> 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 < > [email protected]> написа: > > > > > > > > > > > > > > > > On Mon, Oct 12, 2020 at 9:47 AM Diego Zuccato <[email protected]> > 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 > > [email protected] > > https://lists.gluster.org/mailman/listinfo/gluster-users > > >
________ 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 [email protected] https://lists.gluster.org/mailman/listinfo/gluster-users
