Mysql-主从复制

一、主从复制的作用和原理

主从复制的作用
主从同步设计不仅可以提高数据库的吞吐量，还有以下 3 个方面的作用。
第1个作用：读写分离。
第2个作用就是数据备份。
第3个作用是具有高可用性。

主从复制的原则:
每个 Slave 只有一个 Master
每个 Slave 只能有一个唯一的服务器ID
每个 Master 可以有多个 Slave

主从复制的实现原理:
Slave 会从 Master 读取 binlog 来进行数据同步。

实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于 3 个线程 来操作，一个主库线程，两个从库线程。

二进制日志转储线程 （Binlog dump thread）是一个主库线程。当从库线程连接的时候，主库可以将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上 加锁 ，读取完成之后，再将锁释放掉。
从库 I/O 线程 会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （Relay log）。
从库 SQL 线程 会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步。

复制三步骤
步骤1： Master 将写操作记录到二进制日志（ binlog ）。
步骤2： Slave 将 Master 的binary log events拷贝到它的中继日志（ relay log ）；
步骤3： Slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的，而且重启后从 接入点 开始复制。

复制的最大问题： 延时

一台 主机 用于处理所有 写请求 ，一台 从机 负责所有 读请求 ，架构图如下：

一主一从的架构模式能够缓解数据库的读写请求,主库负责客户端的写操作,从库负责读请求;通过Binlog日志实现主从数据的复制。

二、BinLog文件格式

格式1： STATEMENT模式

	binlog_format=STATEMENT  #基于SQL语句的复制(statement-based replication, SBR）

每一条会修改数据的sql语句会记录到binlog中。这是默认的binlog格式。

SBR格式的优点:

1.历史悠久，技术成熟
2.不需要记录每一行的变化，减少了binlog日志量，文件较小
3.binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
4.binlog可以用于实时的还原，而不仅仅用于复制
5.主从版本可以不一样，从服务器版本可以比主服务器版本高

SBR 的缺点：

1.不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候
使用以下函数的语句也无法被复制：LOAD_FILE()、UUID()、USER()、FOUND_ROWS()、SYSDATE()
(除非启动时启用了 --sysdate-is-now 选项)
2.INSERT … SELECT 会产生比 RBR 更多的行级锁
3.复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
4.对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发
生变化的记录产生影响
5.执行复杂语句如果出错的话，会消耗更多资源
6.数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错

格式2： ROW模式（基于行的复制(row-based replication, RBR)）

	binlog_format=ROW

5.1.5版本的MySQL才开始支持，不记录每条sql语句的上下文信息，仅记录哪条数据被修改了，修改成什么样了。

RBR 的优点：

1.任何情况都可以被复制，这对复制来说是最 安全可靠 的。（比如：不会出现某些特定情况下的存储过程、function、trigger的调用和触发无法被正确复制的问题） 多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
2. 复制以下几种语句时的行锁更少：INSERT … SELECT、包含 AUTO_INCREMENT 字段的 INSERT、
3. 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句 执行 INSERT，UPDATE，DELETE 语句时锁更少
4.从服务器上采用 多线程 来执行复制成为可能

RBR 的缺点：

1.binlog 大了很多
2.复杂的回滚时 binlog 中会包含大量的数据 主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到binlog 中，而 SBR 只会写一 次，这会导致频繁发生 binlog 的并发写问题
3.无法从 binlog 中看到都复制了些什么语句

格式3：MIXED模式（混合模式复制(mixed-based replication, MBR)）

	binlog_format=MIXED

从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
在Mixed模式下，一般的语句修改使用statment格式保存binlog。如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog。MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

三、同步数据一致性问题

主从同步的要求：
读库和写库的数据一致(最终一致)；
写数据必须写到写库；
读数据必须到读库(不一定);

进行主从同步的内容是二进制日志，它是一个文件，在进行 网络传输 的过程中就一定会 存在主从延迟（比如 500ms），这样就可能造成用户在从库上读取的数据不是最新的数据，也就是主从同步中的 数据不一致性 问题。

主从延迟问题

在网络正常的时候，日志从主库传给从库所需的时间是很短的，即T2-T1的值是非常小的。即，网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。
主备延迟最直接的表现是，从库消费中继日志（relay log）的速度，比主库生产binlog的速度要慢
造成原因：
1、从库的机器性能比主库要差
2、从库的压力大
3、大事务的执行

举例1：一次性用delete语句删除太多数据
举例2：一次性用insert…select插入太多数据
举例:3：大表DDL
结论：后续再删除数据的时候，要控制每个事务删除的数据量，分成多次删除。

如何减少主从延迟

若想要减少主从延迟的时间，可以采取下面的办法：

1. 降低多线程大事务并发的概率，优化业务逻辑
2. 优化SQL，避免慢SQL， 减少批量操作 ，建议写脚本以update-sleep这样的形式完成。
3. 提高从库机器的配置 ，减少主库写binlog和从库读binlog的效率差。
4. 尽量采用 短的链路 ，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。
5. 实时性要求的业务读强制走主库，从库只做灾备，备份。

如何解决一致性问题

如果操作的数据存储在同一个数据库中，那么对数据进行更新的时候，可以对记录加写锁，这样在读取的时候就不会发生数据不一致的情况。但这时从库的作用就是 备份 ，并没有起到 读写分离 ，分担主库读压力 的作用。

读写分离情况下，解决主从同步中数据不一致的问题， 就是解决主从之间 数据复制方式 的问题，如果按照数据一致性 从弱到强 来进行划分，有以下 3 种复制方式。

方法 1：异步复制

事务没有进行提交的时候就将binlog进行复制,Slave进行消费后提交事务;Slave需要比Master后commit事务,如果Master事务回滚,Slave事务也需要回滚。这种方法是不安全的。

方法 2：半同步复制

方法 3：组复制
异步复制和半同步复制都无法最终保证数据的一致性问题，半同步复制是通过判断从库响应的个数来决定是否返回给客户端，虽然数据一致性相比于异步复制有提升，但仍然无法满足对数据一致性要求高的场景，比如金融领域。MGR 很好地弥补了这两种复制模式的不足。

组复制技术，简称 MGR（MySQL Group Replication）。是 MySQL 在 5.7.17
版本中推出的一种新的数据复制技术，这种复制技术是基于 Paxos 协议的状态机复制。

组复制技术MGR 是如何工作的

首先我们将多个节点共同组成一个复制组，在 执行读写（RW）事务 的时候，需要通过一致性协议层（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于 （N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对 只读（RO）事务 则不需要经过组内同意，直接 COMMIT 即可。在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证组内数据的一致性。

MGR 将 MySQL 带入了数据强一致性的时代，是一个划时代的创新，其中一个重要的原因就是MGR 是基于 Paxos 协议的。Paxos 算法是由 2013 年的图灵奖获得者 Leslie Lamport 于 1990 年提出的，有关这个算法的决策机制可以搜一下。事实上，Paxos 算法提出来之后就作为 分布式一致性算法 被广泛应用，比如Apache 的 ZooKeeper 也是基于 Paxos 实现的。