Tungsten multi replication
简单介绍
Tungsten 提供的是一种类似于xtradb cluster的多主复制方式，其核心思想是多个Master同时维护一份数据。
xtradb cluster维护的是一个环形结构通过在Mysql代码曾进行加锁来保证数据一致性，而Tungsten则是简单的依赖于Binlog的Transfer和Apply来保证所有Master节点的数据都是一致的，并且Tungsten并不是简单的维护一个环形结构而是一种更复杂的结构。
拓扑结构
下面这张图就是Matser节点为4个的情况下的一个拓扑结构：
可以看出其对应关系非常复杂，任何一个Master节点写的Binlog都要向其他三个节点进行传输，如果要再加一个节点的话就会是这样：
其实这样最大的好处就是比较灵活，我可以把一台Mysql的Binlog放在任何一台或者多台Myqsql上执行。
其实这个结构是什么样完全取决于怎么配的。
实现原理
下面就两个Master节点的情况下对他的原理进行说明。
如图所示一共有两个Master节点：Sjc和Nyc
每一个Master节点对应两个服务LocalService和RemoteService，如图所示：Sjc的LocalService会把Binlog解析成TungstenLog推送到Nyc的RemoteService上并且在Nyc上执行，同样Nyc的LocalService会把Binlog解析成TungstenLog推送到Sjc的RemoteService上并且执行。
这样会有一个问题：
会不会出现无线循环的推送，比如说在Sjc生成的Binlog执行到Nyc上，在Nyc上Apply这个Binlog以后生成的Binlog会不会再次传到Sjc上执行？
Tungsten使用BidiRemoteSlaveFilter来防止这种情况的发生，简单的理解他会加一个标记符来标记这个SQL语句是在本机执行的还是远程传输过来的。比如说在Sjc上执行的SQL语句传输到Nyc上，在Nyc上执行以后就会在Binlog里加一个注释，来表明是从哪一个LocalService传送过来的，这样他就能知道把需要哪些Binlog传送到别的机器上。
insert into xx values (911) /* ___SERVICE___ = [test1] */
Tungsten的问题
Tungsten完全是根据Binlog解析成TungstenLog传输到别的机器再Apply来保证数据完整性的，所以这个过程中问题会很多。
假设这样一种情况：
master1 开启事务执行一条Update，修改一条记录。
Master2 同时开始事务执行Delete，删除Master1修改的记录，并提交。
单节点的情况下会被锁住，但是在Tungsten这种复制关系中会直接报错。
在TungstenLog的传输过程中有可能会遇到延迟等网络问题或者Tungsten本身服务挂掉，这时候各个节点数据之间的一致性是无法保证的。
虽然Tungsten有着这样那样的问题，但是tungsten 他很灵活，他能实现多Master写到一个slave。这样对我们合并多个Slave有很大帮助。