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

[Tatsuo Ishii]

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