[Pgpool-general] inconsistency when using two pgpool instances in warm standby?

[Yutaka Tanida]

Hi Edward,

Thank you for your interesting script. However this script has better
pgpool-II handling than pgpool-HA's.
Unfortunately I can't merge into pgpool-HA because of license conflict.
Pgpool-HA's is BSD style but yours is GPL...

Here's some remarks.

-I  do not recommend to use /etc/init.d script to start/stop pgpool and
PostgreSQL. OCF script should have own startup/stop procedures. And the
file name itself is also  problem. (e.g. my Debian Etch environment has
"/etc/init.d/postgresql-7.4" but not "postgresql".)

-Command "status" and "monitor" are same. Usually you can use more small
sanity check such as pid check for "status". Current one is good for
"monitor".

-No "recover" command here. I think if pgpool-II crashes but PostgreSQL
alives, the cluster would be failed over. This unnecsssary failover can
be avoided by having "recover" command to restart pgpool, 

- No OCF-style configuration. There's a lot of inlined values such as
"/var/lib/pgsql/data". It is better to replace them by instance
parameter.

BTW, Should we change the file name of OCF script?  It conflicts
pgpool-HA's one and It doesn't support pgpool-I or  "typical" pgpool-II
configuration. Maybe "pgpool2-wsb" is more better than "pgpool".

Regards,
--
Yutaka Tanida.

> [cut]
> 
> I have deployed PgPool working under control of heartbeat 2.1.4 (v2 - by use
> of CRM).
> 
> - heartbeat config file (/etc/ha/d/ha.cf)
> 
> use_logd yes
> keepalive 10
> deadtime 60
> warntime 20
> initdead 60
> ucast eth1 10.60.70.245
> auto_failback on
> node cbs01 cbs02
> crm respawn
> 
> - cib.xml defines the following pgpool group of resources:
> 
>        <group id="PGP">
>          <primitive class="ocf" id="PGPOOL_IPaddr" provider="heartbeat"
> type="IPaddr">
>            <operations>
>              <op id="PGPOOL_IPaddr_mon" interval="20s" name="monitor"
> timeout="5s"/>
>            </operations>
>            <instance_attributes id="PGPOOL_IPaddr_inst_attr">
>              <attributes>
>                <nvpair id="PGPOOL_IPaddr_attr_0" name="ip" value="
> 10.60.70.247"/>
>                <nvpair id="PGPOOL_IPaddr_attr_2" name="cidr_netmask"
> value="28"/>
>                <nvpair id="PGPOOL_IPaddr_attr_3" name="broadcast" value="
> 10.60.70.255"/>
>              </attributes>
>            </instance_attributes>
>          </primitive>
>          <primitive class="ocf" id="PGPOOL" provider="heartbeat"
> type="PgPool">
>            <operations>
>              <op id="PGPOOL_mon" interval="120s" name="monitor"
> timeout="20s"/>
>              <op id="PGPOOL_start" name="start" timeout="600s"/>
>            </operations>
>          </primitive>
>        </group>
> 
> - primitive resource PGPOOL is controlled by the OCF script (see attached
> file)
> - OCF scripts use parameters from /etc/pgpool.conf (see atteched file) and
> it uses PCP commands
>  to attach/detach/recovery/... operations on backend databases.
> 
> This provides running single (hence synchronized) pgpool instance accessed
> via virtual IP address that migrates together with pgpool over cluster nodes
> in case failure occurs . OCF script is bothering on attaching/detaching the
> underlying backends (with data synchronization if required) when
> starting/stopping the pgpool instance.
> 
> I can prepare ./contrib/ branch of heartbeat configuration resources to the
> 2.2 relese if you are interested in.
> 
> regards,
> Edward Pilipczuk

-- 
Yutaka Tanida <y.tanida at sra-europe.com>