Multi-Master replication是指在集群中所有的节点都能够写入.如果你写错了数据库位置,也不用担心,它会定时做数据同步.
这是一直盼望的特性.
Percona XtraDB Cluster可以在任意节点写入,并且集群能够保证数据的一致性.写的数据要么在所有节点都提交,要么都不提交.下面用两个节点的示例说明一下(多个节点原理是一样的)
所有的查询都在本地的节点执行,只有在COMMIT的时候需要特殊处理.当COMMIT命令发出时,事务需要在所有节点通过认证.如果认证没有通过,那么客户端会返回一个报错.ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
认证通过之后,就在本地节点执行.
COMMIT的响应时间由下面几部分组成:
- 网络往返的时间
- 认证时间
- 本地执行的时间
注意 远程节点上执行事务不影响COMMIT的响应时间,因为它发生认证响应之后,并且在后台执行.
这种架构有两个重要的影响 :
- 首先,我们有很多应用是并发执行的.这种架构提供了真正的并行复制.从库可以有很多并行线程.可以修改wsrep_slave_threads变量调整.
- 其次,从库由主库同步,可能只需要很短的时间,因为主库肯定会先于从库执行,有时,你可能在从库上面读到还未改变的数据.从图中可以看到.然而,这种行为可以通过参数变量wsrep_causal_reads=ON改变,在这种情况下,想要读取从库的数据,需要等待事务执行完(但是,这会增加响应时间).复制之所以被称为"virtually synchronous replication"而不是"synchronous replication",就是因为主库和从库直接存在这种间隔.
COMMIT所描述的行为,还有第二层含义.如果执行的事务写到两个不同的节点上,集群会使用乐观锁(optimistic locking model),这意味着事务在单个查询中不会检查可能存在的锁冲突,但是,在提交阶段,你可能会得到错误响应.因为这是InnoDB的规则,你可能会遇到不兼容的情况.在查询时,经常会出现DEADLOCK和LOCK TIMEOUT的错误响应,而不是在提交时.在COMMIT之后,检查错误代码是一个非常好的方法,但是仍有很多程序不这样做.
如果你想使用Percona XtraDB Cluster在多个节点同时写入的功能,你可能需要处理COMMIT失败之后的返回信息.