Re: pgpool question - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: pgpool question
Date
Msg-id 20050310.133559.132935630.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: pgpool question  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: pgpool question
List pgsql-hackers
> On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
> 
> >> I'm experimenting with pgpool 2.51 on my Linux box runnung
> >> two postgresql backends: pg74:5432 and pg801:5433
> >>
> >> I configured pgpool to use pg74:5432 as primary backend and
> >> pg801:5433 as second one. Pgpool is running on default port (9999) and
> >> I configured my web application to use it, so I could start/stop backends
> >> without disturbing client (web browser).
> >>
> >> When I stop primary backend (pg74:5432) pgpool switched to backend
> >>      failover from (5432) to (5433) done
> >> but when I start primary and stopped secondary backend pgpool
> >> never switched back to primary backend as expected !
> >> I see bogus message like:
> >>      starting failover from (5433) to (5433)
> >>
> >> What I'm doing  wrong ?
> >
> > That's an intended behavior. Or at least a side effect of failover
> > design. If we allow unlimited switching between the master and the
> > secondary, pgpool could repeat switching forever if we have unliable
> > network or hardware.
> 
> You may recognize manual action of DBA, that is why '-s m switch' is needed !
> 
> 
> >
> > However it would be easy to modify pgpool to allow automatic switch
> > back (with a risk of unwanted repeating switching, of course). Is
> > this what you want?
> 
> No, your arguments are important. I don't want too much intelligence, but
> when I restart primary backend by hand I don't see any problem to
> switch pgpool back using -s m switch (also by hand). For brave, probably,
> something like --auto would fine.

Problem is, the communication infrastructure between pgpool master
process and another pgpool process which you started by hand to switch
is very poor. Currently signal is used to tell the pgpool master
process to switch/fail over. Apparently we need more info (for example
the signal is sent by DBA, not because of a failure detected by a
pgpool child process).

To fix the problem we need shared memory, pipe, socket or whatever
to pass info and it will not be a trivial fix so will take some
time...
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: pgpool question
Next
From: Oleg Bartunov
Date:
Subject: Re: pgpool question