[Pgpool-general] PGPool Queries

vic vic at digi.com.ph
Wed Mar 1 15:11:54 GMT 2006


Hi everyone,

 

 

I'm trying out pgpool-3.0.1 on two Linux-2.4.x machines clustered in LVS-DR
manner using heartbeat-1.3.2 and the noarp module. With my LVS-DR setup,
only the current Master Node can respond and service remote DB clients via
the Virtual IP.

 

My server application uses Postgres-7.4.11 as backend DB. In addition to my
remote clients being served via VIP, my servers also have internal/local
clients performing DB writes to their respective databases.

 

To satisfy the requirements, I have setup PGPgpool in Strict, Replication
Mode on both Nodes, running at port 5432, and Postgres at port 9999. The
current Master runs in "-s m", and the other in "-s s" mode.

 

My setting for both Nodes is as follows:

 

#---------------------------------------------------------------------------
--------

listen_addresses='*'

port=5432

socket_dir='/tmp'

backend_host_name='node1'

backend_port=9999

backend_socket_dir='/tmp'

secondary_backend_host_name='node2'

secondary_backend_port=9999

num_init_children=32

max_pool=4

child_life_time=300

connection_life_time=120

child_max_connections=0

logdir='/tmp'

replication_mode=true

replication_strict=true

replication_timeout=5000

load_balance_mode=false

weight_master=0.5

weight_secondary=0.5

replication_stop_on_mismatch=false

reset_query_list='ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'

print_timestamp=true

master_slave_mode=false

connection_cache=true

health_check_timeout=20

health_check_period=0

health_check_user='nobody'

insert_lock=false

ignore_leading_white_space=true

#---------------------------------------------------------------------------
--------

 

>From my tests, PGPool seem to function OK if my test only involves a single
remote client, or if my client transactions on similar data are not being
done simultaneously. But when my tests involve numerous clients performing
simultaneous DB updates, mostly on similar data, problems start to happen.
Most of the time PGPool blocks or hangs up while the backend Postgres at
port 9999 still works. 

 

And sometimes during my tests, I also perform a manual "createdb" command on
one Node, and a "dropdb" on the other, then check for results. At some point
during this routine, PGPool on one Node crashes. I consider PGPool to be in
a "crashed" state when the DB service is no longer available on port 5432
but is still running on port 9999. And during such case, the nymber of
pgpool instances on the failed Node is drastically reduced! With this
scenario, I had to stop pgpool (or kill the remaining instances), then start
pgpool again on the Node where it crashed in order to continue the
replication.

 

Now here are my questions:

 

-          Is my config above correct?

-          I also plan to loadbalance PGPool at a service level using
ldirectord via VIP, is it OK for me to do it?

-          Although I can direct my remote Clients to access one Node only
when performing DB access, but by design, my server application also perform
DB updates locally. Will PGPool be able to satisfy my requirement as my
setup performs DB updates from remote and local (on both nodes) Clients? If
so, how do I do this properly?

-          Are there any plans for PGPool to have something similar to what
PGCluster is doing? I mean above Two-Node clustering? My server Application
is a bit huge already. And I noticed that PGCluster requires a great amount
of resource in order for it to run satisfactorily for long periods. PGPool
however, seem more lighter than PGCluster. It's great if I can make my
requirements work using PGPool.

 

 

I will continue testing PGPool to somehow give more details regarding the
problems I encounter. If anyone on the list can correct my configuration or
give me advice how to go about with my problems, please feel free to send me
your suggestions/tips.

 

 

TIA and Best regards,

Vic

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/pgpool-general/attachments/20060301/b8dee627/attachment.html


More information about the Pgpool-general mailing list