[Gluster-users] Glusterfs as databse store

[Olaf Buitelaar]

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.

Best Olaf


Op ma 12 okt. 2020 om 20:10 schreef 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
>>
> ________
>
>
>
> 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/20201012/011c6ed1/attachment.html>