[pgpool-general: 3932] Re: "replication" mode inconsistencies

Jose Baez pepote at gmail.com
Thu Aug 6 18:48:36 JST 2015


One idea to make Pgpool not depend on any status file....

Could pgpool2 check/compare the last query's timestamp saved in the
postgresql log file of both nodes?




On 6 August 2015 at 08:24, Tatsuo Ishii <ishii at postgresql.org> wrote:

> No. It measn both replication_mode and master_slave_mode = off.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
> > "we need to remove this part except in "raw mode", in which database
> > incosistency problem will not happen."
> >
> > Raw mode means 'connection_cache=off' ?
> > El 06/08/2015 02:30, "Tatsuo Ishii" <ishii at postgresql.org> escribió:
> >
> >> It appeared that the behavior (if all backend are down, pgpool_status
> >> is ignored) is intentional.
> >>
> >> From src/main/pgpool_main.c:
> >>
> >>         /*
> >>          * If no one woke up, we regard the status file bogus
> >>          */
> >>         if (someone_wakeup == false)
> >>         {
> >>                 for (i=0;i< pool_config->backend_desc->num_backends;i++)
> >>                 {
> >>                         BACKEND_INFO(i).backend_status =
> CON_CONNECT_WAIT;
> >>                 }
> >>                 (void)write_status_file();
> >>         }
> >>
> >> Here is the commit log:
> >> -------------------------------------------------------------
> >> commit a97eed16ef8c3a481c0cd0282b9950fb4ee28a89
> >> Author: Tatsuo Ishii <ishii at sraoss.co.jp>
> >> Date:   Sat Feb 13 11:23:55 2010 +0000
> >>
> >>     Fix read_status_file so that if all nodes were marked down status,
> >>     it is regarded that this file is bogus. This will prevent "all
> >>     node down" syndrome.
> >> -------------------------------------------------------------
> >>
> >> The decision was made long time ago by me, but now I think this was
> >> not correct decision as you pointed out. I think we need to remove
> >> this part except in "raw mode", in which database incosistency problem
> >> will not happen.
> >>
> >> Best regards,
> >> --
> >> Tatsuo Ishii
> >> SRA OSS, Inc. Japan
> >> English: http://www.sraoss.co.jp/index_en.php
> >> Japanese:http://www.sraoss.co.jp
> >>
> >> > Thank you.  I've confirmed that if only *one* of the two servers is
> >> > unreachable, pgpool behaves as expected (waits for the server to be
> >> > manually reattached).
> >> >
> >> > Although I wonder also, even if pgpool *did* correctly refuse to send
> >> > traffic if both servers were "down" in pgpool_status on restart, how
> >> > should we know in which direction to recover data (from A to B or B to
> >> > A)?  Pgpool does not record in pgpool_status which "down" server was
> >> > the last to go down (and is thus authoritative).  As a workaround I
> >> > think it would work to write a failover/failback_command which records
> >> > this information.
> >> >
> >> > On Wed, Aug 5, 2015 at 6:59 PM, Tatsuo Ishii <ishii at postgresql.org>
> >> wrote:
> >> >> Pgpool should recognize that both A and B are in down status, but
> >> >> actually not. Let me investigate...
> >> >>
> >> >> Best regards,
> >> >> --
> >> >> Tatsuo Ishii
> >> >> SRA OSS, Inc. Japan
> >> >> English: http://www.sraoss.co.jp/index_en.php
> >> >> Japanese:http://www.sraoss.co.jp
> >> >>
> >> >>> Consider the following sequence, starting from a healthy system of
> two
> >> >>> PG servers (A and B) joined in "replication" mode:
> >> >>>
> >> >>> 1) Server A loses connectivity.
> >> >>> 2) A write comes in, which pgpool commits to server B.
> >> >>> 3) Server B loses connectivity.
> >> >>> 4) Server A regains connectivity.
> >> >>> 5) pgpool restarts (due to either sysadmin action or failure).
> >> >>>
> >> >>> At this point, pgpool happily directs all traffic to server A, which
> >> >>> does *not* have the most recent commit to server B.  This is very
> bad
> >> >>> since I have now lost data consistency.
> >> >>>
> >> >>> Rather, I would expect that pgpool remembers that it has written
> data
> >> >>> to B but not to A, and would refuse incoming connections until A has
> >> >>> been recovered from B.
> >> >>>
> >> >>> Even to workaround, if before restarting pgpool, I had some tool
> which
> >> >>> checked the state in which pgpool left the two servers and then
> >> >>> rectified them, that would suffice.  However since pgpool doesn't
> seem
> >> >>> to track at all the fact that it had written some data only to B but
> >> >>> not to A, that information is not available (e.g. from
> pgpool_status).
> >> >>>
> >> >>> What am I missing?  How is it that others use pgpool in
> "replication"
> >> >>> mode without encountering data inconsistencies when nodes fail?
> >> >>> _______________________________________________
> >> >>> pgpool-general mailing list
> >> >>> pgpool-general at pgpool.net
> >> >>> http://www.pgpool.net/mailman/listinfo/pgpool-general
> >> _______________________________________________
> >> pgpool-general mailing list
> >> pgpool-general at pgpool.net
> >> http://www.pgpool.net/mailman/listinfo/pgpool-general
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20150806/3f3ae07c/attachment-0001.html>


More information about the pgpool-general mailing list