Re: Postgres HA

From: John Scalia <jayknowsunix(at)gmail(dot)com>
To: "Jehan-Guillaume (ioguix) de Rorthais" <ioguix(at)free(dot)fr>
Cc: Azimuddin Mohammed <azimeiu(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: Postgres HA
Date: 2018-01-06 01:07:16
Message-ID: A4616F90-BD93-4FEE-B2D8-016B3E59931C@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general

What he said, and you also may want to look at pgpool-II. I’ve had fairly good luck with that and Tatsuo (the author) hangs out here occasionally too.

Jay

Sent from my iPad

> On Jan 5, 2018, at 4:00 PM, Jehan-Guillaume (ioguix) de Rorthais <ioguix(at)free(dot)fr> wrote:
>
> On Fri, 5 Jan 2018 13:07:10 -0600
> Azimuddin Mohammed <azimeiu(at)gmail(dot)com> wrote:
>
>> Hello,
>> I am little confused with how HA works in postgres. Reading the article
>> which state as below "*If the primary server fails and the standby server
>> becomes the new primary, and then the old primary restarts, you must have a
>> mechanism for informing the old primary that it is no longer the primary.
>> This is sometimes known as STONITH (Shoot The Other Node In The Head),
>> which is necessary to avoid situations where both systems think they are
>> the primary, which will lead to confusion and ultimately data loss.*
>>
>> *Many failover systems use just two systems, the primary and the standby,
>> connected by some kind of heartbeat mechanism to continually verify the
>> connectivity between the two and the viability of the primary. It is also
>> possible to use a third system (called a witness server) to prevent some
>> cases of inappropriate failover, but the additional complexity might not be
>> worthwhile unless it is set up with sufficient care and rigorous testing.*
>> *PostgreSQL does not provide the system software required to identify a
>> failure on the primary and notify the standby database server. Many such
>> tools exist and are well integrated with the operating system facilities
>> required for successful failover, such as IP address migration."*
>>
>> Can someone explain how the HA failback will take place
>
> The failback need either to rebuild the old master as a standby (rsync,
> pg_basebackup, restore PITR, ...) or to use pg_rewind to rewind the old master
> to a point where it can catch up with the new master.
>
> Some tools tries to automate failback using pg_rewind (patroni, repmgr), but I
> have no experience with them.
>
>> and what open source tools we can use to make sure once the primary server
>> which failed over to slave will mark itself as slave.
>
> There's a lot of open source tools to build some HA around PgSQL: Repmgr,
> Patroni (based on etcd or zookeeper), PAF (based on Pacemaker), etc. You will
> have to spend a lot of time to make extensive tests, understand them, pick one
> and document your cluster.
>
> Regards,
>

In response to

  • Re: Postgres HA at 2018-01-05 21:00:42 from Jehan-Guillaume (ioguix) de Rorthais

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tatsuo Ishii 2018-01-06 02:09:31 Re: Postgres HA
Previous Message Jehan-Guillaume (ioguix) de Rorthais 2018-01-05 21:00:42 Re: Postgres HA

Browse pgsql-general by date

  From Date Subject
Next Message Tatsuo Ishii 2018-01-06 02:09:31 Re: Postgres HA
Previous Message Adrian Klaver 2018-01-05 23:40:06 Re: What generates pg_config.h?