浅谈MySQL Replication(复制)基本原理

核心提示： 从官方文档中看到，之前的MySQL一直都只有基于statement的复制模式，浅谈MySQL Replication(复制)基本原理(4)，直到5.1.5版本的MySQL才开始支持row level的复制，从5.0开始，除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，My

从官方文档中看到，之前的MySQL一直都只有基于statement的复制模式，直到5.1.5版本的MySQL才开始支持row level的复制。从5.0开始，MySQL的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给MySQL Replication复制又带来了更大的新挑战。另外，看到官方文档说，从5.1.8版本开始，MySQL提供了除Statement Level和Row Level之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样，仅仅记录执行的语句。而新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。

3、MySQL Replication复制常用架构

MySQL Replication复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。

一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的binlog信息，返回给slave的IO进程。对于slave的配置细节，在MySQL的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave的配置方法。

MySQL不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。MySQL AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。

MySQL也可以搭建成dual master模式，也就是说两个MySQL instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形：

时间点　　 MySQL A　　　　　　　　　　　　　　　　　　　　　　　 MySQL B

1　　　 更新x表y记录为10

2　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 更新x表y记录为20

3　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 获取到A日志并应用，更新x表的y记录为10（不符合期望）

4　　　 获取B日志更新x表y记录为20（符合期望）

这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。