成为数据治理专家：MySQL主从复制模式

概述

「什么是 MYSQL REPLICATION」

1. Replication 可以实现将数据从一台数据库服务器（master）复制到一或多台数据库服务器（slave）
2. 默认情况下属于异步复制，无需维持长连接
3. 通过配置，可以复制所有的库或者几个库，甚至库中的一些表
4. 是 MySQL 内建的，本身自带的

「REPLICATION 的原理」

简单的说就是 master 将数据库的改变写入二进制日志，slave 同步这些二进制日志，并根据这些二进制日 志进行数据操作。

DML:SQL操作语句，update,insert，delete 。

Relay log :中继日志

「REPLICATION的作用」

1. Fail Over   故障切换
2. Backup Server 备份服务，无法对SQL语句执行产生的故障恢复，有限的备份
3. High Performance高性能，可以多台slave,实现读写分离

「REPLICATION如何工作」

整体上来说，复制有3个步骤：

1. master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
2. slave将master的binary log events拷贝到它的中继日志(relay log)；
3. slave重做中继日志中的事件，修改salve上的数据。

「MySQL主从复制过程」

第一步：master记录二进制日志。在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后， master通知存储引擎提交事务。

第二步：slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经执行完master产生的所有文件，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。

第三步：SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重新执行其中的事件而更新slave的数据，使其与master中的数据一致。

总结来说，MySQL 的主从复制：异步单线程。

Master上 1 个IO线程，负责向Slave传输 binary log（binlog） Slave上 2 个线程：IO 线程和执行SQL的线程，其中：IO线程：将获取的日志信息，追加到relay log上；执行SQL的线程：检测到relay log中内容有更新，则在Slave上执行sql；

REPLICATION 常见方案

「ONE MASTER AND MUTI SALVE  一主多备」

一般用来做读写分离的，master写，其他slave读，这种架构最大问题I/O压力集中在Master上,多台同步影响IO。

「M-S-S」

使用一台slave作为中继，分担Master的压力，slave中继需要开启bin-log,并配置log-slave-updates。Slave中继可使用Black-hole存储引擎，不会把数据存储到磁盘，只记录二进制日志。

「M-M 双主互备(互为主从)」

很多人误以为这样可以做到MySQL负载均衡，实际没什么好处，每个服务器需要做同样的同步更新，破坏了事物的隔离性和数据的一致性。

「M-M-M Multi-Master Replication Manager for MySQL」

监控三台机器互相做对方的master。天生的缺陷：复制延迟，slave上同步要慢于master,如果大并发的情况那延迟更严重Mysql在5.6已经自身可以实现failover故障切换。

Multi-Master Replication Manager for MySQL，取其中的三个M开头的单词简写。它是mysql多主复制管理器，基于perl实现，关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），MMM也能对从服务器进行读负载均衡，所以可以用它来在一组用于复制的服务器启动虚拟ip，除此之外，它还有实现数 据备份、节点之间重新同步功能的脚本。

MySQL本身没有提供replication failover的解决方案，通过MMM方案 能实现服务器的故障转移，从而实现mysql的高可用。MMM不仅能提供浮动IP的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。

M-M-M 架构的优点：

1. 可以兼容不同系列的MySQL来做高可用。比如有MySQL官方社区版本，有percona版本的，有MariaDB版本的MySQL。这样的集群可以可以使用MMM架构来做高可用。
2. 高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证 的数据的一致性。
3. 当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。

M-M-M 架构的缺点：

1. 是一种比较老的MySQL高可用实现方式，因为社区不活跃，所以目前已经没有人在维护这个组件了。

2. 只能基于日之点的主从复制集群架构来做高可用，不支持基于GTID的主从复制集群架构。这也是因为社区活跃，没有维护这个组件导致不支持GTID。

3. 数据不能保证100%的一致性，这个是以为它在做故障转移的时候实现的方式所导致的。如果对于数据需要强一致性，则不能选择MMM高可用架构，可以考虑MHA高可用架构。

4. monitor节点是单点，不过这个可以结合keepalived或者haertbeat做成高可用。

5. 至少三个节点，2个master，1个slave，对主机的数量有要求，

6. 在读写非常繁忙的业务系统下表现不是很稳定，可能会出现复制延时、切换失效等问题。

7. MMM方案并不太适应于对数据安全性要求很高，并且读、写 繁忙的环境中。

8. 需要实现读写分离，还需要在前端编写读写分离程序，或者结合数据库中间件来解决。

欢迎加入 DevXTalk 的技术交流群,在这里你可以和大佬们一起交流分享技术,行业经验,提升自我。结识新的业内朋友，扩大自己的圈子，当你想换工作的时候也许就能拿到不错的 offer 。总之期待你的加入...

「看完本文有收获？转发给更多的朋友吧」

「DevXTalk 不止于技术」