Re: [Postgres-xc-general] newbie - testing and initial setup

[鈴木 幸市 <ko...@in...>]

Please see my input inline.
---
Koichi Suzuki

2014/04/07 18:46、Attila Berenyi <att...@se...<mailto:att...@se...>> のメール：

Hi,

I have been testing master-master replication solutions recently, and I have identified three possible solutions/software:

The scenario
Multiple masters located in different offices in the UK (phase 1); all around the globe (phase 2). The servers should be in sync all the time.

Possible solutions
1. Bucardo
2. Postgres-XC
3. EnterpriseDB's xDB Replication Server

Test results
1. Bucardo
Easy to use and set up, but as the data authors at the different offices will create and drop tables quite frequently we cannot really cope with the administration of bucardo, i.e. adding table to the herds. If you have a more or less static dataset or you have a DBA at every site it might work for you though.

2. Postgres-XC
The overall structure of the replication looks pretty convincing but I have a few question:
- I read somewhere/saw in a slide deck (unfortunately I cannot find it any more) that it creates a performance bottleneck to have the coordinator and the datanode on the same machine (VMs in my test case). Is it still valid?

No it is not valid.   Instead, for simpler load balancing between coordinator and datanode, we advice to configure both on the same machine.   This can also utilize data localization for better performance.

- Is it possible to add 'slave' datanodes to the DB cluster, e.g an external web server?

Yes.   pgxc_ctl from contrib module will help much.   You will find the reference at http://postgres-xc.sourceforge.net/docs/1_2_1/pgxc-ctl.html

You will find sample configuration and pgxc_ctl demo scenario from https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=PGOpen2013_Postgres_Open_2013

- Approximate overhead/latency? I guess if the user connects to the local (i.e. the user's office) coordinator and commits some changes, the user still have to wait for the data to be sync'd with all the datanodes in the cluster, right? What if the DB cluser includes coordinators/datanodes from all over the globe?

We’ve not assumed the usecase where coordinators/datanodes are geometrically distributed, not because of the latency but to provide full-featured transaction ACID capability over the cluster.     In the local configuration, this latency is ignorable.

Thank you.


3. EnterpriseDB's xDB Replication Server
TBD

Thanks in advance.

Cheers,
Attila
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR_______________________________________________
Postgres-xc-general mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-general