[Pgpool-general] inconsistency when using two pgpool instances in warm standby?

[Tatsuo Ishii]

> Hello,
> 
> I'm designing a warm-standby Postgres/pgpool system accepting 
> connections from a number of application servers.
> 
> Of course, running a single instance of pgpool introduces a single point 
> of failure.

To avoid the SPOF, you could use pgpool-HA or whatever Hot/Standby
additional software to construct pgpool HA cluster.

> However, I'm having difficulties seeing how multiple 
> instances of pgpool, in general, can have a consistent picture of the 
> (failure) state of the "master" database.

Yes, I had gotten this kind of questions many times. So I talked to
someone who are familiar with networking. Suggestions from him was:

1) use bonding/teaming between pgpool("A" or "B") and switch. This
   will virtualy make networking down between them never happen.

2) we don't need to care about networking failure between db servers
   and switch since if it goes down, each pgpool instance will do the
   same failover anyway.

3) any failure inside switch does not likely cause the scenario you
   mentioned.

Hope this helps,
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> For example, consider two appservers "A" and "B", both running an 
> instance of pgpool. Additionally, we have a master postgres database 
> server and a standby postgres database server.
> 
> In that situation, the network connection between "B" and the master 
> database server is going down. The pgpool instance on B detect a failure 
> and triggers a failover to the standby server, which therefore exits 
> recovery mode and starts accepting database connections.
> 
> Especially in a design without single points of failure, the network 
> connection between appserver "A" and the master database is likely not 
> to be failing at the same time. Therefore, from the perspective of 
> appserver "A" the master database is not failing at all. Its pgpool 
> instance therefore happily continues to proxy database connections to 
> the master database.
> 
> The net effect is that our system is broken into two independent halves. 
> It just takes one database transaction to make these two halves into two 
> inconsistent systems :)
> 
> I find it difficult to think of a solutions to this. Whatever schema I 
> use, the very same failure that caused the database failover in the 
> first place, can or will also hinder (direct or indirect) communication 
> between the two pgpool instances to prevent inconsistent failover states.
> 
> --
> Duco
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general