No subject
Fri Jan 30 20:15:43 JST 2015
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If no one woke up, we regard the status=
file bogus<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (someone_wakeup =3D=3D false)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (i=3D0;i< po=
ol_config->backend_desc->num_backends;i++)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 BACKEND_INFO(i).backend_status =3D CON_CONNECT_WAIT;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (void)write_status_=
file();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
<br>
Here is the commit log:<br>
-------------------------------------------------------------<br>
commit a97eed16ef8c3a481c0cd0282b9950fb4ee28a89<br>
Author: Tatsuo Ishii <ishii at <a href=3D"http://sraoss.co.jp" rel=3D"no=
referrer" target=3D"_blank">sraoss.co.jp</a>><br>
Date:=C2=A0 =C2=A0Sat Feb 13 11:23:55 2010 +0000<br>
<br>
=C2=A0 =C2=A0 Fix read_status_file so that if all nodes were marked down st=
atus,<br>
=C2=A0 =C2=A0 it is regarded that this file is bogus. This will prevent &qu=
ot;all<br>
=C2=A0 =C2=A0 node down" syndrome.<br>
-------------------------------------------------------------<br>
<br>
The decision was made long time ago by me, but now I think this was<br>
not correct decision as you pointed out. I think we need to remove<br>
this part except in "raw mode", in which database incosistency pr=
oblem<br>
will not happen.<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href=3D"http://www.sraoss.co.jp/index_en.php" rel=3D"noreferrer=
" target=3D"_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href=3D"http://www.sraoss.co.jp" rel=3D"noreferrer" target=3D"_=
blank">http://www.sraoss.co.jp</a><br>
<br>
> Thank you.=C2=A0 I've confirmed that if only *one* of the two serv=
ers is<br>
> unreachable, pgpool behaves as expected (waits for the server to be<br=
>
> manually reattached).<br>
><br>
> Although I wonder also, even if pgpool *did* correctly refuse to send<=
br>
> traffic if both servers were "down" in pgpool_status on rest=
art, how<br>
> should we know in which direction to recover data (from A to B or B to=
<br>
> A)?=C2=A0 Pgpool does not record in pgpool_status which "down&quo=
t; server was<br>
> the last to go down (and is thus authoritative).=C2=A0 As a workaround=
I<br>
> think it would work to write a failover/failback_command which records=
<br>
> this information.<br>
><br>
> On Wed, Aug 5, 2015 at 6:59 PM, Tatsuo Ishii <<a href=3D"mailto:ish=
ii at postgresql.org">ishii at postgresql.org</a>> wrote:<br>
>> Pgpool should recognize that both A and B are in down status, but<=
br>
>> actually not. Let me investigate...<br>
>><br>
>> Best regards,<br>
>> --<br>
>> Tatsuo Ishii<br>
>> SRA OSS, Inc. Japan<br>
>> English: <a href=3D"http://www.sraoss.co.jp/index_en.php" rel=3D"n=
oreferrer" target=3D"_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> Japanese:<a href=3D"http://www.sraoss.co.jp" rel=3D"noreferrer" ta=
rget=3D"_blank">http://www.sraoss.co.jp</a><br>
>><br>
>>> Consider the following sequence, starting from a healthy syste=
m of two<br>
>>> PG servers (A and B) joined in "replication" mode:<b=
r>
>>><br>
>>> 1) Server A loses connectivity.<br>
>>> 2) A write comes in, which pgpool commits to server B.<br>
>>> 3) Server B loses connectivity.<br>
>>> 4) Server A regains connectivity.<br>
>>> 5) pgpool restarts (due to either sysadmin action or failure).=
<br>
>>><br>
>>> At this point, pgpool happily directs all traffic to server A,=
which<br>
>>> does *not* have the most recent commit to server B.=C2=A0 This=
is very bad<br>
>>> since I have now lost data consistency.<br>
>>><br>
>>> Rather, I would expect that pgpool remembers that it has writt=
en data<br>
>>> to B but not to A, and would refuse incoming connections until=
A has<br>
>>> been recovered from B.<br>
>>><br>
>>> Even to workaround, if before restarting pgpool, I had some to=
ol which<br>
>>> checked the state in which pgpool left the two servers and the=
n<br>
>>> rectified them, that would suffice.=C2=A0 However since pgpool=
doesn't seem<br>
>>> to track at all the fact that it had written some data only to=
B but<br>
>>> not to A, that information is not available (e.g. from pgpool_=
status).<br>
>>><br>
>>> What am I missing?=C2=A0 How is it that others use pgpool in &=
quot;replication"<br>
>>> mode without encountering data inconsistencies when nodes fail=
?<br>
>>> _______________________________________________<br>
>>> pgpool-general mailing list<br>
>>> <a href=3D"mailto:pgpool-general at pgpool.net">pgpool-general at pg=
pool.net</a><br>
>>> <a href=3D"http://www.pgpool.net/mailman/listinfo/pgpool-gener=
al" rel=3D"noreferrer" target=3D"_blank">http://www.pgpool.net/mailman/list=
info/pgpool-general</a><br>
_______________________________________________<br>
pgpool-general mailing list<br>
<a href=3D"mailto:pgpool-general at pgpool.net">pgpool-general at pgpool.net</a><=
br>
<a href=3D"http://www.pgpool.net/mailman/listinfo/pgpool-general" rel=3D"no=
referrer" target=3D"_blank">http://www.pgpool.net/mailman/listinfo/pgpool-g=
eneral</a><br>
</blockquote></div>
--001a1134633a448431051c9f5b63--
More information about the pgpool-general
mailing list