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

[Tatsuo Ishii]

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

As I said in the previous mail, when PostgreSQL goes down, any
transaction receives an error status "FATAL: terminating connection
due to administrator command" from it.
--
Tatsuo Ishii

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