Re: [Postgres-xc-general] ERROR: Failed to get pooled connections

[Vladimir S. <vst...@gm...>]

On Fri, Jul 20, 2012 at 06:18:22PM +0900, Michael Paquier wrote:

>    Like postgreSQL, you can attach a slave node to a datanode and then perform a failover on it.
>    After the master node fails for a reason or another, you will need to promote a slave waiting behind.
>    Something like pg_ctl promote -D $DN_FOLDER is enough.
>    This is for the Datanode side.
>    Then what you need to do is update the node catalogs on each Coordinator to allow them to redirect to the new promoted
>    node.
>    Let's suppose that the node that failed was called datanodeN (you need the same node name for master and slave).
>    In order to do that, issue "ALTER NODE datanodeN WITH (HOST = '$new_ip', PORT = $NEW_PORT); SELECT pgxc_pool_reload();"
>    Do that on each Coordinator and then the promoted slave will be visible to each Coordinator and will be a part of
>    cluster.

If You don't do this every day there are chances You make an error. How
much time it take in this case? As I wrote above, it is not own XC HA
feature, but rather external cluster infrastructure. As such it is better
to use mentioned above tandem drbd + corosync + pacemaker - at least it
get failover automated.

>    In 1.0 you can do that with those kind of things (want to remove data from datanodeN):
>    CREATE TABLE new_table TO NODE (datanode1, ... datanode(N-1), datanode(N+1), datanodeP) AS SELECT * from old_table;
>    DROP TABLE old_table;
>    ALTER TABLE new_table RENAME TO old_table;
>    Once you are sure that the datanode you want to remove has no unique data (don't care about replicated...), perform a
>    DROP NODE on each Coordinator,
>    then pgxc_pool_reload() and the node will be removed correctly.

Looks fine! What if there are thousands such tables to be relocated (it
is real case)? And as I see, to do opposite operation, i.e. adding
data node, wee need to use this CREATE/DROP/RENAME TABLE technique again?
It doesn't look like HA.

>    Please note that I working on a patch able to do such stuff automatically... Will be committed soon.

It is hopeful news.

>      DISTRIBUTE BY REPLICATION) XC itself have no neither HA nor LB (at least
>      for writes) capabilities?
>
>    Basically it has both, I know some guys who are already building an HA/LB solution based on that...

What do You mean? As we saw above HA is external and LB is a question
either read or write. Yes, we have one only variant of such solution:
when all tables are replicated we have "internal" HA and "read" LB. But
such solution is implemented in many other technologies apart from XC.
But as far as I understand, the main feature of XC is what named as
"write-scalable, synchronous multi-master"

OK, I still hope, I make right decision choosing XC as cluster
solution. But now summarizing discussed problematic I have further
question: Why do You implemented distribution types on table level? It
is very complex for using and is not transparent. For example, when You
need to install third party application You need to revise their all sql
scripts to add DISTRIBUTE BY statement if You don't want defaults. What
do You think about implementing different data node types (instead of
tables), i.e. "distributed" and "replicated" nodes?

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************