On Mon, Oct 12, 2020, 21:50 Olaf Buitelaar <[email protected]> wrote:
> Hi Alex, > > I've been running databases both directly and indirectly through qemu > images vms (managed by oVirt), and since the recent gluster versions (6+, > haven't tested 7-8) I'm generally happy with the stability. I'm running > mostly write intensive workloads. > For mariadb, any gluster volume seems to workfine, i've both running > shared and none-sharded volumes (using none-sharded for backup slave's to > keep the file's as a whole). > For postgresql it's required to enable the volume > option; performance.strict-o-direct: on. but both shared and none-sharded > work in that case too. > none the less i would advise to run any database with strict-o-direct on. > Thanx Olaf for your feedback. Appreciated > > Best Olaf > > > Op ma 12 okt. 2020 om 20:10 schreef 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 >> >
________ 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
