Обсуждение: postgresql and glusterFS
Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.
the ENV is on Centos 7
Any idea?
Cheers
Alfredo
Hey Alfredo,
You can set up ceph as back end/data storage for postgres. Moreover you'll get a better community support as well.
On Wed, Sep 12, 2018 at 2:26 PM Alfredo De Luca <alfredo.deluca@gmail.com> wrote:
Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.the ENV is on Centos 7Any idea?Cheers--Alfredo
Thanks Prince. Appreciated.
So glusterFS is not good/suppported you think?
Cheers
On Wed, Sep 12, 2018 at 11:12 AM Prince Pathria <prince.pathria@goevive.com> wrote:
Hey Alfredo,You can set up ceph as back end/data storage for postgres. Moreover you'll get a better community support as well.On Wed, Sep 12, 2018 at 2:26 PM Alfredo De Luca <alfredo.deluca@gmail.com> wrote:Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.the ENV is on Centos 7Any idea?Cheers--Alfredo
Alfredo
Dear team,
Would please remove me from the group? thx
Beat Regard,
Zhenyu Xu
发件人: Prince Pathria <prince.pathria@goevive.com>
发送时间: Wednesday, September 12, 2018 17:12
收件人: alfredo.deluca@gmail.com
抄送: pgsql-admin@lists.postgresql.org
主题: Re: postgresql and glusterFS
Hey Alfredo,
You can set up ceph as back end/data storage for postgres. Moreover you'll get a better community support as well.
On Wed, Sep 12, 2018 at 2:26 PM Alfredo De Luca <alfredo.deluca@gmail.com> wrote:
Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.
the ENV is on Centos 7
Any idea?
Cheers
--
Alfredo
Em qua, 12 de set de 2018 às 10:56, Alfredo De Luca <alfredo.deluca@gmail.com> escreveu:
Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.the ENV is on Centos 7Any idea?
I have tested it but never put in production, it's useless.
What exactly you want to do?
Flavio
thanks heaps.
The idea is actually to use K8s so install postgres with glusterfs as storage manager so in case a POD crashes can start again on another node with the same file systems
Cheers
On Wed, Sep 12, 2018 at 11:48 AM Flavio Henrique Araque Gurgel <fhagur@gmail.com> wrote:
Em qua, 12 de set de 2018 às 10:56, Alfredo De Luca <alfredo.deluca@gmail.com> escreveu:Hi all. I wonder if I can install/configure postgresql with a distributed file system ...specifically glusterFS? is it supported? Does it work properly.the ENV is on Centos 7Any idea?It works and it supports all POSIX semantics. And because of it, it's slow as hell to writes because a FS lock acquired by PostgreSQL has to be replicated to all nodes before being confirmed. If you have a read bound database you should be fine tho.I have tested it but never put in production, it's useless.What exactly you want to do?Flavio
Alfredo
Em qui, 13 de set de 2018 às 10:06, Alfredo De Luca <alfredo.deluca@gmail.com> escreveu:
thanks heaps.The idea is actually to use K8s so install postgres with glusterfs as storage manager so in case a POD crashes can start again on another node with the same file systems
So it was a case of problem A question B.
If you're really looking that way I would never consider a networked filesystem.
k8s has mechanisms to restart a pod on the same node if you configure your pod correctly. Also, you should declare a data container with a well defined hardware dedicated volume and use a known stable filesystem like xfs or ext4 on it.
You should think of using PostgreSQL native replication to a standby pod on another kubernetes node.
If you really think you don't want to replicate your data (not recommended anyway) you can use a hardware storage system connected to two (or more) servers and use CLVM to switch a volume between servers in a controlled way. I don't know how to automate that with kubernetes maybe someone has more answers to you.
I don't see the point of using kubernetes for such a statefull beast like a database, kubernetes basics assume that a pod may fail at any time and you can have other instances running in parallel without worrying about their current state, which is *not* what a database system can do transparently.
You may consider using that for development or testing purposes but I don't see it in production by current technology. Some people run production databases on containers (replicating things as I said), I don't know about k8s.
Flavio Gurgel
Re: Flavio Henrique Araque Gurgel 2018-09-13 <CAGHTAeMkTMRe+nMAxW_2sMPPraMoBMTnbvZVa=SmXX4Ci1S+fA@mail.gmail.com> > You should think of using PostgreSQL native replication to a standby pod on > another kubernetes node. patroni supports kubernetes, have a look at that. Christoph
Em qui, 13 de set de 2018 às 11:39, Christoph Berg <myon@debian.org> escreveu:
Re: Flavio Henrique Araque Gurgel 2018-09-13 <CAGHTAeMkTMRe+nMAxW_2sMPPraMoBMTnbvZVa=SmXX4Ci1S+fA@mail.gmail.com>
> You should think of using PostgreSQL native replication to a standby pod on
> another kubernetes node.
patroni supports kubernetes, have a look at that.
Thanks for your contributions to the community Christoph, patroni is a fine piece of software.
To help the OP to take his decisions, a recent post from Josh about the state of databases on containers is here: http://www.databasesoup.com/2018/07/should-i-run-postgres-on-kubernetes_12.html
Best,
Flavio
On 12/09/18 21:11, Prince Pathria wrote: > Hey Alfredo, > > You can set up ceph as back end/data storage for postgres. Moreover > you'll get a better community support as well. > I'd add a +1 for Ceph as opposed to Gluster. Great community support and a better designed product. Where I work, we run an Openstack Cloud with Ceph as the backing for the block storage provider (Cinder). A number of customers use Postgres and Mysql on this setup. regards Mark
thanks everybody. I don't think we can use ceph (which I would prefere anyway) as we have already glusterFS for other stuff.
thanks heaps
On Thu, Sep 13, 2018 at 12:05 PM Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote:
On 12/09/18 21:11, Prince Pathria wrote:
> Hey Alfredo,
>
> You can set up ceph as back end/data storage for postgres. Moreover
> you'll get a better community support as well.
>
I'd add a +1 for Ceph as opposed to Gluster. Great community support and
a better designed product.
Where I work, we run an Openstack Cloud with Ceph as the backing for the
block storage provider (Cinder). A number of customers use Postgres and
Mysql on this setup.
regards
Mark
Alfredo
Using k8s you'll get the best performance and reliability using a pvc (persistent volume claim) with something like an EBS volume. NFS has historically performed horrible for us.
On Thu, Sep 13, 2018, 4:38 AM Alfredo De Luca <alfredo.deluca@gmail.com> wrote:
thanks everybody. I don't think we can use ceph (which I would prefere anyway) as we have already glusterFS for other stuff.thanks heapsOn Thu, Sep 13, 2018 at 12:05 PM Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote:On 12/09/18 21:11, Prince Pathria wrote:
> Hey Alfredo,
>
> You can set up ceph as back end/data storage for postgres. Moreover
> you'll get a better community support as well.
>
I'd add a +1 for Ceph as opposed to Gluster. Great community support and
a better designed product.
Where I work, we run an Openstack Cloud with Ceph as the backing for the
block storage provider (Cinder). A number of customers use Postgres and
Mysql on this setup.
regards
Mark--Alfredo
The information contained in this email message is PRIVATE and intended only for the personal and confidential use of the recipient named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by email, and delete the original message.