Mailing List Archive

$BBg^<$5$s(B

$B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
$B$4L5:;BA$7$F$*$j$^$9!#(B

PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G$9!#(B
max_wal_senders :
https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
max_connections $B$*$h$S(B superuser_reserved_connections :
https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html

$B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now() )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
$B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error (connection
to the server went bad and the session was not interactive) occurred
while executing the psql command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B

$B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(Bmonitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
$B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
$B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_Dj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B

$BM>CL$G$9$,(BPostgreSQL 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
$B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b$7$l$^$;$s!#(B

----
Takehiro Matsushima



2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
> $B3F0L(B
>
> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
> $BBg^<$H?=$7$^$9!#(B
>
> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>
> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>
> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>
> $B4D6-$O0J2<$NDL$j$G$9!#(B
> CentOS5
> PostgreSQL9.2.4
> Pacemaker1.0.13-1.1
> Master/Slave$B9=@.(B
> $B0J>e(B
>
> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>
> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients already
> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL template1 isn't
> running
> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
> (connection to the server went bad and the session was not interactive)
> occurred while executing the psql command.
> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info: process_lrm_event:
> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
> confirmed=false) unknown error
> $B0J>e(B
>
> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
> $B$$$k$h$&$K;W$o$l$^$9!#(B
>
> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B max_connections=100$B$N>uBV$,B3$$$F$7$^(B
> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>
> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$B>>Eg$5$s(B

$B$*@$OC$K$J$C$F$*$j$^$9!#(B
$BBg^<$G$9!#(B

$B$4L5:;BA$7$F$^$9!*(B
$B$^$?<!2s$N(BOSC$B$KM7$S$K9T$3$&$+$H;W$C$F$^$9!#(B

$BAaB.$NJV?.$"$j$,$H$&$4$6$$$^$9!#(B
$BBgJQ=u$+$j$^$9!#(B

max_connections$B$N@_Dj$,%G%U%)%k%H$N(B100$B$@$C$?$N$,LdBj$@$C$?$s$G$9$M!#(B
WEB$B%5!<%P!<B&$N@_Dj$H(BDB$BB&$N@_Dj$KAj0c$,$"$C$?$h$&$J$N$G!":#2s$O(B
max_connections$B$rE,@Z$J?tCM$K9g$o$;$kJ}8~$GBP=h$7(B $B$h$&$H;W$$$^$9!#(B
$B$A$J$_$K(Bsuperuser_reserved_connections$B$O%3%a%s%H%"%&%H$5$l$F$$$^$7$?!#(B

$B:#;H$C$F$$$k%5!<%P!<<+BN$,MhG/$"$?$j$K$O%j%W%l%$%9$K$J$k$+$b$7$l$^$;$s$N(B
$B$G!"$=$N:]$K$O(Bpg_isready$B$bD4$Y$F$_$h$&$+$H;W$$$^(B $B$9!#(B

$B$H$3$m$G!":#2s$?$^$?$^%U%'%$%k%*!<%P!<$7$F$$$?$3$H$K5$$E$$$?$N$G$9$,!"$_(B
$B$J$5$s$O$I$N$h$&$K%U%'%$%k%*!<%P!<$r8!CN$7$F$$$k$N$G$7$g$&(B $B$+!#(B

$B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B

On 2015/08/26 2:17, Takehiro Matsushima wrote:
> $BBg^<$5$s(B
>
> $B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
> $B$4L5:;BA$7$F$*$j$^$9!#(B
>
> PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G$9!#(B
> max_wal_senders :
> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
> max_connections $B$*$h$S(B superuser_reserved_connections :
> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>
> $B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
> RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now() )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
> $B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error (connection
> to the server went bad and the session was not interactive) occurred
> while executing the psql command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B
>
> $B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(Bmonitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
> $B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
> $B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_Dj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B
>
> $BM>CL$G$9$,(BPostgreSQL 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
> $B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b$7$l$^$;$s!#(B
>
> ----
> Takehiro Matsushima
>
>
>
> 2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>> $B3F0L(B
>>
>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>> $BBg^<$H?=$7$^$9!#(B
>>
>> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
>> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
>> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>>
>> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>>
>> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>
>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>> CentOS5
>> PostgreSQL9.2.4
>> Pacemaker1.0.13-1.1
>> Master/Slave$B9=@.(B
>> $B0J>e(B
>>
>> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
>> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>>
>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients already
>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL template1 isn't
>> running
>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
>> (connection to the server went bad and the session was not interactive)
>> occurred while executing the psql command.
>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info: process_lrm_event:
>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
>> confirmed=false) unknown error
>> $B0J>e(B
>>
>> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
>> $B$$$k$h$&$K;W$o$l$^$9!#(B
>>
>> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B max_connections=100$B$N>uBV$,B3$$$F$7$^(B
>> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>>
>> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$BBg^<$5$s(B

$B>>Eg$G$9!#(B
OSC 2015 Tokyo/Fall$B$G$*2q$$$G$-$k$3$H$r3Z$7$_$K$7$F$*$j$^$9!*(B


Web$B%5!<%P!<(B($B@53N$K$O(BAP$B%5!<%P!<(B)$B$,(BDB$B$KBP$7$F$$$/$D$N%3%M%/%7%g%s$rD%$k$+$H$$$&$3$H$rK\Ev$O7W;;$7$F$*$/I,MW$,$"$j$^$9!#(B
AP$B$"$?$j$N%3%M%/%7%g%s?t!"(BAP$BBf?t!"FbItE*$K@8$8$k%3%M%/%7%g%s?t!"DL>o4IM}MQ$KI,MW$J%3%M%/%7%g%s?t!"(BDB$B$N%j%=!<%9!"(BAP$B$N%j%=!<%9$J$I$+$iCM$r7h$a$F$$$/$3$H$K$J$k$H$*$b$$$^$9!#(B

pg_isready$B$G$9$,!"8=>u$N(Bpgsql RA$B$OL$BP1~$G$9$N$G!"(BRA$B$r2~=$$7$F$_$k$N$b3Z$7$$$H;W$$$^$9!#(B

$B%U%'%$%k%*!<%P!<$N8!CN$G$9$,!";d$O(BMailTo RA$B$r;HMQ$7$F%a!<%kDLCN$r$9$k$h$&$K$7$F$$$^$9!#(B
Zabbix$BEy$N4F;k%=%j%e!<%7%g%s$G%W%m%;%94F;k$7$?$j%+%9%?%`%3%^%s%I$G4F;k$7$?$j!"$b$7$/$O(BSNMP$B$r;HMQ$9$k$N$b$h$$$H;W$$$^$9!#(B
$B;~4VE*$KM>M5$,$"$k$N$G$7$?$i$$$m$$$m;n$7$F$_$F!":G=*E*$K7hDj$7$F$$$?$@$/$N$,$b$A$m$s:GA1$@$H$O;W$$$^$9$,!"B(@J$G$H$$$&$3$H$G$7$?$i$H$j$"$($:(BMailTo
RA$B$,;H$$$d$9$$0u>]$G$9!#(B
$B$<$R$*;n$7$/$@$5$$!#(B

$B0J>e$h$m$7$/$*4j$$$$$?$7$^$9!#(B

----
Takehiro Matsushima

2015$BG/(B8$B7n(B26$BF|(B 10:32 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
> $B>>Eg$5$s(B
>
> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
> $BBg^<$G$9!#(B
>
> $B$4L5:;BA$7$F$^$9!*(B
> $B$^$?<!2s$N(BOSC$B$KM7$S$K9T$3$&$+$H;W$C$F$^$9!#(B
>
> $BAaB.$NJV?.$"$j$,$H$&$4$6$$$^$9!#(B
> $BBgJQ=u$+$j$^$9!#(B
>
> max_connections$B$N@_Dj$,%G%U%)%k%H$N(B100$B$@$C$?$N$,LdBj$@$C$?$s$G$9$M!#(B
> WEB$B%5!<%P!<B&$N@_Dj$H(BDB$BB&$N@_Dj$KAj0c$,$"$C$?$h$&$J$N$G!":#2s$O(B
> max_connections$B$rE,@Z$J?tCM$K9g$o$;$kJ}8~$GBP=h$7(B $B$h$&$H;W$$$^$9!#(B
> $B$A$J$_$K(Bsuperuser_reserved_connections$B$O%3%a%s%H%"%&%H$5$l$F$$$^$7$?!#(B
>
> $B:#;H$C$F$$$k%5!<%P!<<+BN$,MhG/$"$?$j$K$O%j%W%l%$%9$K$J$k$+$b$7$l$^$;$s$N(B
> $B$G!"$=$N:]$K$O(Bpg_isready$B$bD4$Y$F$_$h$&$+$H;W$$$^(B $B$9!#(B
>
> $B$H$3$m$G!":#2s$?$^$?$^%U%'%$%k%*!<%P!<$7$F$$$?$3$H$K5$$E$$$?$N$G$9$,!"$_(B
> $B$J$5$s$O$I$N$h$&$K%U%'%$%k%*!<%P!<$r8!CN$7$F$$$k$N$G$7$g$&(B $B$+!#(B
>
> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>
> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>> $BBg^<$5$s(B
>>
>> $B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
>> $B$4L5:;BA$7$F$*$j$^$9!#(B
>>
>> PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G$9!#(B
>> max_wal_senders :
>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>> max_connections $B$*$h$S(B superuser_reserved_connections :
>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>
>> $B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
>> RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now() )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
>> $B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error (connection
>> to the server went bad and the session was not interactive) occurred
>> while executing the psql command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B
>>
>> $B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(Bmonitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
>> $B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
>> $B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_Dj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B
>>
>> $BM>CL$G$9$,(BPostgreSQL 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>> $B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b$7$l$^$;$s!#(B
>>
>> ----
>> Takehiro Matsushima
>>
>>
>>
>> 2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>> $B3F0L(B
>>>
>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>> $BBg^<$H?=$7$^$9!#(B
>>>
>>> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
>>> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
>>> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>>>
>>> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>>>
>>> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>
>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>> CentOS5
>>> PostgreSQL9.2.4
>>> Pacemaker1.0.13-1.1
>>> Master/Slave$B9=@.(B
>>> $B0J>e(B
>>>
>>> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
>>> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>>>
>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients already
>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL template1 isn't
>>> running
>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
>>> (connection to the server went bad and the session was not interactive)
>>> occurred while executing the psql command.
>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info: process_lrm_event:
>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
>>> confirmed=false) unknown error
>>> $B0J>e(B
>>>
>>> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
>>> $B$$$k$h$&$K;W$o$l$^$9!#(B
>>>
>>> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B max_connections=100$B$N>uBV$,B3$$$F$7$^(B
>>> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>>>
>>> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$B>>Eg$5$s(B

$B$*@$OC$K$J$C$F$*$j$^$9!#(B
$BBg^<$G$9!#(B

$B$=$&$G$9$M!*;d$b3Z$7$_$K$7$F$$$^$9!*(B

$B$$$m$$$m$H$4;XF3$$$?$@$-$"$j$,$H$&$4$6$$$^$9!#(B
$B$$$D$bBgJQ=u$+$j$^$9!#(B

MailTo RA$B$H$$$&$N$,$"$k$N$G$9$M!#8!:w$7$F$_$^$9!#(B
$B;d$,$"$^$j5;=QE*$KL@$k$/$J$/!";n9T:x8m$G;~4V$,$+$+$j$=$&$J$N$G!"(BZabbix$BEy(B
$B$G$&$^$/4F;k=PMh$J$$$+C4Ev<T$KAjCL$7$F$_$^$9!#(B

$B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B

On 2015/08/26 11:45, Takehiro Matsushima wrote:
> $BBg^<$5$s(B
>
> $B>>Eg$G$9!#(B
> OSC 2015 Tokyo/Fall$B$G$*2q$$$G$-$k$3$H$r3Z$7$_$K$7$F$*$j$^$9!*(B
>
>
> Web$B%5!<%P!<(B($B@53N$K$O(BAP$B%5!<%P!<(B)$B$,(BDB$B$KBP$7$F$$$/$D$N%3%M%/%7%g%s$rD%$k$+$H$$$&$3$H$rK\Ev$O7W;;$7$F$*$/I,MW$,$"$j$^$9!#(B
> AP$B$"$?$j$N%3%M%/%7%g%s?t!"(BAP$BBf?t!"FbItE*$K@8$8$k%3%M%/%7%g%s?t!"DL>o4IM}MQ$KI,MW$J%3%M%/%7%g%s?t!"(BDB$B$N%j%=!<%9!"(BAP$B$N%j%=!<%9$J$I$+$iCM$r7h$a$F$$$/$3$H$K$J$k$H$*$b$$$^$9!#(B
>
> pg_isready$B$G$9$,!"8=>u$N(Bpgsql RA$B$OL$BP1~$G$9$N$G!"(BRA$B$r2~=$$7$F$_$k$N$b3Z$7$$$H;W$$$^$9!#(B
>
> $B%U%'%$%k%*!<%P!<$N8!CN$G$9$,!";d$O(BMailTo RA$B$r;HMQ$7$F%a!<%kDLCN$r$9$k$h$&$K$7$F$$$^$9!#(B
> Zabbix$BEy$N4F;k%=%j%e!<%7%g%s$G%W%m%;%94F;k$7$?$j%+%9%?%`%3%^%s%I$G4F;k$7$?$j!"$b$7$/$O(BSNMP$B$r;HMQ$9$k$N$b$h$$$H;W$$$^$9!#(B
> $B;~4VE*$KM>M5$,$"$k$N$G$7$?$i$$$m$$$m;n$7$F$_$F!":G=*E*$K7hDj$7$F$$$?$@$/$N$,$b$A$m$s:GA1$@$H$O;W$$$^$9$,!"B(@J$G$H$$$&$3$H$G$7$?$i$H$j$"$($:(BMailTo
> RA$B$,;H$$$d$9$$0u>]$G$9!#(B
> $B$<$R$*;n$7$/$@$5$$!#(B
>
> $B0J>e$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>
> ----
> Takehiro Matsushima
>
> 2015$BG/(B8$B7n(B26$BF|(B 10:32 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>> $B>>Eg$5$s(B
>>
>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>> $BBg^<$G$9!#(B
>>
>> $B$4L5:;BA$7$F$^$9!*(B
>> $B$^$?<!2s$N(BOSC$B$KM7$S$K9T$3$&$+$H;W$C$F$^$9!#(B
>>
>> $BAaB.$NJV?.$"$j$,$H$&$4$6$$$^$9!#(B
>> $BBgJQ=u$+$j$^$9!#(B
>>
>> max_connections$B$N@_Dj$,%G%U%)%k%H$N(B100$B$@$C$?$N$,LdBj$@$C$?$s$G$9$M!#(B
>> WEB$B%5!<%P!<B&$N@_Dj$H(BDB$BB&$N@_Dj$KAj0c$,$"$C$?$h$&$J$N$G!":#2s$O(B
>> max_connections$B$rE,@Z$J?tCM$K9g$o$;$kJ}8~$GBP=h$7(B $B$h$&$H;W$$$^$9!#(B
>> $B$A$J$_$K(Bsuperuser_reserved_connections$B$O%3%a%s%H%"%&%H$5$l$F$$$^$7$?!#(B
>>
>> $B:#;H$C$F$$$k%5!<%P!<<+BN$,MhG/$"$?$j$K$O%j%W%l%$%9$K$J$k$+$b$7$l$^$;$s$N(B
>> $B$G!"$=$N:]$K$O(Bpg_isready$B$bD4$Y$F$_$h$&$+$H;W$$$^(B $B$9!#(B
>>
>> $B$H$3$m$G!":#2s$?$^$?$^%U%'%$%k%*!<%P!<$7$F$$$?$3$H$K5$$E$$$?$N$G$9$,!"$_(B
>> $B$J$5$s$O$I$N$h$&$K%U%'%$%k%*!<%P!<$r8!CN$7$F$$$k$N$G$7$g$&(B $B$+!#(B
>>
>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>
>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>> $BBg^<$5$s(B
>>>
>>> $B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
>>> $B$4L5:;BA$7$F$*$j$^$9!#(B
>>>
>>> PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G$9!#(B
>>> max_wal_senders :
>>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>> max_connections $B$*$h$S(B superuser_reserved_connections :
>>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>
>>> $B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
>>> RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now() )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
>>> $B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error (connection
>>> to the server went bad and the session was not interactive) occurred
>>> while executing the psql command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B
>>>
>>> $B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(Bmonitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
>>> $B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
>>> $B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_Dj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B
>>>
>>> $BM>CL$G$9$,(BPostgreSQL 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
>>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>> $B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b$7$l$^$;$s!#(B
>>>
>>> ----
>>> Takehiro Matsushima
>>>
>>>
>>>
>>> 2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>>> $B3F0L(B
>>>>
>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>> $BBg^<$H?=$7$^$9!#(B
>>>>
>>>> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
>>>> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
>>>> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>>>>
>>>> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>>>>
>>>> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>>
>>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>>> CentOS5
>>>> PostgreSQL9.2.4
>>>> Pacemaker1.0.13-1.1
>>>> Master/Slave$B9=@.(B
>>>> $B0J>e(B
>>>>
>>>> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
>>>> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>>>>
>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients already
>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL template1 isn't
>>>> running
>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
>>>> (connection to the server went bad and the session was not interactive)
>>>> occurred while executing the psql command.
>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info: process_lrm_event:
>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
>>>> confirmed=false) unknown error
>>>> $B0J>e(B
>>>>
>>>> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
>>>> $B$$$k$h$&$K;W$o$l$^$9!#(B
>>>>
>>>> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B max_connections=100$B$N>uBV$,B3$$$F$7$^(B
>>>> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>>>>
>>>> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

メトロシステムズ
飯田様

お世話になっております。
大渕です。

情報ありがとうございます！

pm_logconv-hbというのがあるのですね。
テスト機で使ってみて試してみます。
使い方でわからないことがあったらまた問い合わせさせてください。

以上、よろしくお願いいたします。

On 2015/08/27 19:38, Yusuke Iida wrote:
> 大渕さま
>
> メトロシステムズ 飯田です。
>
> LinuxHA Japanではpm_logconv-hbというツールを公開しています。
> このツールは下記の機能を持っています。
> ・クラスタログを読みやすい形に変換する機能
> ・指定したリソースが故障などによりノード間を移動した時に、ログに「フェイルオーバーした」と出力してくれる機能
>
> このフェイルオーバーのログをZabbix等の監視ソフトで監視してみるのはいかがでしょうか？
>
> CentOS5でPacemaker-1.0.13をお使いのようなので、下記のページにあるパッケージを利用すると良いかと思われます。
> https://osdn.jp/projects/linux-ha/releases/61792
>
>
> 以上、よろしくお願いいたします。
>
> 2015年8月27日 19:25 大渕昭夫 <ohbuchi@m2j.co.jp>:
>> 海藤様
>>
>> 大渕です。
>> お世話になっております。
>>
>> 検出方法のご提示ありがとうございます！
>> 確かに今回のサーバーはインターネットに接続できないサーバーです。
>>
>> 海藤様の検出方法はPostgreSQLのフェイルオーバーが発生した時に
>> サーバーのHost名が変わって気づけるという内容でよろしいでしょうか。
>> サーバーの死活監視はZabbix等で実施しているので、サーバーの稼働
>> には問題がない状態でPostgreSQLのフェイルオーバーだけが発生した
>> 場合に気づけるとありがたいです。
>>
>> 以上、よろしくお願いいたします。
>>
>>
>> On 2015/08/27 9:44, 海藤 廣一 wrote:
>>
>> 大渕様、松島様
>>
>> 海藤です。
>> いつもお世話になっております。
>>
>> 割り込んで申し訳ありません。
>> 多分、皆さんには容易に出来ることと思いますが私が実施予定の
>> Ｆ／Ｏ検出方法をご紹介します。
>>
>> 松島様の方法はインターネットに接続されているネットワークでは
>> 非常に有効と思いますが、私の検討しているサーバーは閉じたLAN
>> なので下記の方法となりました。
>>
>> ①サーバー（両Node）にそれぞれUDPサーバープログラム
>> 　を実行させます。
>> 　UDPコマンドでHost名（/etc/hostnameの内容）を応答するもの。
>> ②サーバーにはクラスタリングで仮想IPを両Node設定
>> ③クライアントから両Node(仮想IP)宛にそれぞれHost名要求コマンド
>> 　をUDP送信する。
>> ④クライアントで受信したHost名がそれぞれ正常動作を示して
>> 　いるかどうかを名称で判断する。
>> 　※その都合で、DBS_PRIとDBS_STBというHost名にしています。
>>
>> 出来れば私の作った（おもちゃのような）UDPサーバープログラム
>> をお試しいただければと思いますがいかがでしょう？
>> もともとネットで見つけたサンプルを改造したものなのですが
>> 第三者によるデバッグにもなるので！
>>
>> ★いきなりソースを送りつけても・・・と思いましたので今回は
>> 控えました。
>>
>> 以上です。
>>
>>
>> On Wed, 26 Aug 2015 11:45:27 +0900
>> Takehiro Matsushima <takehiro.dreamizm@gmail.com> wrote:
>>
>> 大渕さん
>>
>> 松島です。
>> OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>>
>>
>> Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張るかということを本当は計算しておく必要があります。
>> APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常管理用に必要なコネクション数、DBのリソース、APのリソースなどから値を決めていくことになるとおもいます。
>>
>> pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるのも楽しいと思います。
>>
>> フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をするようにしています。
>> Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監視したり、もしくはSNMPを使用するのもよいと思います。
>> 時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していただくのがもちろん最善だとは思いますが、即席でということでしたらとりあえずMailTo
>> RAが使いやすい印象です。
>> ぜひお試しください。
>>
>> 以上よろしくお願いいたします。
>>
>> ----
>> Takehiro Matsushima
>>
>> 2015年8月26日 10:32 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>
>> 松島さん
>>
>> お世話になっております。
>> 大渕です。
>>
>> ご無沙汰してます！
>> また次回のOSCに遊びに行こうかと思ってます。
>>
>> 早速の返信ありがとうございます。
>> 大変助かります。
>>
>> max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>> WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>> max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>> ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>
>> 今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませんの
>> で、その際にはpg_isreadyも調べてみようかと思いま す。
>>
>> ところで、今回たまたまフェイルオーバーしていたことに気づいたのですが、み
>> なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>
>> 以上、よろしくお願いいたします。
>>
>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>>
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
>


--
*************************************************
株式会社マネースクウェアHD (M2HD)
【東証第1部：8728】

システム企画部　大渕　昭夫

〒107-6240
東京都港区赤坂9-7-1　ミッドタウン・タワー
TEL：03－3470－5083
FAX：03－3470－5087
HP : http://www.m2hd.co.jp/
E-mail : ohbuchi@m2hd.co.jp

*************************************************

Japanese disclaimer may corrupt due to message encoding.
この株式会社マネースクウェアHDから発信されたメッセージには機密情報や個人情報が
含まれている場合があり、宛先にお名前が明示されている正規の受取人に限りご利用い
ただけます。
送信上の誤操作等により、受信する予定でない方に配信されました場合は、お手数でも
送信者までただちにご返信いただき、その後破棄または消去していただくようお願い申
し上げます。
正規の受取人以外の方による使用（調査、複製、転送、配布、公表等）は固くお断りい
たします。

The information transmitted by the MoneySquare Holdings Inc. in this email is
intended for the addressee only, and may contain confidential or personal
information.
Any use, retention, dissemination, distribution or copying of this message by
any person other than the intended recipient is prohibited.
If you have received this email in error, please notify the sender immediately
by return email and delete this email and any copies.

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

各位

お世話になっております。
大渕と申します。

前回こちらで問い合わせさせてもらったサーバーについて、また質問させてくだ
さい。

「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェント」
を参考に構築したサーバーです。

環境は以下の通りです。
CentOS5
PostgreSQL9.2.4
Pacemaker1.0.13-1.1
Master/Slave構成
以上

前回、松島さんにアドバイスいただいた内容を参考に、PostgreSQLの
max_connectionsの100を1000に上げて work_memを32MBから4MBに下げてからデー
タ同期してHA構成に戻したのですが、本日以下のような事象が発生しました。

14:08　エラーがマスター機で発生、PostgreSQL停止/フェイルオーバー発生
16:15　エラーがマスター機で発生、PostgreSQL停止　DBアクセス不可とユー
ザーから連絡
16:15　サーバーにアクセスしたところ以下の状態

Node Attributes:
* Node ptdb01.localdomain:
+ default_ping_set : 100
+ master-pgsql:1 : -INFINITY
+ pgsql-data-status : LATEST
+ pgsql-status : STOP
+ ptdb02.localdomain-eth2 : up
+ ptdb02.localdomain-eth3 : up
* Node ptdb02.localdomain:
+ default_ping_set : 100
+ master-pgsql:0 : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
+ ptdb01.localdomain-eth2 : up
+ ptdb01.localdomain-eth3 : up

Failed actions:
pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
status=Timed Out): unknown exec error
pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
status=Timed Out): unknown exec error

16:25　両ノードを停止、マスター機のみで起動して取り急ぎ復旧
以上

14:08と16:15に重いクエリを実行したそうなので、work_memを4MBに下げたため
にPostgreSQLに問題が起きて unknown exec errorになったのではないかと思っ
ています。

ha-logを添付させていただきますので、本件の原因と今後の再発防止策につい
て、ご教示いただけると大変ありがたいです。

以上、よろしくお願いいたします。

On 2015/08/26 11:45, Takehiro Matsushima wrote:
> 大渕さん
>
> 松島です。
> OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>
>
> Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張るかということを本当は計算しておく必要があります。
> APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常管理用に必要なコネクション数、DBのリソース、APのリソースなどから値を決めていくことになるとおもいます。
>
> pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるのも楽しいと思います。
>
> フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をするようにしています。
> Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監視したり、もしくはSNMPを使用するのもよいと思います。
> 時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していただくのがもちろん最善だとは思いますが、即席でということでしたらとりあえずMailTo
> RAが使いやすい印象です。
> ぜひお試しください。
>
> 以上よろしくお願いいたします。
>
> ----
> Takehiro Matsushima
>
> 2015年8月26日 10:32 大渕昭夫 <ohbuchi@m2j.co.jp>:
>> 松島さん
>>
>> お世話になっております。
>> 大渕です。
>>
>> ご無沙汰してます！
>> また次回のOSCに遊びに行こうかと思ってます。
>>
>> 早速の返信ありがとうございます。
>> 大変助かります。
>>
>> max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>> WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>> max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>> ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>
>> 今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませんの
>> で、その際にはpg_isreadyも調べてみようかと思いま す。
>>
>> ところで、今回たまたまフェイルオーバーしていたことに気づいたのですが、み
>> なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>
>> 以上、よろしくお願いいたします。
>>
>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>> 大渕さん
>>>
>>> お世話になっております、松島です。
>>> ご無沙汰しております。
>>>
>>> PostgreSQLのストリーミングレプリケーションにおいて、スレーブはマスターに対して常時接続を行っていたと思いますので、max_connectionsを使い切った状態でレプリケーションを新規に開始しようとしたのでなければ、問題ないはずです。
>>> max_wal_senders :
>>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>> max_connections および superuser_reserved_connections :
>>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>
>>> ログのメッセージからはRAが死活監視のためにPostgreSQLに接続しようとして拒否されていると私は推測しました。
>>> RAはmonitorアクションでpsqlで接続し、SQL(デフォルトは SELECT now() )を実行して成否を判断しています。
>>> したがって、max_connectionsを使い切っているときに死活監視が走ると、"Connection error (connection
>>> to the server went bad and the session was not interactive) occurred
>>> while executing the psql command."と言われてしまうということになります。
>>>
>>> ところで、この状況であってもsuperuser_reserved_connectionsで予約してあれば、monitor_userにスーパーユーザーの名前を書いておくことで死活監視は成功するものと思われます。
>>> 管理作業の都合もありますのでsuperuser_reserved_connectionsは2以上必要ですが、運用や管理に合わせて最終的な数を決定する必要があります。
>>> ただし、スーパーユーザー(postgresユーザなど)を死活監視等で使用する場合にはpg_hba.confなどを適切に設定しなくてはなりませんのでご注意ください。
>>>
>>> 余談ですがPostgreSQL 9.3からは接続ステータスを判別できるpg_isreadyというコマンドが使えるようになりました。
>>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>> 試してみてはいないのですが、monitorアクションでこれも使えるようにRAを変更すればこういった事例にも対応できるかもしれません。
>>>
>>> ----
>>> Takehiro Matsushima
>>>
>>>
>>>
>>> 2015年8月25日 18:50 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>> 各位
>>>>
>>>> お世話になっております。
>>>> 大渕と申します。
>>>>
>>>> 2年ほど前に「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェント」を参考に構築し、サーバーの設置場所の移動
>>>> の際など何度かこちら のメーリングリストにお世話になりまして、おかげさまで無事に稼働していたの ですが、昨夜アクセスが集中する事態が発生した
>>>> ところ、フェイルオーバーし たようです。
>>>>
>>>> フェイルオーバーした原因を教えていただきたく、メールさせていただきました。
>>>>
>>>> ha-logを添付いたしますので、お力を貸していただけると大変ありがたいです。
>>>>
>>>> 環境は以下の通りです。
>>>> CentOS5
>>>> PostgreSQL9.2.4
>>>> Pacemaker1.0.13-1.1
>>>> Master/Slave構成
>>>> 以上
>>>>
>>>> また、ha-logの7028行目あたりに以下のような表示がありましたので、この時間 にerrorが発生したことが原因でフェイルオーバーする
>>>> 流れになったように思わ れます。
>>>>
>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients already
>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL template1 isn't
>>>> running
>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
>>>> (connection to the server went bad and the session was not interactive)
>>>> occurred while executing the psql command.
>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info: process_lrm_event:
>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
>>>> confirmed=false) unknown error
>>>> 以上
>>>>
>>>> Master側のサーバー自体はダウンしておりません。/var/log/messagesの該当時 刻には特にログはなかったので問題なく動いて
>>>> いるように思われます。
>>>>
>>>> アクセスが長時間集中したのでMaster側のPostgreSQLの設定にあった max_connections=100の状態が続いてしま
>>>> い、Slave側の通信に応答しなかった ためフェイルオーバーしてしまったのではないかと予想してみたのですが、そう いったことは考えられますで しょうか。
>>>>
>>>> 以上、お忙しいところ恐縮ですが、よろしくお願いいたします。
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

度々すいません。
大渕です。

昨日の問い合わせ内容なんですが、CRMの設定は以下のようになっていました。

primitive pgsql ocf:heartbeat:pgsql \
params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
psql="/usr/local/pgsql-9.2.4/bin/psql" pgdata="/var/lib/pgsql/data/"
start_opt="-p 5432" rep_mode="sync" node_list="ptdb01.localdomain
ptdb02.localdomain" restore_command="cp
/var/lib/pgsql/data/pg_archive/%f %p"
primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
keepalives_count=5" master_ip="172.16.1.3" stop_escalate="0" \
op start interval="0s" timeout="60s" on-fail="restart" \
op monitor interval="7s" timeout="60s" on-fail="restart" \
op monitor interval="2s" role="Master" timeout="60s"
on-fail="restart" \
op promote interval="0s" timeout="60s" on-fail="restart" \
op demote interval="0s" timeout="60s" on-fail="stop" \
op stop interval="0s" timeout="60s" on-fail="block" \
op notify interval="0s" timeout="60s"

16:15の時点ではフェイルオーバー後なので片肺状態だったと思うのですが、そ
の時に重いクエリが実行されて停止処理のタイムアウト値 60sに到達したので自
ノードのpostgresプロセスを強制終了したということになりますでしょうか。

片肺状態でもタイムアウト値に到達するとpostgresプロセスの強制終了を実行し
てしまうのでしょうか。

その場合この設定の60sを300sなどに修正すると重いクエリに耐えられる状態に
なりますでしょうか。

いまさらな質問で恐縮ですが、お時間あるときにアドバイスいただけますと助か
ります。

以上、よろしくお願いいたします。

On 2015/10/01 19:25, 大渕昭夫 wrote:
> 各位
>
> お世話になっております。
> 大渕と申します。
>
> 前回こちらで問い合わせさせてもらったサーバーについて、また質問させてく
> だ さい。
>
> 「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェン
> ト」 を参考に構築したサーバーです。
>
> 環境は以下の通りです。
> CentOS5
> PostgreSQL9.2.4
> Pacemaker1.0.13-1.1
> Master/Slave構成
> 以上
>
> 前回、松島さんにアドバイスいただいた内容を参考に、PostgreSQLの
> max_connectionsの100を1000に上げて work_memを32MBから4MBに下げてから
> デー タ同期してHA構成に戻したのですが、本日以下のような事象が発生しま
> した。
>
> 14:08　エラーがマスター機で発生、PostgreSQL停止/フェイルオーバー発生
> 16:15　エラーがマスター機で発生、PostgreSQL停止　DBアクセス不可とユー
> ザーから連絡
> 16:15　サーバーにアクセスしたところ以下の状態
>
> Node Attributes:
> * Node ptdb01.localdomain:
> + default_ping_set : 100
> + master-pgsql:1 : -INFINITY
> + pgsql-data-status : LATEST
> + pgsql-status : STOP
> + ptdb02.localdomain-eth2 : up
> + ptdb02.localdomain-eth3 : up
> * Node ptdb02.localdomain:
> + default_ping_set : 100
> + master-pgsql:0 : -INFINITY
> + pgsql-data-status : DISCONNECT
> + pgsql-status : STOP
> + ptdb01.localdomain-eth2 : up
> + ptdb01.localdomain-eth3 : up
>
> Failed actions:
> pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
> status=Timed Out): unknown exec error
> pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
> status=Timed Out): unknown exec error
>
> 16:25　両ノードを停止、マスター機のみで起動して取り急ぎ復旧
> 以上
>
> 14:08と16:15に重いクエリを実行したそうなので、work_memを4MBに下げたた
> め にPostgreSQLに問題が起きて unknown exec errorになったのではないかと
> 思っ ています。
>
> ha-logを添付させていただきますので、本件の原因と今後の再発防止策につい
> て、ご教示いただけると大変ありがたいです。
>
> 以上、よろしくお願いいたします。
>
> On 2015/08/26 11:45, Takehiro Matsushima wrote:
>> 大渕さん
>>
>> 松島です。
>> OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>>
>>
>> Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張る
>> かということを本当は計算しておく必要があります。
>> APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常
>> 管理用に必要なコネクション数、DBのリソース、APのリ ソースなどから値を
>> 決めていくことになるとおもいます。
>>
>> pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるの
>> も楽しいと思います。
>>
>> フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をする
>> ようにしています。
>> Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監
>> 視したり、もしくはSNMPを使用するのもよいと思いま す。
>> 時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していた
>> だくのがもちろん最善だとは思いますが、即席でということでした らとりあ
>> えずMailTo
>> RAが使いやすい印象です。
>> ぜひお試しください。
>>
>> 以上よろしくお願いいたします。
>>
>> ----
>> Takehiro Matsushima
>>
>> 2015年8月26日 10:32 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>> 松島さん
>>>
>>> お世話になっております。
>>> 大渕です。
>>>
>>> ご無沙汰してます！
>>> また次回のOSCに遊びに行こうかと思ってます。
>>>
>>> 早速の返信ありがとうございます。
>>> 大変助かります。
>>>
>>> max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>>> WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>>> max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>>> ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>>
>>> 今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませ
>>> んの
>>> で、その際にはpg_isreadyも調べてみようかと思いま す。
>>>
>>> ところで、今回たまたまフェイルオーバーしていたことに気づいたのです
>>> が、み
>>> なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>>
>>> 以上、よろしくお願いいたします。
>>>
>>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>> 大渕さん
>>>>
>>>> お世話になっております、松島です。
>>>> ご無沙汰しております。
>>>>
>>>> PostgreSQLのストリーミングレプリケーションにおいて、スレーブはマス
>>>> ターに対して常時接続を行っていたと思いますの で、max_connectionsを
>>>> 使い切った状態でレプリケーションを新規に開始しようとしたのでなけれ
>>>> ば、問題ないはずで す。
>>>> max_wal_senders :
>>>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>
>>>> max_connections および superuser_reserved_connections :
>>>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>
>>>>
>>>> ログのメッセージからはRAが死活監視のためにPostgreSQLに接続しようと
>>>> して拒否されていると私は推測しました。
>>>> RAはmonitorアクションでpsqlで接続し、SQL(デフォルトは SELECT now()
>>>> )を実行して成否を判断しています。
>>>> したがって、max_connectionsを使い切っているときに死活監視が走る
>>>> と、"Connection error (connection
>>>> to the server went bad and the session was not interactive) occurred
>>>> while executing the psql command."と言われてしまうということになり
>>>> ます。
>>>>
>>>> ところで、この状況であってもsuperuser_reserved_connectionsで予約し
>>>> てあれば、 monitor_userにスーパーユーザーの名前を書いておくことで死
>>>> 活監視は成功するものと思われます。
>>>> 管理作業の都合もありますのでsuperuser_reserved_connectionsは2以上必
>>>> 要ですが、運用や管理に 合わせて最終的な数を決定する必要があります。
>>>> ただし、スーパーユーザー(postgresユーザなど)を死活監視等で使用する
>>>> 場合にはpg_hba.confなどを適切に設 定しなくてはなりませんのでご注意
>>>> ください。
>>>>
>>>> 余談ですがPostgreSQL 9.3からは接続ステータスを判別できるpg_isready
>>>> というコマンドが使えるようになりました。
>>>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>>> 試してみてはいないのですが、monitorアクションでこれも使えるようにRA
>>>> を変更すればこういった事例にも対応できるかも しれません。
>>>>
>>>> ----
>>>> Takehiro Matsushima
>>>>
>>>>
>>>>
>>>> 2015年8月25日 18:50 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>>> 各位
>>>>>
>>>>> お世話になっております。
>>>>> 大渕と申します。
>>>>>
>>>>> 2年ほど前に「PostgreSQL9.1ストリーミングレプリケーション対応リソー
>>>>> スエー ジェント」を参考に構築し、サーバーの設置場所の移動
>>>>> の際など何度かこちら のメーリングリストにお世話になりまして、おか
>>>>> げさまで無事に稼働していたの ですが、昨夜アクセスが集中する事態が
>>>>> 発生した
>>>>> ところ、フェイルオーバーし たようです。
>>>>>
>>>>> フェイルオーバーした原因を教えていただきたく、メールさせていただき
>>>>> ました。
>>>>>
>>>>> ha-logを添付いたしますので、お力を貸していただけると大変ありがたい
>>>>> です。
>>>>>
>>>>> 環境は以下の通りです。
>>>>> CentOS5
>>>>> PostgreSQL9.2.4
>>>>> Pacemaker1.0.13-1.1
>>>>> Master/Slave構成
>>>>> 以上
>>>>>
>>>>> また、ha-logの7028行目あたりに以下のような表示がありましたので、こ
>>>>> の時間 にerrorが発生したことが原因でフェイルオーバーする
>>>>> 流れになったように思わ れます。
>>>>>
>>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA output:
>>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many clients
>>>>> already
>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: PostgreSQL
>>>>> template1 isn't
>>>>> running
>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR: Connection error
>>>>> (connection to the server went bad and the session was not
>>>>> interactive)
>>>>> occurred while executing the psql command.
>>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info:
>>>>> process_lrm_event:
>>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1, cib-update=50710,
>>>>> confirmed=false) unknown error
>>>>> 以上
>>>>>
>>>>> Master側のサーバー自体はダウンしておりません。/var/log/messagesの
>>>>> 該当時 刻には特にログはなかったので問題なく動いて
>>>>> いるように思われます。
>>>>>
>>>>> アクセスが長時間集中したのでMaster側のPostgreSQLの設定にあった
>>>>> max_connections=100の状態が続いてしま
>>>>> い、Slave側の通信に応答しなかった ためフェイルオーバーしてしまった
>>>>> のではないかと予想してみたのですが、そう いったことは考えられます
>>>>> で しょうか。
>>>>>
>>>>> 以上、お忙しいところ恐縮ですが、よろしくお願いいたします。
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan@lists.osdn.me
>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

大渕さん

こんにちは、山内です。

場合によっては、monitorのタイムアウトの伸長は有効だと思います。

ただし、負荷試験などで、実際にかかる負荷をある程度見極める必要があると思います。
また、仮想マシンで構成されている場合などは、CPUなどに制限をかけている場合は、その制限を増やすなども
有効な場合があります。

以上です。




----- Original Message -----
>From: 大渕昭夫 <ohbuchi@m2j.co.jp>
>To: linux-ha-japan@lists.osdn.me
>Date: 2015/10/2, Fri 10:40
>Subject: Re: [Linux-ha-jp] PostgreSQLのストリーミングレプリケーションのフェイルオーバーの原因について
>
>
>度々すいません。
>大渕です。
>
>昨日の問い合わせ内容なんですが、CRMの設定は以下のようになっていました。
>
>primitive pgsql ocf:heartbeat:pgsql \
>    params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
      psql="/usr/local/pgsql-9.2.4/bin/psql"
      pgdata="/var/lib/pgsql/data/" start_opt="-p 5432" rep_mode="sync"
      node_list="ptdb01.localdomain ptdb02.localdomain"
      restore_command="cp /var/lib/pgsql/data/pg_archive/%f %p"
      primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
      keepalives_count=5" master_ip="172.16.1.3" stop_escalate="0" \
>    op start interval="0s" timeout="60s" on-fail="restart" \
>    op monitor interval="7s" timeout="60s" on-fail="restart" \
>    op monitor interval="2s" role="Master" timeout="60s"
      on-fail="restart" \
>    op promote interval="0s" timeout="60s" on-fail="restart" \
>    op demote interval="0s" timeout="60s" on-fail="stop" \
>    op stop interval="0s" timeout="60s" on-fail="block" \
>    op notify interval="0s" timeout="60s"
>
>16:15の時点ではフェイルオーバー後なので片肺状態だったと思うのですが、その時に重いクエリが実行されて停止処理のタイムアウト値
      60sに到達したので自ノードのpostgresプロセスを強制終了したということになりますでしょうか。
>
>片肺状態でもタイムアウト値に到達するとpostgresプロセスの強制終了を実行してしまうのでしょうか。
>
>その場合この設定の60sを300sなどに修正すると重いクエリに耐えられる状態になりますでしょうか。
>
>いまさらな質問で恐縮ですが、お時間あるときにアドバイスいただけますと助かります。
>
>以上、よろしくお願いいたします。
>
>On 2015/10/01 19:25, 大渕昭夫 wrote:
>
>各位
>>
>>お世話になっております。
>>大渕と申します。
>>
>>前回こちらで問い合わせさせてもらったサーバーについて、また質問させてくだ さい。
>>
>>「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェント」 を参考に構築したサーバーです。
>>
>>環境は以下の通りです。
>>CentOS5
>>PostgreSQL9.2.4
>>Pacemaker1.0.13-1.1
>>Master/Slave構成
>>以上
>>
>>前回、松島さんにアドバイスいただいた内容を参考に、PostgreSQLの max_connectionsの100を1000に上げて
      work_memを32MBから4MBに下げてからデー タ同期してHA構成に戻したのですが、本日以下のような事象が発生しました。
>>
>>14:08　エラーがマスター機で発生、PostgreSQL停止/フェイルオーバー発生
>>16:15　エラーがマスター機で発生、PostgreSQL停止　DBアクセス不可とユー ザーから連絡
>>16:15　サーバーにアクセスしたところ以下の状態
>>
>>Node Attributes:
>>* Node ptdb01.localdomain:
>>    + default_ping_set                  : 100
>>    + master-pgsql:1                    : -INFINITY
>>    + pgsql-data-status                 : LATEST
>>    + pgsql-status                      : STOP
>>    + ptdb02.localdomain-eth2           : up
>>    + ptdb02.localdomain-eth3           : up
>>* Node ptdb02.localdomain:
>>    + default_ping_set                  : 100
>>    + master-pgsql:0                    : -INFINITY
>>    + pgsql-data-status                 : DISCONNECT
>>    + pgsql-status                      : STOP
>>    + ptdb01.localdomain-eth2           : up
>>    + ptdb01.localdomain-eth3           : up
>>
>>Failed actions:
>>    pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
      status=Timed Out): unknown exec error
>>    pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
      status=Timed Out): unknown exec error
>>
>>16:25　両ノードを停止、マスター機のみで起動して取り急ぎ復旧
>>以上
>>
>>14:08と16:15に重いクエリを実行したそうなので、work_memを4MBに下げたため にPostgreSQLに問題が起きて
      unknown exec errorになったのではないかと思っ ています。
>>
>>ha-logを添付させていただきますので、本件の原因と今後の再発防止策につい て、ご教示いただけると大変ありがたいです。
>>
>>以上、よろしくお願いいたします。
>>
>>On 2015/08/26 11:45, Takehiro Matsushima wrote:
>>
>>大渕さん
>>>
>>>松島です。
>>>OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>>>
>>>
>>>Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張るかということを本当は計算しておく必要があります。
>>>APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常管理用に必要なコネクション数、DBのリソース、APのリ
        ソースなどから値を決めていくことになるとおもいます。
>>>
>>>pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるのも楽しいと思います。
>>>
>>>フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をするようにしています。
>>>Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監視したり、もしくはSNMPを使用するのもよいと思いま
        す。
>>>時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していただくのがもちろん最善だとは思いますが、即席でということでした
        らとりあえずMailTo
>>>RAが使いやすい印象です。
>>>ぜひお試しください。
>>>
>>>以上よろしくお願いいたします。
>>>
>>>----
>>>Takehiro Matsushima
>>>
>>>2015年8月26日 10:32 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>
>>>松島さん
>>>>
>>>>お世話になっております。
>>>>大渕です。
>>>>
>>>>ご無沙汰してます！
>>>>また次回のOSCに遊びに行こうかと思ってます。
>>>>
>>>>早速の返信ありがとうございます。
>>>>大変助かります。
>>>>
>>>>max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>>>>WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>>>>max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>>>>ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>>>
>>>>今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませんの
>>>>で、その際にはpg_isreadyも調べてみようかと思いま す。
>>>>
>>>>ところで、今回たまたまフェイルオーバーしていたことに気づいたのですが、み
>>>>なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>>>
>>>>以上、よろしくお願いいたします。
>>>>
>>>>On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>>
>>>>大渕さん
>>>>>
>>>>>お世話になっております、松島です。
>>>>>ご無沙汰しております。
>>>>>
>>>>>PostgreSQLのストリーミングレプリケーションにおいて、スレーブはマスターに対して常時接続を行っていたと思いますの
            で、max_connectionsを使い切った状態でレプリケーションを新規に開始しようとしたのでなければ、問題ないはずで
            す。
>>>>>max_wal_senders :
>>>>>https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>>max_connections および superuser_reserved_connections :
>>>>>https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>>
>>>>>ログのメッセージからはRAが死活監視のためにPostgreSQLに接続しようとして拒否されていると私は推測しました。
>>>>>RAはmonitorアクションでpsqlで接続し、SQL(デフォルトは SELECT now()
            )を実行して成否を判断しています。
>>>>>したがって、max_connectionsを使い切っているときに死活監視が走ると、"Connection error
            (connection
>>>>>to the server went bad and the session was not interactive)
            occurred
>>>>>while executing the psql command."と言われてしまうということになります。
>>>>>
>>>>>ところで、この状況であってもsuperuser_reserved_connectionsで予約してあれば、
            monitor_userにスーパーユーザーの名前を書いておくことで死活監視は成功するものと思われます。
>>>>>管理作業の都合もありますのでsuperuser_reserved_connectionsは2以上必要ですが、運用や管理に
            合わせて最終的な数を決定する必要があります。
>>>>>ただし、スーパーユーザー(postgresユーザなど)を死活監視等で使用する場合にはpg_hba.confなどを適切に設
            定しなくてはなりませんのでご注意ください。
>>>>>
>>>>>余談ですがPostgreSQL
            9.3からは接続ステータスを判別できるpg_isreadyというコマンドが使えるようになりました。
>>>>>https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>>>>試してみてはいないのですが、monitorアクションでこれも使えるようにRAを変更すればこういった事例にも対応できるかも
            しれません。
>>>>>
>>>>>----
>>>>>Takehiro Matsushima
>>>>>
>>>>>
>>>>>
>>>>>2015年8月25日 18:50 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>>>
>>>>>各位
>>>>>>
>>>>>>お世話になっております。
>>>>>>大渕と申します。
>>>>>>
>>>>>>2年ほど前に「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー
              ジェント」を参考に構築し、サーバーの設置場所の移動
>>>>>>の際など何度かこちら のメーリングリストにお世話になりまして、おかげさまで無事に稼働していたの
              ですが、昨夜アクセスが集中する事態が発生した
>>>>>>ところ、フェイルオーバーし たようです。
>>>>>>
>>>>>>フェイルオーバーした原因を教えていただきたく、メールさせていただきました。
>>>>>>
>>>>>>ha-logを添付いたしますので、お力を貸していただけると大変ありがたいです。
>>>>>>
>>>>>>環境は以下の通りです。
>>>>>>CentOS5
>>>>>>PostgreSQL9.2.4
>>>>>>Pacemaker1.0.13-1.1
>>>>>>Master/Slave構成
>>>>>>以上
>>>>>>
>>>>>>また、ha-logの7028行目あたりに以下のような表示がありましたので、この時間
              にerrorが発生したことが原因でフェイルオーバーする
>>>>>>流れになったように思わ れます。
>>>>>>
>>>>>>Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA
              output:
>>>>>>(pgsql:0:monitor:stderr) psql: FATAL:  sorry, too many
              clients already
>>>>>>pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
              PostgreSQL template1 isn't
>>>>>>running
>>>>>>pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
              Connection error
>>>>>>(connection to the server went bad and the session was not
              interactive)
>>>>>>occurred while executing the psql command.
>>>>>>Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info:
              process_lrm_event:
>>>>>>LRM operation pgsql:0_monitor_2000 (call=16, rc=1,
              cib-update=50710,
>>>>>>confirmed=false) unknown error
>>>>>>以上
>>>>>>
>>>>>>Master側のサーバー自体はダウンしておりません。/var/log/messagesの該当時
              刻には特にログはなかったので問題なく動いて
>>>>>>いるように思われます。
>>>>>>
>>>>>>アクセスが長時間集中したのでMaster側のPostgreSQLの設定にあった
              max_connections=100の状態が続いてしま
>>>>>>い、Slave側の通信に応答しなかった ためフェイルオーバーしてしまったのではないかと予想してみたのですが、そう
              いったことは考えられますで しょうか。
>>>>>>
>>>>>>以上、お忙しいところ恐縮ですが、よろしくお願いいたします。
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Linux-ha-japan mailing list
>>>>>>Linux-ha-japan@lists.osdn.me
>>>>>>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>>
_______________________________________________
>>>>>Linux-ha-japan mailing list
>>>>>Linux-ha-japan@lists.osdn.me
>>>>>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>
>>>>>
_______________________________________________
>>>>Linux-ha-japan mailing list
>>>>Linux-ha-japan@lists.osdn.me
>>>>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
_______________________________________________
>>>Linux-ha-japan mailing list
>>>Linux-ha-japan@lists.osdn.me
>>>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>>>
>>
>>
>>_______________________________________________
Linux-ha-japan mailing list Linux-ha-japan@lists.osdn.me http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>_______________________________________________
>Linux-ha-japan mailing list
>Linux-ha-japan@lists.osdn.me
>http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
>
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$B;3Fb$5$s(B

$BBg^<$G$9!#(B
$B$4JV?.$"$j$,$H$&$4$6$$$^$9!*(B

monitor$B$N%?%$%`%"%&%H$N?-D9$b8!F$$7$F$_$^$9!#(B

$B$=$&$G$9$M!#$=$b$=$b$N(BPostgreSQL$B$N@_DjA4HL$K4X$7$F8+D>$7$F$$$k$H$3$m$G$9!#(B
PostgreSQL$B$N%m%0$bM-8z$K$J$C$F$$$J$+$C$?$N$G!#(B

$B%^%7%s$OJ*M}%5!<%P!<(B2$BBf9=@.$J$N$G!"(BCPU$B$N@)8BEy$O$J$$$H;W$o$l$^$9!#(B

$B$^$?!"(BCRM$B$NFbMF$K$D$$$F$b$b$&0lEYJY6/$7$F$*$j$^$9!#(B

$BK\7o$N5sF0$K$D$$$F9M$($F$_$?$N$G$9$,!"!"!"(B
$BJRGY>uBV$G(Bop monitor interval="2s" role="Master" timeout="60s"
on-fail="restart" $B$N(B
timeout60$BIC$KE~C#$7$?$N$G(Bpgsql$B$r(Brestart$B$7$?$1$l$I!"(Bunknownerror$B$G(Bstop$B$K(B
$B$J$C$?(B
$B$H$$$&G'<1$G9g$C$F$*$j$^$9$G$7$g$&$+!#(B

$B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B

On 2015/10/07 17:03, renayama19661014@ybb.ne.jp wrote:
> $BBg^<$5$s(B
>
> $B$3$s$K$A$O!";3Fb$G$9!#(B
>
> $B>l9g$K$h$C$F$O!"(Bmonitor$B$N%?%$%`%"%&%H$N?-D9$OM-8z$@$H;W$$$^$9!#(B
>
> $B$?$@$7!"Ii2Y;n83$J$I$G!"<B:]$K$+$+$kIi2Y$r$"$kDxEY8+6K$a$kI,MW$,$"$k$H;W$$$^$9!#(B
> $B$^$?!"2>A[.%^%7%s$G9=@.$5$l$F$$$k>l9g$J$I$O!"(BCPU$B$J$I$K@)8B$r$+$1$F$$$k>l9g$O!"$=$N@)8B$rA}$d$9$J$I$b(B
> $BM-8z$J>l9g$,$"$j$^$9!#(B
>
> $B0J>e$G$9!#(B
>
>
>
>
> ----- Original Message -----
>> From: $BBg^<><IW(B <ohbuchi@m2j.co.jp>
>> To: linux-ha-japan@lists.osdn.me
>> Date: 2015/10/2, Fri 10:40
>> Subject: Re: [Linux-ha-jp] PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$N%U%'%$%k%*!<%P!<$N860x$K$D$$$F(B
>>
>>
>> $BEY!9$9$$$^$;$s!#(B
>> $BBg^<$G$9!#(B
>>
>> $B:rF|$NLd$$9g$o$;FbMF$J$s$G$9$,!"(BCRM$B$N@_Dj$O0J2<$N$h$&$K$J$C$F$$$^$7$?!#(B
>>
>> primitive pgsql ocf:heartbeat:pgsql \
>> params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
> psql="/usr/local/pgsql-9.2.4/bin/psql"
> pgdata="/var/lib/pgsql/data/" start_opt="-p 5432" rep_mode="sync"
> node_list="ptdb01.localdomain ptdb02.localdomain"
> restore_command="cp /var/lib/pgsql/data/pg_archive/%f %p"
> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
> keepalives_count=5" master_ip="172.16.1.3" stop_escalate="0" \
>> op start interval="0s" timeout="60s" on-fail="restart" \
>> op monitor interval="7s" timeout="60s" on-fail="restart" \
>> op monitor interval="2s" role="Master" timeout="60s"
> on-fail="restart" \
>> op promote interval="0s" timeout="60s" on-fail="restart" \
>> op demote interval="0s" timeout="60s" on-fail="stop" \
>> op stop interval="0s" timeout="60s" on-fail="block" \
>> op notify interval="0s" timeout="60s"
>>
>> 16:15$B$N;~E@$G$O%U%'%$%k%*!<%P!<8e$J$N$GJRGY>uBV$@$C$?$H;W$&$N$G$9$,!"$=$N;~$K=E$$%/%(%j$,<B9T$5$l$FDd;_=hM}$N%?%$%`%"%&%HCM(B
> 60s$B$KE~C#$7$?$N$G<+%N!<%I$N(Bpostgres$B%W%m%;%9$r6/@)=*N;$7$?$H$$$&$3$H$K$J$j$^$9$G$7$g$&$+!#(B
>> $BJRGY>uBV$G$b%?%$%`%"%&%HCM$KE~C#$9$k$H(Bpostgres$B%W%m%;%9$N6/@)=*N;$r<B9T$7$F$7$^$&$N$G$7$g$&$+!#(B
>>
>> $B$=$N>l9g$3$N@_Dj$N(B60s$B$r(B300s$B$J$I$K=$@5$9$k$H=E$$%/%(%j$KBQ$($i$l$k>uBV$K$J$j$^$9$G$7$g$&$+!#(B
>>
>> $B$$$^$5$i$J<ALd$G62=L$G$9$,!"$*;~4V$"$k$H$-$K%"%I%P%$%9$$$?$@$1$^$9$H=u$+$j$^$9!#(B
>>
>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>
>> On 2015/10/01 19:25, $BBg^<><IW(B wrote:
>>
>> $B3F0L(B
>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>> $BBg^<$H?=$7$^$9!#(B
>>>
>>> $BA02s$3$A$i$GLd$$9g$o$;$5$;$F$b$i$C$?%5!<%P!<$K$D$$$F!"$^$?<ALd$5$;$F$/$@(B $B$5$$!#(B
>>>
>>> $B!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W(B $B$r;29M$K9=C[.$7$?%5!<%P!<$G$9!#(B
>>>
>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>> CentOS5
>>> PostgreSQL9.2.4
>>> Pacemaker1.0.13-1.1
>>> Master/Slave$B9=@.(B
>>> $B0J>e(B
>>>
>>> $BA02s!">>Eg$5$s$K%"%I%P%$%9$$$?$@$$$?FbMF$r;29M$K!"(BPostgreSQL$B$N(B max_connections$B$N(B100$B$r(B1000$B$K>e$2$F(B
> work_mem$B$r(B32MB$B$+$i(B4MB$B$K2<$2$F$+$i%G!<(B $B%?F14|$7$F(BHA$B9=@.$KLa$7$?$N$G$9$,!"K\F|0J2<$N$h$&$J;v>]$,H/@8$7$^$7$?!#(B
>>> 14:08$B!!%(%i!<$,%^%9%?!<5!$GH/@8!"(BPostgreSQL$BDd;_(B/$B%U%'%$%k%*!<%P!<H/@8(B
>>> 16:15$B!!%(%i!<$,%^%9%?!<5!$GH/@8!"(BPostgreSQL$BDd;_!!(BDB$B%"%/%;%9IT2D$H%f!<(B $B%6!<$+$iO"Mm(B
>>> 16:15$B!!%5!<%P!<$K%"%/%;%9$7$?$H$3$m0J2<$N>uBV(B
>>>
>>> Node Attributes:
>>> * Node ptdb01.localdomain:
>>> + default_ping_set : 100
>>> + master-pgsql:1 : -INFINITY
>>> + pgsql-data-status : LATEST
>>> + pgsql-status : STOP
>>> + ptdb02.localdomain-eth2 : up
>>> + ptdb02.localdomain-eth3 : up
>>> * Node ptdb02.localdomain:
>>> + default_ping_set : 100
>>> + master-pgsql:0 : -INFINITY
>>> + pgsql-data-status : DISCONNECT
>>> + pgsql-status : STOP
>>> + ptdb01.localdomain-eth2 : up
>>> + ptdb01.localdomain-eth3 : up
>>>
>>> Failed actions:
>>> pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
> status=Timed Out): unknown exec error
>>> pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
> status=Timed Out): unknown exec error
>>> 16:25$B!!N>%N!<%I$rDd;_!"%^%9%?!<5!$N$_$G5/F0$7$F<h$j5^$.I|5l(B
>>> $B0J>e(B
>>>
>>> 14:08$B$H(B16:15$B$K=E$$%/%(%j$r<B9T$7$?$=$&$J$N$G!"(Bwork_mem$B$r(B4MB$B$K2<$2$?$?$a(B $B$K(BPostgreSQL$B$KLdBj$,5/$-$F(B
> unknown exec error$B$K$J$C$?$N$G$O$J$$$+$H;W$C(B $B$F$$$^$9!#(B
>>> ha-log$B$rE:IU$5$;$F$$$?$@$-$^$9$N$G!"K\7o$N860x$H:#8e$N:FH/KI;_:v$K$D$$(B $B$F!"$465<($$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>
>>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>
>>> On 2015/08/26 11:45, Takehiro Matsushima wrote:
>>>
>>> $BBg^<$5$s(B
>>>> $B>>Eg$G$9!#(B
>>>> OSC 2015 Tokyo/Fall$B$G$*2q$$$G$-$k$3$H$r3Z$7$_$K$7$F$*$j$^$9!*(B
>>>>
>>>>
>>>> Web$B%5!<%P!<(B($B@53N$K$O(BAP$B%5!<%P!<(B)$B$,(BDB$B$KBP$7$F$$$/$D$N%3%M%/%7%g%s$rD%$k$+$H$$$&$3$H$rK\Ev$O7W;;$7$F$*$/I,MW$,$"$j$^$9!#(B
>>>> AP$B$"$?$j$N%3%M%/%7%g%s?t!"(BAP$BBf?t!"FbItE*$K@8$8$k%3%M%/%7%g%s?t!"DL>o4IM}MQ$KI,MW$J%3%M%/%7%g%s?t!"(BDB$B$N%j%=!<%9!"(BAP$B$N%j(B
> $B%=!<%9$J$I$+$iCM$r7h$a$F$$$/$3$H$K$J$k$H$*$b$$$^$9!#(B
>>>> pg_isready$B$G$9$,!"8=>u$N(Bpgsql RA$B$OL$BP1~$G$9$N$G!"(BRA$B$r2~=$$7$F$_$k$N$b3Z$7$$$H;W$$$^$9!#(B
>>>>
>>>> $B%U%'%$%k%*!<%P!<$N8!CN$G$9$,!";d$O(BMailTo RA$B$r;HMQ$7$F%a!<%kDLCN$r$9$k$h$&$K$7$F$$$^$9!#(B
>>>> Zabbix$BEy$N4F;k%=%j%e!<%7%g%s$G%W%m%;%94F;k$7$?$j%+%9%?%`%3%^%s%I$G4F;k$7$?$j!"$b$7$/$O(BSNMP$B$r;HMQ$9$k$N$b$h$$$H;W$$$^(B
> $B$9!#(B
>>>> $B;~4VE*$KM>M5$,$"$k$N$G$7$?$i$$$m$$$m;n$7$F$_$F!":G=*E*$K7hDj$7$F$$$?$@$/$N$,$b$A$m$s:GA1$@$H$O;W$$$^$9$,!"B(@J$G$H$$$&$3$H$G$7$?(B
> $B$i$H$j$"$($:(BMailTo
>>>> RA$B$,;H$$$d$9$$0u>]$G$9!#(B
>>>> $B$<$R$*;n$7$/$@$5$$!#(B
>>>>
>>>> $B0J>e$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>
>>>> ----
>>>> Takehiro Matsushima
>>>>
>>>> 2015$BG/(B8$B7n(B26$BF|(B 10:32 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>>>
>>>> $B>>Eg$5$s(B
>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>>> $BBg^<$G$9!#(B
>>>>>
>>>>> $B$4L5:;BA$7$F$^$9!*(B
>>>>> $B$^$?<!2s$N(BOSC$B$KM7$S$K9T$3$&$+$H;W$C$F$^$9!#(B
>>>>>
>>>>> $BAaB.$NJV?.$"$j$,$H$&$4$6$$$^$9!#(B
>>>>> $BBgJQ=u$+$j$^$9!#(B
>>>>>
>>>>> max_connections$B$N@_Dj$,%G%U%)%k%H$N(B100$B$@$C$?$N$,LdBj$@$C$?$s$G$9$M!#(B
>>>>> WEB$B%5!<%P!<B&$N@_Dj$H(BDB$BB&$N@_Dj$KAj0c$,$"$C$?$h$&$J$N$G!":#2s$O(B
>>>>> max_connections$B$rE,@Z$J?tCM$K9g$o$;$kJ}8~$GBP=h$7(B $B$h$&$H;W$$$^$9!#(B
>>>>> $B$A$J$_$K(Bsuperuser_reserved_connections$B$O%3%a%s%H%"%&%H$5$l$F$$$^$7$?!#(B
>>>>>
>>>>> $B:#;H$C$F$$$k%5!<%P!<<+BN$,MhG/$"$?$j$K$O%j%W%l%$%9$K$J$k$+$b$7$l$^$;$s$N(B
>>>>> $B$G!"$=$N:]$K$O(Bpg_isready$B$bD4$Y$F$_$h$&$+$H;W$$$^(B $B$9!#(B
>>>>>
>>>>> $B$H$3$m$G!":#2s$?$^$?$^%U%'%$%k%*!<%P!<$7$F$$$?$3$H$K5$$E$$$?$N$G$9$,!"$_(B
>>>>> $B$J$5$s$O$I$N$h$&$K%U%'%$%k%*!<%P!<$r8!CN$7$F$$$k$N$G$7$g$&(B $B$+!#(B
>>>>>
>>>>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>
>>>>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>>>
>>>>> $BBg^<$5$s(B
>>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
>>>>>> $B$4L5:;BA$7$F$*$j$^$9!#(B
>>>>>>
>>>>>> PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N(B
> $B$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G(B
> $B$9!#(B
>>>>>> max_wal_senders :
>>>>>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>>> max_connections $B$*$h$S(B superuser_reserved_connections :
>>>>>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>>>
>>>>>> $B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
>>>>>> RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now()
> )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
>>>>>> $B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error
> (connection
>>>>>> to the server went bad and the session was not interactive)
> occurred
>>>>>> while executing the psql command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B
>>>>>>
>>>>>> $B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(B
> monitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
>>>>>> $B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K(B
> $B9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
>>>>>> $B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_(B
> $BDj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B
>>>>>> $BM>CL$G$9$,(BPostgreSQL
> 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
>>>>>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>>>>> $B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b(B
> $B$7$l$^$;$s!#(B
>>>>>> ----
>>>>>> Takehiro Matsushima
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>>>>>
>>>>>> $B3F0L(B
>>>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>>>>> $BBg^<$H?=$7$^$9!#(B
>>>>>>>
>>>>>>> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B
> $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
>>>>>>> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B
> $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
>>>>>>> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>>>>>>>
>>>>>>> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>>>>>>>
>>>>>>> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>>>>>
>>>>>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>>>>>> CentOS5
>>>>>>> PostgreSQL9.2.4
>>>>>>> Pacemaker1.0.13-1.1
>>>>>>> Master/Slave$B9=@.(B
>>>>>>> $B0J>e(B
>>>>>>>
>>>>>>> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B
> $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
>>>>>>> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>>>>>>>
>>>>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]: info: RA
> output:
>>>>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too many
> clients already
>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
> PostgreSQL template1 isn't
>>>>>>> running
>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
> Connection error
>>>>>>> (connection to the server went bad and the session was not
> interactive)
>>>>>>> occurred while executing the psql command.
>>>>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]: info:
> process_lrm_event:
>>>>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1,
> cib-update=50710,
>>>>>>> confirmed=false) unknown error
>>>>>>> $B0J>e(B
>>>>>>>
>>>>>>> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B
> $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
>>>>>>> $B$$$k$h$&$K;W$o$l$^$9!#(B
>>>>>>>
>>>>>>> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B
> max_connections=100$B$N>uBV$,B3$$$F$7$^(B
>>>>>>> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B
> $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>>>>>>> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>
>>>>>>>
> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>>
> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan@lists.osdn.me
>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>
> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>>>
>>>
>>> _______________________________________________
> Linux-ha-japan mailing list Linux-ha-japan@lists.osdn.me http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>
>>
>>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

大渕さん

こんばんは、山内です。

> 本件の挙動について考えてみたのですが、、、
> 片肺状態でop monitor interval="2s" role="Master" 
> timeout="60s" 
> on-fail="restart" の
> timeout60秒に到達したのでpgsqlをrestartしたけれど、unknownerrorでstopに 
> なった
> という認識で合っておりますでしょうか。


CRMの詳細を見ていないのですが・・・

Pacemakerのデフォルト設定（指定していない場合）では、リソースの故障管理回数の閾値(migration-threshold)は１回になっていますので、
故障(monitor故障）が許されるのは１回になります。

また、on-fail="restart"を指定している場合には、そのopでエラーが起きると、
そのリソースのstop->startの動作となります。

よって、今回の場合、
monitorで１回故障が起きたので、stopした。

＃restart(stop後にstart)する為には、故障管理回数の閾値が２以上の必要があります。

となっているはずです。

以上です。



----- Original Message -----
> From: 大渕昭夫 <ohbuchi@m2j.co.jp>
> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
> Cc:
> Date: 2015/10/7, Wed 18:51
> Subject: Re: [Linux-ha-jp] PostgreSQLのストリーミングレプリケーションのフェイルオーバーの原因について
>
> 山内さん
>
> 大渕です。
> ご返信ありがとうございます！
>
> monitorのタイムアウトの伸長も検討してみます。
>
> そうですね。そもそものPostgreSQLの設定全般に関して見直しているところです。
> PostgreSQLのログも有効になっていなかったので。
>
> マシンは物理サーバー2台構成なので、CPUの制限等はないと思われます。
>
> また、CRMの内容についてももう一度勉強しております。
>
> 本件の挙動について考えてみたのですが、、、
> 片肺状態でop monitor interval="2s" role="Master"
> timeout="60s"
> on-fail="restart" の
> timeout60秒に到達したのでpgsqlをrestartしたけれど、unknownerrorでstopに
> なった
> という認識で合っておりますでしょうか。
>
> 以上、よろしくお願いいたします。
>
> On 2015/10/07 17:03, renayama19661014@ybb.ne.jp wrote:
>> 大渕さん
>>
>> こんにちは、山内です。
>>
>> 場合によっては、monitorのタイムアウトの伸長は有効だと思います。
>>
>> ただし、負荷試験などで、実際にかかる負荷をある程度見極める必要があると思います。
>> また、仮想マシンで構成されている場合などは、CPUなどに制限をかけている場合は、その制限を増やすなども
>> 有効な場合があります。
>>
>> 以上です。
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: 大渕昭夫 <ohbuchi@m2j.co.jp>
>>> To: linux-ha-japan@lists.osdn.me
>>> Date: 2015/10/2, Fri 10:40
>>> Subject: Re: [Linux-ha-jp] PostgreSQLのストリーミングレプリケーションのフェイルオーバーの原因について
>>>
>>>
>>> 度々すいません。
>>> 大渕です。
>>>
>>> 昨日の問い合わせ内容なんですが、CRMの設定は以下のようになっていました。
>>>
>>> primitive pgsql ocf:heartbeat:pgsql \
>>>       params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
>>         psql="/usr/local/pgsql-9.2.4/bin/psql"
>>         pgdata="/var/lib/pgsql/data/" start_opt="-p
> 5432" rep_mode="sync"
>>         node_list="ptdb01.localdomain ptdb02.localdomain"
>>         restore_command="cp /var/lib/pgsql/data/pg_archive/%f %p"
>>         primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>         keepalives_count=5" master_ip="172.16.1.3"
> stop_escalate="0" \
>>>       op start interval="0s" timeout="60s"
> on-fail="restart" \
>>>       op monitor interval="7s" timeout="60s"
> on-fail="restart" \
>>>       op monitor interval="2s" role="Master"
> timeout="60s"
>>         on-fail="restart" \
>>>       op promote interval="0s" timeout="60s"
> on-fail="restart" \
>>>       op demote interval="0s" timeout="60s"
> on-fail="stop" \
>>>       op stop interval="0s" timeout="60s"
> on-fail="block" \
>>>       op notify interval="0s" timeout="60s"
>>>
>>> 16:15の時点ではフェイルオーバー後なので片肺状態だったと思うのですが、その時に重いクエリが実行されて停止処理のタイムアウト値
>>         60sに到達したので自ノードのpostgresプロセスを強制終了したということになりますでしょうか。
>>> 片肺状態でもタイムアウト値に到達するとpostgresプロセスの強制終了を実行してしまうのでしょうか。
>>>
>>> その場合この設定の60sを300sなどに修正すると重いクエリに耐えられる状態になりますでしょうか。
>>>
>>> いまさらな質問で恐縮ですが、お時間あるときにアドバイスいただけますと助かります。
>>>
>>> 以上、よろしくお願いいたします。
>>>
>>> On 2015/10/01 19:25, 大渕昭夫 wrote:
>>>
>>> 各位
>>>> お世話になっております。
>>>> 大渕と申します。
>>>>
>>>> 前回こちらで問い合わせさせてもらったサーバーについて、また質問させてくだ さい。
>>>>
>>>> 「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェント」 を参考に構築したサーバーです。
>>>>
>>>> 環境は以下の通りです。
>>>> CentOS5
>>>> PostgreSQL9.2.4
>>>> Pacemaker1.0.13-1.1
>>>> Master/Slave構成
>>>> 以上
>>>>
>>>> 前回、松島さんにアドバイスいただいた内容を参考に、PostgreSQLの max_connectionsの100を1000に上げて
>>         work_memを32MBから4MBに下げてからデー タ同期してHA構成に戻したのですが、本日以下のような事象が発生しました。
>>>> 14:08　エラーがマスター機で発生、PostgreSQL停止/フェイルオーバー発生
>>>> 16:15　エラーがマスター機で発生、PostgreSQL停止　DBアクセス不可とユー ザーから連絡
>>>> 16:15　サーバーにアクセスしたところ以下の状態
>>>>
>>>> Node Attributes:
>>>> * Node ptdb01.localdomain:
>>>>       + default_ping_set                  : 100
>>>>       + master-pgsql:1                    : -INFINITY
>>>>       + pgsql-data-status                : LATEST
>>>>       + pgsql-status                      : STOP
>>>>       + ptdb02.localdomain-eth2          : up
>>>>       + ptdb02.localdomain-eth3          : up
>>>> * Node ptdb02.localdomain:
>>>>       + default_ping_set                  : 100
>>>>       + master-pgsql:0                    : -INFINITY
>>>>       + pgsql-data-status                : DISCONNECT
>>>>       + pgsql-status                      : STOP
>>>>       + ptdb01.localdomain-eth2          : up
>>>>       + ptdb01.localdomain-eth3          : up
>>>>
>>>> Failed actions:
>>>>       pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
>>         status=Timed Out): unknown exec error
>>>>       pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
>>         status=Timed Out): unknown exec error
>>>> 16:25　両ノードを停止、マスター機のみで起動して取り急ぎ復旧
>>>> 以上
>>>>
>>>> 14:08と16:15に重いクエリを実行したそうなので、work_memを4MBに下げたため にPostgreSQLに問題が起きて
>>         unknown exec errorになったのではないかと思っ ています。
>>>> ha-logを添付させていただきますので、本件の原因と今後の再発防止策につい て、ご教示いただけると大変ありがたいです。
>>>>
>>>> 以上、よろしくお願いいたします。
>>>>
>>>> On 2015/08/26 11:45, Takehiro Matsushima wrote:
>>>>
>>>> 大渕さん
>>>>> 松島です。
>>>>> OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>>>>>
>>>>>
>>>>> Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張るかということを本当は計算しておく必要があります。
>>>>> APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常管理用に必要なコネクション数、DBのリソース、APのリ
>>           ソースなどから値を決めていくことになるとおもいます。
>>>>> pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるのも楽しいと思います。
>>>>>
>>>>> フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をするようにしています。
>>>>> Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監視したり、もしくはSNMPを使用するのもよいと思いま
>>           す。
>>>>>
> 時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していただくのがもちろん最善だとは思いますが、即席でということでした
>>           らとりあえずMailTo
>>>>> RAが使いやすい印象です。
>>>>> ぜひお試しください。
>>>>>
>>>>> 以上よろしくお願いいたします。
>>>>>
>>>>> ----
>>>>> Takehiro Matsushima
>>>>>
>>>>> 2015年8月26日 10:32 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>>>
>>>>> 松島さん
>>>>>> お世話になっております。
>>>>>> 大渕です。
>>>>>>
>>>>>> ご無沙汰してます！
>>>>>> また次回のOSCに遊びに行こうかと思ってます。
>>>>>>
>>>>>> 早速の返信ありがとうございます。
>>>>>> 大変助かります。
>>>>>>
>>>>>> max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>>>>>> WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>>>>>> max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>>>>>> ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>>>>>
>>>>>> 今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませんの
>>>>>> で、その際にはpg_isreadyも調べてみようかと思いま す。
>>>>>>
>>>>>> ところで、今回たまたまフェイルオーバーしていたことに気づいたのですが、み
>>>>>> なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>>>>>
>>>>>> 以上、よろしくお願いいたします。
>>>>>>
>>>>>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>>>>
>>>>>> 大渕さん
>>>>>>> お世話になっております、松島です。
>>>>>>> ご無沙汰しております。
>>>>>>>
>>>>>>>
> PostgreSQLのストリーミングレプリケーションにおいて、スレーブはマスターに対して常時接続を行っていたと思いますの
>>               で、max_connectionsを使い切った状態でレプリケーションを新規に開始しようとしたのでなければ、問題ないはずで
>>               す。
>>>>>>> max_wal_senders :
>>>>>>>
> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>>>> max_connections および superuser_reserved_connections :
>>>>>>>
> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>>>>
>>>>>>>
> ログのメッセージからはRAが死活監視のためにPostgreSQLに接続しようとして拒否されていると私は推測しました。
>>>>>>> RAはmonitorアクションでpsqlで接続し、SQL(デフォルトは SELECT now()
>>               )を実行して成否を判断しています。
>>>>>>>
> したがって、max_connectionsを使い切っているときに死活監視が走ると、"Connection error
>>               (connection
>>>>>>> to the server went bad and the session was not
> interactive)
>>               occurred
>>>>>>> while executing the psql
> command."と言われてしまうということになります。
>>>>>>>
>>>>>>> ところで、この状況であってもsuperuser_reserved_connectionsで予約してあれば、
>>               monitor_userにスーパーユーザーの名前を書いておくことで死活監視は成功するものと思われます。
>>>>>>>
> 管理作業の都合もありますのでsuperuser_reserved_connectionsは2以上必要ですが、運用や管理に
>>               合わせて最終的な数を決定する必要があります。
>>>>>>>
> ただし、スーパーユーザー(postgresユーザなど)を死活監視等で使用する場合にはpg_hba.confなどを適切に設
>>               定しなくてはなりませんのでご注意ください。
>>>>>>> 余談ですがPostgreSQL
>>               9.3からは接続ステータスを判別できるpg_isreadyというコマンドが使えるようになりました。
>>>>>>>
> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>>>>>>>
> 試してみてはいないのですが、monitorアクションでこれも使えるようにRAを変更すればこういった事例にも対応できるかも
>>               しれません。
>>>>>>> ----
>>>>>>> Takehiro Matsushima
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2015年8月25日 18:50 大渕昭夫 <ohbuchi@m2j.co.jp>:
>>>>>>>
>>>>>>> 各位
>>>>>>>> お世話になっております。
>>>>>>>> 大渕と申します。
>>>>>>>>
>>>>>>>> 2年ほど前に「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー
>>                 ジェント」を参考に構築し、サーバーの設置場所の移動
>>>>>>>> の際など何度かこちら のメーリングリストにお世話になりまして、おかげさまで無事に稼働していたの
>>                 ですが、昨夜アクセスが集中する事態が発生した
>>>>>>>> ところ、フェイルオーバーし たようです。
>>>>>>>>
>>>>>>>> フェイルオーバーした原因を教えていただきたく、メールさせていただきました。
>>>>>>>>
>>>>>>>> ha-logを添付いたしますので、お力を貸していただけると大変ありがたいです。
>>>>>>>>
>>>>>>>> 環境は以下の通りです。
>>>>>>>> CentOS5
>>>>>>>> PostgreSQL9.2.4
>>>>>>>> Pacemaker1.0.13-1.1
>>>>>>>> Master/Slave構成
>>>>>>>> 以上
>>>>>>>>
>>>>>>>> また、ha-logの7028行目あたりに以下のような表示がありましたので、この時間
>>                 にerrorが発生したことが原因でフェイルオーバーする
>>>>>>>> 流れになったように思わ れます。
>>>>>>>>
>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]:
> info: RA
>>                 output:
>>>>>>>> (pgsql:0:monitor:stderr) psql: FATAL:  sorry, too
> many
>>                 clients already
>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>                 PostgreSQL template1 isn't
>>>>>>>> running
>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>                 Connection error
>>>>>>>> (connection to the server went bad and the session
> was not
>>                 interactive)
>>>>>>>> occurred while executing the psql command.
>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]:
> info:
>>                 process_lrm_event:
>>>>>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1,
>>                 cib-update=50710,
>>>>>>>> confirmed=false) unknown error
>>>>>>>> 以上
>>>>>>>>
>>>>>>>> Master側のサーバー自体はダウンしておりません。/var/log/messagesの該当時
>>                 刻には特にログはなかったので問題なく動いて
>>>>>>>> いるように思われます。
>>>>>>>>
>>>>>>>> アクセスが長時間集中したのでMaster側のPostgreSQLの設定にあった
>>                 max_connections=100の状態が続いてしま
>>>>>>>> い、Slave側の通信に応答しなかった
> ためフェイルオーバーしてしまったのではないかと予想してみたのですが、そう
>>                 いったことは考えられますで しょうか。
>>>>>>>> 以上、お忙しいところ恐縮ですが、よろしくお願いいたします。
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Linux-ha-japan mailing list
>>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>>>
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>>
>>>>>>>>
>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>
>>>>>>>
>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>
>> _______________________________________________
>>>>> Linux-ha-japan mailing list
>>>>> Linux-ha-japan@lists.osdn.me
>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>> Linux-ha-japan mailing list Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>
>>>
>>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

$B;3Fb$5$s(B

$B$3$s$K$A$O!#(B
$BBg^<$G$9!#(B

$B$4JV?.$"$j$,$H$&$4$6$$$^$9!#(B
$B$^$?!"CzG+$J2r@b$"$j$,$H$&$4$6$$$^$9!#K\Ev$K=u$+$j$^$9!#(B

migretion-threshold$B$O0J2<$N$h$&$K(B1$B$H$J$C$F$$$k$h$&$G$9!#(B
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY" \
migration-threshold="1"

$B0z$-B3$-JY6/$7$F$$$3$&$H;W$$$^$9!#(B

$B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B

On 2015/10/07 20:33, renayama19661014@ybb.ne.jp wrote:
> $BBg^<$5$s(B
>
> $B$3$s$P$s$O!";3Fb$G$9!#(B
>
>> $BK\7o$N5sF0$K$D$$$F9M$($F$_$?$N$G$9$,!"!"!"(B
>> $BJRGY>uBV$G(Bop monitor interval="2s" role="Master"
>> timeout="60s"
>> on-fail="restart" $B$N(B
>> timeout60$BIC$KE~C#$7$?$N$G(Bpgsql$B$r(Brestart$B$7$?$1$l$I!"(Bunknownerror$B$G(Bstop$B$K(B
>> $B$J$C$?(B
>> $B$H$$$&G'<1$G9g$C$F$*$j$^$9$G$7$g$&$+!#(B
>
> CRM$B$N>\:Y$r8+$F$$$J$$$N$G$9$,!&!&!&(B
>
> Pacemaker$B$N%G%U%)%k%H@_Dj!J;XDj$7$F$$$J$$>l9g!K$G$O!"%j%=!<%9$N8N>c4IM}2s?t$NogCM(B(migration-threshold)$B$O#12s$K$J$C$F$$$^$9$N$G!"(B
> $B8N>c(B(monitor$B8N>c!K$,5v$5$l$k$N$O#12s$K$J$j$^$9!#(B
>
> $B$^$?!"(Bon-fail="restart"$B$r;XDj$7$F$$$k>l9g$K$O!"$=$N(Bop$B$G%(%i!<$,5/$-$k$H!"(B
> $B$=$N%j%=!<%9$N(Bstop->start$B$NF0:n$H$J$j$^$9!#(B
>
> $B$h$C$F!":#2s$N>l9g!"(B
> monitor$B$G#12s8N>c$,5/$-$?$N$G!"(Bstop$B$7$?!#(B
>
> $B!t(Brestart(stop$B8e$K(Bstart)$B$9$k0Y$K$O!"8N>c4IM}2s?t$NogCM$,#20J>e$NI,MW$,$"$j$^$9!#(B
>
> $B$H$J$C$F$$$k$O$:$G$9!#(B
>
> $B0J>e$G$9!#(B
>
>
>
> ----- Original Message -----
>> From: $BBg^<><IW(B <ohbuchi@m2j.co.jp>
>> To: renayama19661014@ybb.ne.jp; linux-ha-japan@lists.osdn.me
>> Cc:
>> Date: 2015/10/7, Wed 18:51
>> Subject: Re: [Linux-ha-jp] PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$N%U%'%$%k%*!<%P!<$N860x$K$D$$$F(B
>>
>> $B;3Fb$5$s(B
>>
>> $BBg^<$G$9!#(B
>> $B$4JV?.$"$j$,$H$&$4$6$$$^$9!*(B
>>
>> monitor$B$N%?%$%`%"%&%H$N?-D9$b8!F$$7$F$_$^$9!#(B
>>
>> $B$=$&$G$9$M!#$=$b$=$b$N(BPostgreSQL$B$N@_DjA4HL$K4X$7$F8+D>$7$F$$$k$H$3$m$G$9!#(B
>> PostgreSQL$B$N%m%0$bM-8z$K$J$C$F$$$J$+$C$?$N$G!#(B
>>
>> $B%^%7%s$OJ*M}%5!<%P!<(B2$BBf9=@.$J$N$G!"(BCPU$B$N@)8BEy$O$J$$$H;W$o$l$^$9!#(B
>>
>> $B$^$?!"(BCRM$B$NFbMF$K$D$$$F$b$b$&0lEYJY6/$7$F$*$j$^$9!#(B
>>
>> $BK\7o$N5sF0$K$D$$$F9M$($F$_$?$N$G$9$,!"!"!"(B
>> $BJRGY>uBV$G(Bop monitor interval="2s" role="Master"
>> timeout="60s"
>> on-fail="restart" $B$N(B
>> timeout60$BIC$KE~C#$7$?$N$G(Bpgsql$B$r(Brestart$B$7$?$1$l$I!"(Bunknownerror$B$G(Bstop$B$K(B
>> $B$J$C$?(B
>> $B$H$$$&G'<1$G9g$C$F$*$j$^$9$G$7$g$&$+!#(B
>>
>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>
>> On 2015/10/07 17:03, renayama19661014@ybb.ne.jp wrote:
>>> $BBg^<$5$s(B
>>>
>>> $B$3$s$K$A$O!";3Fb$G$9!#(B
>>>
>>> $B>l9g$K$h$C$F$O!"(Bmonitor$B$N%?%$%`%"%&%H$N?-D9$OM-8z$@$H;W$$$^$9!#(B
>>>
>>> $B$?$@$7!"Ii2Y;n83$J$I$G!"<B:]$K$+$+$kIi2Y$r$"$kDxEY8+6K$a$kI,MW$,$"$k$H;W$$$^$9!#(B
>>> $B$^$?!"2>A[.%^%7%s$G9=@.$5$l$F$$$k>l9g$J$I$O!"(BCPU$B$J$I$K@)8B$r$+$1$F$$$k>l9g$O!"$=$N@)8B$rA}$d$9$J$I$b(B
>>> $BM-8z$J>l9g$,$"$j$^$9!#(B
>>>
>>> $B0J>e$G$9!#(B
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: $BBg^<><IW(B <ohbuchi@m2j.co.jp>
>>>> To: linux-ha-japan@lists.osdn.me
>>>> Date: 2015/10/2, Fri 10:40
>>>> Subject: Re: [Linux-ha-jp] PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$N%U%'%$%k%*!<%P!<$N860x$K$D$$$F(B
>>>>
>>>>
>>>> $BEY!9$9$$$^$;$s!#(B
>>>> $BBg^<$G$9!#(B
>>>>
>>>> $B:rF|$NLd$$9g$o$;FbMF$J$s$G$9$,!"(BCRM$B$N@_Dj$O0J2<$N$h$&$K$J$C$F$$$^$7$?!#(B
>>>>
>>>> primitive pgsql ocf:heartbeat:pgsql \
>>>> params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
>>> psql="/usr/local/pgsql-9.2.4/bin/psql"
>>> pgdata="/var/lib/pgsql/data/" start_opt="-p
>> 5432" rep_mode="sync"
>>> node_list="ptdb01.localdomain ptdb02.localdomain"
>>> restore_command="cp /var/lib/pgsql/data/pg_archive/%f %p"
>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>> keepalives_count=5" master_ip="172.16.1.3"
>> stop_escalate="0" \
>>>> op start interval="0s" timeout="60s"
>> on-fail="restart" \
>>>> op monitor interval="7s" timeout="60s"
>> on-fail="restart" \
>>>> op monitor interval="2s" role="Master"
>> timeout="60s"
>>> on-fail="restart" \
>>>> op promote interval="0s" timeout="60s"
>> on-fail="restart" \
>>>> op demote interval="0s" timeout="60s"
>> on-fail="stop" \
>>>> op stop interval="0s" timeout="60s"
>> on-fail="block" \
>>>> op notify interval="0s" timeout="60s"
>>>>
>>>> 16:15$B$N;~E@$G$O%U%'%$%k%*!<%P!<8e$J$N$GJRGY>uBV$@$C$?$H;W$&$N$G$9$,!"$=$N;~$K=E$$%/%(%j$,<B9T$5$l$FDd;_=hM}$N%?%$%`%"%&%HCM(B
>>> 60s$B$KE~C#$7$?$N$G<+%N!<%I$N(Bpostgres$B%W%m%;%9$r6/@)=*N;$7$?$H$$$&$3$H$K$J$j$^$9$G$7$g$&$+!#(B
>>>> $BJRGY>uBV$G$b%?%$%`%"%&%HCM$KE~C#$9$k$H(Bpostgres$B%W%m%;%9$N6/@)=*N;$r<B9T$7$F$7$^$&$N$G$7$g$&$+!#(B
>>>>
>>>> $B$=$N>l9g$3$N@_Dj$N(B60s$B$r(B300s$B$J$I$K=$@5$9$k$H=E$$%/%(%j$KBQ$($i$l$k>uBV$K$J$j$^$9$G$7$g$&$+!#(B
>>>>
>>>> $B$$$^$5$i$J<ALd$G62=L$G$9$,!"$*;~4V$"$k$H$-$K%"%I%P%$%9$$$?$@$1$^$9$H=u$+$j$^$9!#(B
>>>>
>>>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>
>>>> On 2015/10/01 19:25, $BBg^<><IW(B wrote:
>>>>
>>>> $B3F0L(B
>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>>> $BBg^<$H?=$7$^$9!#(B
>>>>>
>>>>> $BA02s$3$A$i$GLd$$9g$o$;$5$;$F$b$i$C$?%5!<%P!<$K$D$$$F!"$^$?<ALd$5$;$F$/$@(B $B$5$$!#(B
>>>>>
>>>>> $B!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B $B%8%'%s%H!W(B $B$r;29M$K9=C[.$7$?%5!<%P!<$G$9!#(B
>>>>>
>>>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>>>> CentOS5
>>>>> PostgreSQL9.2.4
>>>>> Pacemaker1.0.13-1.1
>>>>> Master/Slave$B9=@.(B
>>>>> $B0J>e(B
>>>>>
>>>>> $BA02s!">>Eg$5$s$K%"%I%P%$%9$$$?$@$$$?FbMF$r;29M$K!"(BPostgreSQL$B$N(B max_connections$B$N(B100$B$r(B1000$B$K>e$2$F(B
>>> work_mem$B$r(B32MB$B$+$i(B4MB$B$K2<$2$F$+$i%G!<(B $B%?F14|$7$F(BHA$B9=@.$KLa$7$?$N$G$9$,!"K\F|0J2<$N$h$&$J;v>]$,H/@8$7$^$7$?!#(B
>>>>> 14:08$B!!%(%i!<$,%^%9%?!<5!$GH/@8!"(BPostgreSQL$BDd;_(B/$B%U%'%$%k%*!<%P!<H/@8(B
>>>>> 16:15$B!!%(%i!<$,%^%9%?!<5!$GH/@8!"(BPostgreSQL$BDd;_!!(BDB$B%"%/%;%9IT2D$H%f!<(B $B%6!<$+$iO"Mm(B
>>>>> 16:15$B!!%5!<%P!<$K%"%/%;%9$7$?$H$3$m0J2<$N>uBV(B
>>>>>
>>>>> Node Attributes:
>>>>> * Node ptdb01.localdomain:
>>>>> + default_ping_set : 100
>>>>> + master-pgsql:1 : -INFINITY
>>>>> + pgsql-data-status : LATEST
>>>>> + pgsql-status : STOP
>>>>> + ptdb02.localdomain-eth2 : up
>>>>> + ptdb02.localdomain-eth3 : up
>>>>> * Node ptdb02.localdomain:
>>>>> + default_ping_set : 100
>>>>> + master-pgsql:0 : -INFINITY
>>>>> + pgsql-data-status : DISCONNECT
>>>>> + pgsql-status : STOP
>>>>> + ptdb01.localdomain-eth2 : up
>>>>> + ptdb01.localdomain-eth3 : up
>>>>>
>>>>> Failed actions:
>>>>> pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
>>> status=Timed Out): unknown exec error
>>>>> pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
>>> status=Timed Out): unknown exec error
>>>>> 16:25$B!!N>%N!<%I$rDd;_!"%^%9%?!<5!$N$_$G5/F0$7$F<h$j5^$.I|5l(B
>>>>> $B0J>e(B
>>>>>
>>>>> 14:08$B$H(B16:15$B$K=E$$%/%(%j$r<B9T$7$?$=$&$J$N$G!"(Bwork_mem$B$r(B4MB$B$K2<$2$?$?$a(B $B$K(BPostgreSQL$B$KLdBj$,5/$-$F(B
>>> unknown exec error$B$K$J$C$?$N$G$O$J$$$+$H;W$C(B $B$F$$$^$9!#(B
>>>>> ha-log$B$rE:IU$5$;$F$$$?$@$-$^$9$N$G!"K\7o$N860x$H:#8e$N:FH/KI;_:v$K$D$$(B $B$F!"$465<($$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>>>
>>>>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>
>>>>> On 2015/08/26 11:45, Takehiro Matsushima wrote:
>>>>>
>>>>> $BBg^<$5$s(B
>>>>>> $B>>Eg$G$9!#(B
>>>>>> OSC 2015 Tokyo/Fall$B$G$*2q$$$G$-$k$3$H$r3Z$7$_$K$7$F$*$j$^$9!*(B
>>>>>>
>>>>>>
>>>>>> Web$B%5!<%P!<(B($B@53N$K$O(BAP$B%5!<%P!<(B)$B$,(BDB$B$KBP$7$F$$$/$D$N%3%M%/%7%g%s$rD%$k$+$H$$$&$3$H$rK\Ev$O7W;;$7$F$*$/I,MW$,$"$j$^$9!#(B
>>>>>> AP$B$"$?$j$N%3%M%/%7%g%s?t!"(BAP$BBf?t!"FbItE*$K@8$8$k%3%M%/%7%g%s?t!"DL>o4IM}MQ$KI,MW$J%3%M%/%7%g%s?t!"(BDB$B$N%j%=!<%9!"(BAP$B$N%j(B
>>> $B%=!<%9$J$I$+$iCM$r7h$a$F$$$/$3$H$K$J$k$H$*$b$$$^$9!#(B
>>>>>> pg_isready$B$G$9$,!"8=>u$N(Bpgsql RA$B$OL$BP1~$G$9$N$G!"(BRA$B$r2~=$$7$F$_$k$N$b3Z$7$$$H;W$$$^$9!#(B
>>>>>>
>>>>>> $B%U%'%$%k%*!<%P!<$N8!CN$G$9$,!";d$O(BMailTo RA$B$r;HMQ$7$F%a!<%kDLCN$r$9$k$h$&$K$7$F$$$^$9!#(B
>>>>>> Zabbix$BEy$N4F;k%=%j%e!<%7%g%s$G%W%m%;%94F;k$7$?$j%+%9%?%`%3%^%s%I$G4F;k$7$?$j!"$b$7$/$O(BSNMP$B$r;HMQ$9$k$N$b$h$$$H;W$$$^(B
>>> $B$9!#(B
>> $B;~4VE*$KM>M5$,$"$k$N$G$7$?$i$$$m$$$m;n$7$F$_$F!":G=*E*$K7hDj$7$F$$$?$@$/$N$,$b$A$m$s:GA1$@$H$O;W$$$^$9$,!"B(@J$G$H$$$&$3$H$G$7$?(B
>>> $B$i$H$j$"$($:(BMailTo
>>>>>> RA$B$,;H$$$d$9$$0u>]$G$9!#(B
>>>>>> $B$<$R$*;n$7$/$@$5$$!#(B
>>>>>>
>>>>>> $B0J>e$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>>
>>>>>> ----
>>>>>> Takehiro Matsushima
>>>>>>
>>>>>> 2015$BG/(B8$B7n(B26$BF|(B 10:32 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>>>>>
>>>>>> $B>>Eg$5$s(B
>>>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>>>>> $BBg^<$G$9!#(B
>>>>>>>
>>>>>>> $B$4L5:;BA$7$F$^$9!*(B
>>>>>>> $B$^$?<!2s$N(BOSC$B$KM7$S$K9T$3$&$+$H;W$C$F$^$9!#(B
>>>>>>>
>>>>>>> $BAaB.$NJV?.$"$j$,$H$&$4$6$$$^$9!#(B
>>>>>>> $BBgJQ=u$+$j$^$9!#(B
>>>>>>>
>>>>>>> max_connections$B$N@_Dj$,%G%U%)%k%H$N(B100$B$@$C$?$N$,LdBj$@$C$?$s$G$9$M!#(B
>>>>>>> WEB$B%5!<%P!<B&$N@_Dj$H(BDB$BB&$N@_Dj$KAj0c$,$"$C$?$h$&$J$N$G!":#2s$O(B
>>>>>>> max_connections$B$rE,@Z$J?tCM$K9g$o$;$kJ}8~$GBP=h$7(B $B$h$&$H;W$$$^$9!#(B
>>>>>>> $B$A$J$_$K(Bsuperuser_reserved_connections$B$O%3%a%s%H%"%&%H$5$l$F$$$^$7$?!#(B
>>>>>>>
>>>>>>> $B:#;H$C$F$$$k%5!<%P!<<+BN$,MhG/$"$?$j$K$O%j%W%l%$%9$K$J$k$+$b$7$l$^$;$s$N(B
>>>>>>> $B$G!"$=$N:]$K$O(Bpg_isready$B$bD4$Y$F$_$h$&$+$H;W$$$^(B $B$9!#(B
>>>>>>>
>>>>>>> $B$H$3$m$G!":#2s$?$^$?$^%U%'%$%k%*!<%P!<$7$F$$$?$3$H$K5$$E$$$?$N$G$9$,!"$_(B
>>>>>>> $B$J$5$s$O$I$N$h$&$K%U%'%$%k%*!<%P!<$r8!CN$7$F$$$k$N$G$7$g$&(B $B$+!#(B
>>>>>>>
>>>>>>> $B0J>e!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>>>
>>>>>>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>>>>>
>>>>>>> $BBg^<$5$s(B
>>>>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!">>Eg$G$9!#(B
>>>>>>>> $B$4L5:;BA$7$F$*$j$^$9!#(B
>>>>>>>>
>>>>>>>>
>> PostgreSQL$B$N%9%H%j!<%_%s%0%l%W%j%1!<%7%g%s$K$*$$$F!"%9%l!<%V$O%^%9%?!<$KBP$7$F>o;~@\B3$r9T$C$F$$$?$H;W$$$^$9$N(B
>>> $B$G!"(Bmax_connections$B$r;H$$@Z$C$?>uBV$G%l%W%j%1!<%7%g%s$r?75,$K3+;O$7$h$&$H$7$?$N$G$J$1$l$P!"LdBj$J$$$O$:$G(B
>>> $B$9!#(B
>>>>>>>> max_wal_senders :
>>>>>>>>
>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>>>>> max_connections $B$*$h$S(B superuser_reserved_connections :
>>>>>>>>
>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>>>>>
>> $B%m%0$N%a%C%;!<%8$+$i$O(BRA$B$,;`3h4F;k$N$?$a$K(BPostgreSQL$B$K@\B3$7$h$&$H$7$F5qH]$5$l$F$$$k$H;d$O?dB,$7$^$7$?!#(B
>>>>>>>> RA$B$O(Bmonitor$B%"%/%7%g%s$G(Bpsql$B$G@\B3$7!"(BSQL($B%G%U%)%k%H$O(B SELECT now()
>>> )$B$r<B9T$7$F@.H]$rH=CG$7$F$$$^$9!#(B
>> $B$7$?$,$C$F!"(Bmax_connections$B$r;H$$@Z$C$F$$$k$H$-$K;`3h4F;k$,Av$k$H!"(B"Connection error
>>> (connection
>>>>>>>> to the server went bad and the session was not
>> interactive)
>>> occurred
>>>>>>>> while executing the psql
>> command."$B$H8@$o$l$F$7$^$&$H$$$&$3$H$K$J$j$^$9!#(B
>>>>>>>> $B$H$3$m$G!"$3$N>u67$G$"$C$F$b(Bsuperuser_reserved_connections$B$GM=Ls$7$F$"$l$P!"(B
>>> monitor_user$B$K%9!<%Q!<%f!<%6!<$NL>A0$r=q$$$F$*$/$3$H$G;`3h4F;k$O@.8y$9$k$b$N$H;W$o$l$^$9!#(B
>> $B4IM}:n6H$NET9g$b$"$j$^$9$N$G(Bsuperuser_reserved_connections$B$O(B2$B0J>eI,MW$G$9$,!"1?MQ$d4IM}$K(B
>>> $B9g$o$;$F:G=*E*$J?t$r7hDj$9$kI,MW$,$"$j$^$9!#(B
>> $B$?$@$7!"%9!<%Q!<%f!<%6!<(B(postgres$B%f!<%6$J$I(B)$B$r;`3h4F;kEy$G;HMQ$9$k>l9g$K$O(Bpg_hba.conf$B$J$I$rE,@Z$K@_(B
>>> $BDj$7$J$/$F$O$J$j$^$;$s$N$G$4Cm0U$/$@$5$$!#(B
>>>>>>>> $BM>CL$G$9$,(BPostgreSQL
>>> 9.3$B$+$i$O@\B3%9%F!<%?%9$rH=JL$G$-$k(Bpg_isready$B$H$$$&%3%^%s%I$,;H$($k$h$&$K$J$j$^$7$?!#(B
>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>> $B;n$7$F$_$F$O$$$J$$$N$G$9$,!"(Bmonitor$B%"%/%7%g%s$G$3$l$b;H$($k$h$&$K(BRA$B$rJQ99$9$l$P$3$&$$$C$?;vNc$K$bBP1~$G$-$k$+$b(B
>>> $B$7$l$^$;$s!#(B
>>>>>>>> ----
>>>>>>>> Takehiro Matsushima
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015$BG/(B8$B7n(B25$BF|(B 18:50 $BBg^<><IW(B <ohbuchi@m2j.co.jp>:
>>>>>>>>
>>>>>>>> $B3F0L(B
>>>>>>>>> $B$*@$OC$K$J$C$F$*$j$^$9!#(B
>>>>>>>>> $BBg^<$H?=$7$^$9!#(B
>>>>>>>>>
>>>>>>>>> 2$BG/$[$IA0$K!V(BPostgreSQL9.1$B%9%H%j!<%_%s%0%l%W%j%1!<%7%g%sBP1~%j%=!<%9%(!<(B
>>> $B%8%'%s%H!W$r;29M$K9=C[$7!"%5!<%P!<$N@_CV>l=j$N0\F0(B
>>>>>>>>> $B$N:]$J$I2?EY$+$3$A$i(B $B$N%a!<%j%s%0%j%9%H$K$*@$OC$K$J$j$^$7$F!"$*$+$2$5$^$GL5;v$K2TF/$7$F$$$?$N(B
>>> $B$G$9$,!":rLk%"%/%;%9$,=8Cf$9$k;vBV$,H/@8$7$?(B
>>>>>>>>> $B$H$3$m!"%U%'%$%k%*!<%P!<$7(B $B$?$h$&$G$9!#(B
>>>>>>>>>
>>>>>>>>> $B%U%'%$%k%*!<%P!<$7$?860x$r65$($F$$$?$@$-$?$/!"%a!<%k$5$;$F$$$?$@$-$^$7$?!#(B
>>>>>>>>>
>>>>>>>>> ha-log$B$rE:IU$$$?$7$^$9$N$G!"$*NO$rB_$7$F$$$?$@$1$k$HBgJQ$"$j$,$?$$$G$9!#(B
>>>>>>>>>
>>>>>>>>> $B4D6-$O0J2<$NDL$j$G$9!#(B
>>>>>>>>> CentOS5
>>>>>>>>> PostgreSQL9.2.4
>>>>>>>>> Pacemaker1.0.13-1.1
>>>>>>>>> Master/Slave$B9=@.(B
>>>>>>>>> $B0J>e(B
>>>>>>>>>
>>>>>>>>> $B$^$?!"(Bha-log$B$N(B7028$B9TL\$"$?$j$K0J2<$N$h$&$JI=<($,$"$j$^$7$?$N$G!"$3$N;~4V(B
>>> $B$K(Berror$B$,H/@8$7$?$3$H$,860x$G%U%'%$%k%*!<%P!<$9$k(B
>>>>>>>>> $BN.$l$K$J$C$?$h$&$K;W$o(B $B$l$^$9!#(B
>>>>>>>>>
>>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]:
>> info: RA
>>> output:
>>>>>>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too
>> many
>>> clients already
>>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>> PostgreSQL template1 isn't
>>>>>>>>> running
>>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>> Connection error
>>>>>>>>> (connection to the server went bad and the session
>> was not
>>> interactive)
>>>>>>>>> occurred while executing the psql command.
>>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]:
>> info:
>>> process_lrm_event:
>>>>>>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1,
>>> cib-update=50710,
>>>>>>>>> confirmed=false) unknown error
>>>>>>>>> $B0J>e(B
>>>>>>>>>
>>>>>>>>> Master$BB&$N%5!<%P!<<+BN$O%@%&%s$7$F$*$j$^$;$s!#(B/var/log/messages$B$N3:Ev;~(B
>>> $B9o$K$OFC$K%m%0$O$J$+$C$?$N$GLdBj$J$/F0$$$F(B
>>>>>>>>> $B$$$k$h$&$K;W$o$l$^$9!#(B
>>>>>>>>>
>>>>>>>>> $B%"%/%;%9$,D9;~4V=8Cf$7$?$N$G(BMaster$BB&$N(BPostgreSQL$B$N@_Dj$K$"$C$?(B
>>> max_connections=100$B$N>uBV$,B3$$$F$7$^(B
>>>>>>>>> $B$$!"(BSlave$BB&$NDL?.$K1~Ez$7$J$+$C$?(B
>> $B$?$a%U%'%$%k%*!<%P!<$7$F$7$^$C$?$N$G$O$J$$$+$HM=A[$7$F$_$?$N$G$9$,!"$=$&(B
>>> $B$$$C$?$3$H$O9M$($i$l$^$9$G(B $B$7$g$&$+!#(B
>>>>>>>>> $B0J>e!"$*K;$7$$$H$3$m62=L$G$9$,!"$h$m$7$/$*4j$$$$$?$7$^$9!#(B
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>>>>
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>>>
>>> _______________________________________________
>>>>>>>> Linux-ha-japan mailing list
>>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>>
>>>>>>>>
>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>
>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux-ha-japan@lists.osdn.me
>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>> Linux-ha-japan mailing list Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan