> 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