From: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> |
---|---|
To: | Azimuddin Mohammed <azimeiu(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres HA |
Date: | 2018-01-05 19:32:10 |
Message-ID: | 44BD5CED-CA02-458D-B84E-133BCD9F6DE0@icloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
There are many different solutions; but I would recommend and use a least a three node cluster using synchronous replication where one of the nodes is acting as the witness — at a minimum (actual have more replicas). The witness node need not be a full Postgres instance; it can also be achieved by using pg_recievexlog as the witness instead. This setup avoids a the split brain situation by making sure there is only one writable instance and that is the one that the witness is following.
I use CARP (Common Address Redundancy Protocol) to manage the HA IP address (very platform specific); when the address flips over to a replica it automatically promotes the replica and witness follows the HA address thus signing off on the self promotion.
The old primary then needs to be reconfigured as a replia which can be done using pg_rewind or other numerous other solutions; i.e. snapshots, backup, etc.
I have not personally used this solution; but you could look at 2ndQuadrant repmgr product if you’re looking a packaged solution.
https://www.2ndquadrant.com/en/resources/repmgr/installation-instructions/
From | Date | Subject | |
---|---|---|---|
Next Message | Jehan-Guillaume (ioguix) de Rorthais | 2018-01-05 21:00:42 | Re: Postgres HA |
Previous Message | Scott Marlowe | 2018-01-05 19:18:56 | Re: Postgres HA |
From | Date | Subject | |
---|---|---|---|
Next Message | Travis Allison | 2018-01-05 19:57:18 | Re: What generates pg_config.h? |
Previous Message | Scott Marlowe | 2018-01-05 19:18:56 | Re: Postgres HA |