分布式数据存储

     上篇文章《分布式数据存储 - MySQL主从复制》，我们说到MySQL主从复制很好的保障了从库，读的高可用性。so，问题来了：

1、针对主库，写的高可用性又是如何做到高可用性？

2、如果需要对Master进行维护或宕机，为了不影响写服务，我们可能会将Slave节点提升为Master来提供写服务。当Master节点可以正常提供服务时，可能会发现Master中数据和实际数据不一致的情况，就不得不 反转原来的Master-Slave关系重新搭建Replication环境，进行新的主从节点数据同步，新的Slaver节点提供读服务。这种方式我们不仅要重新搭建Replication环境，还要处理数据同步postion位置，甚至数据冲突。那么有没有更好的处理方法？

一般的解决方法采用双主模式。

一、MySQL双主复制(Dual Master)                                                            

      

Dual Master，既是master，又是另一台服务器的slave。这样，任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

双主复制的复制过程和主从复制类似的，这里就不再赘述。

双主复制需要注意哪些问题？数据完整性、数据一致性和主键冲突

1、尽可能通过业务场景设计来规避，对于同一个库，同一张表，同一个记录中的同一字段的两地变更，引发的数据一致性判断冲突。

2、避免使用数据库自增类主键方案，而使用分布式全局ID，避免双主双写并同步复制可能引发主键冲突。

3、双向同步复制Dual Master潜在可能引发循环同步的问题。

• 在MySQL的Binary Log中记录了当前MySQL的server-id，而且这个参数也是我们搭建MySQLReplication的时候必须明确指定，并且参数值不一致。一旦有了server-id的值之后，MySQL就很容易判断某个变更是从哪一个MySQL Server最初产生的，所以就很容易避免出现循环复制的情况。
• 如果我们不打开记录Slave的Binary Log的选项（--log-slave-update）的时候，MySQL根本就不会记录复制过程中的变更到BinaryLog中，就更不用担心可能会出现循环复制的情形了。

我们从MySQL的Dual Master的循环复制方案中看出，就是在Binary Log中打上标记，就有办法判断哪些Binary Log是复制产生的，并将其过滤。

复制过滤可以让你只复制服务器中的一部分数据，有两种复制过滤：在master上过滤二进制日志中的事件；在slave上过滤中继日志中的事件。

     

二、自定义标记SQL方案                                                                             

     Dual Master的循环复制方案过于依赖配置，可以考虑一种通用的标记 SQL 方案。简单来说，就是在同步复制入库时插入特殊的标记 SQL 语句来标记这是来自复制程序的变更，这个标记 SQL 会进入 binlog 中。而在复制程序读取时，通过识别这个标记 SQL 来过滤判断。

binlog 中存储了对数据产生变更影响的的 SQL 语句，这些 SQL 语句组成了一段一段的事务，如下图所示：

（http://www.cnblogs.com/mindwind/p/4993708.html）

绿色区是业务运行产生的正常事务，红色区是复制程序写入产生的事务，其中蓝色块是标记 SQL。标记 SQL 分别在事务开始后与事务结束前，标记 SQL 更新一张预定义的区别于业务表的标记表。那么每次复制程序去批量读取 binlog 内容时，可能存在下面 5 种情况，如下图所示：

（http://www.cnblogs.com/mindwind/p/4993708.html）

1. 批量读取范围全落在绿色区内。
2. 批量读取范围起点落在绿色区，终点落在红色区。
3. 批量读取范围起点落在红色区，终点落在绿色区。
4. 批量读取范围起点和终点都在绿色区，但中间涵盖了一段红色区。
5. 批量读取范围全落在红色区。

如上只有第 5 种情况，一个事务被拆成 3 段来同步。中间一段因为没有事务头和尾的标记，复制程序读取时将无法判断，导致循环同步，需要避免。通过把复制程序的批量读取范围固定设置为至少大于或等于写入的事务长度范围，避免了第 5 种情况。复制程序批量读取 binlog 日志事件时，通过标记 SQL 来过滤，避免了循环复制，实现了回环控制。