> I truly believe that this problem – HA – is PostgreSQL's, not 3rd > party's. And it's a shame that Postgres itself doesn't solve this. So > we're discussing it here. Let's see what other subscribers on this forum say. >> > What if pg1 is currently primary, pg0 is standby, both are healthy, but >> > due not network issues, both pg1 and w2 are not reachable to other >> > nodes? Will pg1 remain primary, and w0 and w1 decide to promote pg0? >> >> pg1 will remain primary but it is set to "quarantine" state from >> pgpool's point of view, which means clients cannot access pg1 via >> pgpool. > > So we have a split brain here – two primaries. Especially if some > clients communicate with PG directly. Clients are not allowed to communicate with PostgreSQL directory. That's the prerequisite of using Pgpool-II. > And even if there are no such > clients, archive_command is going to > work on both nodes, What's the problem with this? Moreover you can write a logic to disable this in the failover command. > monitoring will show two primaries confusing > humans (e.g, SREs) and various systems, That's why pgpool provides its own monitoring tools. Clustering system is different from standalone PostgreSQL. Existing PostgreSQL tools usually only take account of stand alone PostgreSQL. Users have to realize the difference. > if we have many standby nodes, > some of them might continue replicating from the old primary if they > happen to be in the same network partition, and so on. As of pg0 and existing standby in the same network as pg0, you can either manually or automatically make them to follow pg0. Best reagards, -- Tatsuo Ishii SRA OSS LLC English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
