On Fri, Jan 5, 2018 at 12:07 PM, Azimuddin Mohammed <azim...@gmail.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 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 are LOTS of ways to implement HA. Here's a book on the subject that's 537 pages long, and is only $4.99 right now: https://www.packtpub.com/big-data-and-business-intelligence/postgresql-high-availability-cookbook-second-edition I've been reading it a bit, seems to be a good resource. -- To understand recursion, one must first understand recursion.
