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

Daniel.Crespo at l-3com.com Daniel.Crespo at l-3com.com
Thu Dec 11 15:07:18 UTC 2008


Hello,

I have the exact same doubt. However, in my system,  appservers "A" and
"B" don't run at the same time. While "A" is active, "B" is inactive and
viceversa. In the case "A" becomes unavailable, "B" takes over. So, the
scenario in this case would be:

Pgpool in both appservers are running and connected to Master DB. Each
pgpool instance can be accessed at any time, but the application running
on each server will do stuff with its local pgpool only if it becomes
active. So, for example:

1. Network connection between "A" and Master DB goes down.
2. "A" application still runs and connects to pgpool, which detects the
failure and issues failover.
3. "A" app is interacting with Backup DB through its local Pgpool.

4. "A" app goes down.
5. "B" takes over.
6. "B" app is still connected to its local pgpool which has no problems
connecting to Master DB.
7. While "A" already saved data into Backup DB, "B" is saving into
Master DB.

Result: inconsistency.

I think it's kind of the same problem. Any workaround?

Thanks,
Daniel

-----Original Message-----
From: pgpool-general-bounces at pgfoundry.org
[mailto:pgpool-general-bounces at pgfoundry.org] On Behalf Of Duco Fijma
Sent: Thursday, December 11, 2008 9:34 AM
To: pgpool-general at pgfoundry.org
Subject: [Pgpool-general] inconsistency when using two pgpool instances
inwarm standby?

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. 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.

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


More information about the Pgpool-general mailing list