[Pgpool-general] PgPool install, Part Deux

[Marc G. Fournier]

On Tue, 7 Jul 2009, J. Carlos Muro wrote:

> Hi, Marc!
>
> 2009/7/7 Marc G. Fournier <scrappy at hub.org>
>
>> Last time I tried, something got "out of sync", ended up breaking the 
>> cluster and going to one DB until I had time to dive better into it, 
>> with two brand new servers ... so, I'm going to make attempt two at 
>> this ...
>>
>
> Be sure that both your nodes are a "hard copy" one of the other. For 
> example, use tar+gzip+cp or rsync in order to copy the whole pg-cluster 
> from one node to another.

I'm building this from scratch, actually ... two brand new 8.4.0 installs, 
with any interaction with them going *through* pgpool ... there is nothing 
local to the machine(s) that are touching them ...

>> load_balance_mode?
>
>
> From the docs:
> load_balance_mode:
> When set to true, SELECT queries will be distributed to each backend for
> load balance. Default is false.
>
> So, if you want to load balance your selects do use it! :)

Right, but does that mean that the same SELECT will be run on each node 
simultaneously, or only passed to one nodes?  If the former, would kinds 
defeat the point of 'load balancing', but if you read the docs, that is 
what it implies :)

>> replication_stop_on_mismatch?
>
>
> From the docs:
> replication_stop_on_mismatch:
> When set to true, pgpool-II degenerates the backends and keeps the service
> only with the Master DB if data mismatch occurs. If false, pgpool-II just
> terminates the query. Default is false.

But, if I'm doing replication / load balancing ... which is Master, which 
is Slave?  Therefore, which one gets degenerated?  The Docs, again, do not 
make this clear ...

> AFAIU, we could say that if this option is enabled, then in case that pgpool
> finds data mismatch between nodes, it will degenerate 'not master nodes', in
> other words, it deactivates replication. It could be interesting for
> production enviroments..


Well, considering that I'm running this as a backend to something that 
will be *very* visible to the PostgreSQL community at large (ie. the 
mailing lists), I'd rather would with facts vs "intersting for production 
enviroments" ... your comment almost implies that pgpool isn't even ready 
for production environments yet ... is that the case?

If pgpool-II is not ready for a production environment, please do let me 
know ... what I'm trying to implement is something that will be visible to 
the PostgreSQL community at large, and would hate to create a shadow 
because I used something that wasn't production ready :(

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy at hub.org                              MSN . scrappy at hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664