Database Replication的数据同步方式

为保证数据在各数据库副本上的一致性，Replication需要频繁同步数据，下文谈谈三种同步方式，以MySQL上的master-slave模型为例。

同步方式（Synchronous）

如果master接收更新请求后，在自身执行的同时将信息传播给所有slave，并要等收到所有slave获得更新信息的反馈之后才返回，那此同步过程会大大拖累性能。这个道理很容易理解，而MySQL Cluster号称拥有Synchronous Replication的特性，我确实还没搞清它怎样能做到。

异步方式（Asynchronous）

典型MySQL上的Replication是异步的，master处理完更新请求后返回，不等待slave获取到更新信息。借用51CTO.com的这张图来介绍下异步Replication的过程吧。

1. master上有更新到来，先将更新存入binary-log中；
2. master上的sql进程执行Database更新，同时master将有新更新的消息散播出去，让各slave随时来请求，这个散播互动的过程通常是基于publish-subscription的；
3. 某slave向master发来IO请求，指定要binary-log上某偏移量之后的跟更新信息；
4. master接受IO请求，并返回所请求的更新信息，以及binray-log上当前的偏移量；
5. slave收到IO反馈，将收到的更新信息追加到relay-log末尾，并将binray-log偏移量记录到master-info文件中，然后向master返回Acknowledge消息；
6. slave的sql进程监测到relay-log中有新内容后，会立即在database上执行更新。

根据binary-log的信息存储形式，Replication又可区分为如下三种级别，相应都在MySQL上有配置。

• Row level　–　Binary Log 中会记录成每一行数据被修改的形式，然后在 Slave 端再对相同的数据进行修改，不用在乎执行的sql语句的上下文相关的信息。显然此方法log中数据量巨大。
• Statement level　–　每一条会修改数据的 Query 都会记录到 Masterçš„ Binary Log 中。log中不存在大量数据了，但它不得不记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。这种结果常因为query语句无法完美Replicate而出现数据不一致。
• Mixed level　–　它是上两种方法的折中，会根据执行的每一条具体的 Query 语句来区分对待记录的日志形式，也就是在Statementå’ŒRow之间选择一种。

半同步方式（Semi-synchronous）

又是一个典型的折中。因为上面提到的异步方式下，master不管slave数据更新的进度，若slave出现明显的落后（Lag），数据不一致的问题和单点故障的风险都会被放大；而完全同步的方式对性能的损害又过大。

借用orczhou.com的图片如下来解释半同步方式。

在半同步的方式下，master等待至少一个slave收到更新，即等待其Acknowledge消息，以此保证至少有一个slave在master突然宕机的情况下能够不丢失数据，并迅速代替master机器。不过如果等待时间超过限制，半同步模式会自动转为异步模式，不再等待slave。

Reference

• 半同步方式的更多解释，http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
• master-slave在MySQL上的配置，http://members.cox.net/midian/howto/mysqlReplication.htm