今天一位开发的同事把我拉去开会，其中有聊到多IDC部署数据库的需求，并且数据库之间要求数据同步。后来因为复杂度并且应用程序可以忍受主库DOWN机，所以决定不上multi-master。不过还是引发了一下我对multi-master的思考。
大概是一个这样的场景:
多个IDC之间会需要同步部分数据，每个IDC有自己的本地数据（不需要同步），最终每个IDC的数据库中的全局数据要求一致。
然后各个IDC要有自己的hot-standby数据库。
首先是同步使用到的技术：
1. sync方案，two phase commit,
可以让应用来做跨库事务，那就不需要数据库惨和了。
或者用PostgreSQL 自身的dblink和two phase commit 技术。
2. async方案，数据库复制软件，例如 slony-I .
3. async方案，数据库触发器和dblink.
然后是全局数据表的设计：
1. 分表，使用不同的表名字，相互复制记录逻辑上隔离，不需要考虑冲突的问题。
分表的目的是使用单向复制软件，如slony-I。
例如IDC A：
IDC B：
IDC C：
global_table_a rw
global_table_b replication from IDC B,read only in IDC A.
global_table_c replication from IDC C,read only in IDC A.IDC B：
global_table_a replication from IDC A,read only in IDC B.
global_table_b rw
global_table_c replication from IDC C,read only in IDC B.IDC C：
global_table_a replication from IDC A,read only in IDC C.
global_table_b replication from IDC B,read only in IDC C.
global_table_c rw
优点是不需要考虑冲突，而且可以使用单向复制软件。
缺点是增加MASTER节点的话，需要新建表。可能还需要改程序。当然也可以建立父表，增加继承表的方式，不改程序，但是又会引起和SLONY-I不兼容的问题，如触发器。
2. 共享表，使用同一个表名，相互复制同一个表里面的记录，可能需要考虑冲突的问题。
例如IDC A：
global_table
IDC B：
global_table
IDC C：
global_table
优点是所有节点使用一个表名，增加节点比较方便，对应用透明。
确定是可能需要考虑冲突，但是这个应该在应用设计的阶段避免修改从别的IDC同步过来的记录。
先thinking这些。
