[Pgpool-general] RE: Bad degeneration when shutting down secondary backend

[Pablo Milano]

It might help if I had only one application server with two database
servers. Unfortunately that's not my case. 
My environment consists of two application servers ("app-A" and "app-B") and
two database servers ("db-A" and "db-B"). Each application server runs
pgpool to the same pair of database backends. In both servers, "db-A" is
defined as master and "db-B" as secondary, in order to tell both pgpools to
shut down the same backend in case of data inconsistence.
As it's hard to syncronize both pgpools to invoke a switch at exactly the
same time, the following problem may arise:

If I issue a switch in application server "app-A" to shut down secondary
backend "db-B", then "app-B" will continue replicating (at least for a
while) and soon will detect data inconsistence, so, it will arise
degeneration mode and will shut down master backend "db-A". As a result,
"app-A" will point to "db-A" and "app-B" will point to "db-B"


Note: All of this, only happens if the environment has continue "heavy" (3
tps) transaction load. When testing the same conditions with "light" (< 1
tps) transaction load, pgpool behavies correctly. ¿May I do some further
research? ¿Why exactly pgpool detects a database shutdown as data
inconsistency?.





> -----Original Message-----
> From: Tatsuo Ishii [mailto:t-ishii at sra.co.jp] 
> Sent: Jueves, 18 de Agosto de 2005 07:27 p.m.
> To: Pablo G. Milano
> Cc: pgpool-general at pgfoundry.org
> Subject: Re: Bad degeneration when shutting down secondary backend
> 
> > > Unfortunately pgpool's data difference detection is not 
> perfect, and
> > > sometimes it raise false alarm. That's why I recommend setting
> > > replication_stop_on_mismatch to false.
> > 
> > The point here is that, if I shut down the secondary 
> backend in a working
> > production environment, degeneration mode performs in the wrong way
> > (shutting down the master backend instead of the 
> secondary). As a result,
> > the entire environment would be down (secondary is down and 
> master is shut
> > down by pgpool).
> > This behaviour may be avoided by setting 
> "replication_stop_on_mismatch" to
> > false, but on the other hand, if a real data mismatch 
> exist, it won't be
> > detected.
> > Is there any other way to avoid pgpool detection of a data 
> mismatch when one
> > backend is being shut down?
> 
> If it's a schedule down time, you could use "switch" to tell pgpool
> explicitly the secondary server is going down.
> 
> $ pgpool -s secondary switch
> 
> Does this help?
> --
> Tatsuo Ishii
>