MYSQL数据复制技术

一、复制模型

上述mysql复制模型中，Master代表主库，Slave表示分库

1. 当有操作进来时，先写入主库
2. 事务提交之后，主库操作会生成Binary Log语句
3. 主库的Log Dump Thread线程会读取Binary Log语句，与从库的IO线程进行通信
4. 从库的IO线程收到语句之后，写入Relay Log文件
5. 使用从库SQL线程真正把数据写入从库进行保存

这个写入过程就是主从延迟的原因

主库数据在Binary Log里面如何存放呢？这里涉及一个参数binlog-format
这个参数代表了在Binary Log数据存在的格式。

1.1 ATATEMENT：语句模式

记录主库操作的原SQL，保存下来，在从库重新执行一遍
问题：
有的表使用随机数作为字段值，随机数是在mysql中生成的，语句中并没有携带具体的数值，这个时候，在主库保存的数据与从库就会有差异。嗯，不可接受。

1.2 ROW：行模式

相比较于语句模式，行模式会记录原SQL和随机数的值，从库不再自己生成，就会保持一致。
5.7.6版本之后均为行模式

1.3 MIXED：混合模式

语句模式与行模式混合的一种模式，默认是语句复制，由存储引擎自动切换到行模式。

二、复制方式

2.1 异步复制

异步复制，Master代表的主流程在将Binary Log数据保存之后，会通知客户端，sql已经执行完成，在这个过程中，从库开始异步读取语句并保存。
如果这个时候，主从服务有问题，主库的线程会继续操作并提交sql，但是从库拿不到最新数据，为了保证高可用，一般情况下的处理，就是以拥有最新数据的从库临时作为主库，那么，主库后来操作的那些数据其实是拿不到的。

2.2 半同步复制

主库提交，等待几个节点之后再向客户端通知，这个间隙留给mysql去连接从库发送消息，等待从库接收。
这个等待的节点数量是可配置的。

从库未连接成功，主库不会给客户端发消息,如果服务连接失败，客户端发现此次提交失败,会重新选择一个从库作为主库，
所以这种配置可以避免连接从库服务断开导致的数据丢失。

问题：
目前很多数据库表采用的是主键自增的方式，主库中的数据，虽然没有给客户端响应成功的消息，但是数据却真实的存在，此时从库变主库，客户端会将刚才未成功的事务重新发送一遍，从库的主键数据自增成功之后，原来的主库去复制数据，会出现主键冲突。

2.3 增强半同步复制

此次方式又叫：无损复制
主库在写完binlog之后就通知从库来复制，保证从库已经连接，等待几个节点之后，再提交客户端，将风险前移。
此时主库服务断开，选择从库变主库之后，所有未完成的事务会重新请求一次。
这块有一个小细节。

并不是主库没有执行操作数据，mysql有一个东西叫：REDO。redo就是等待执行的意思，虽然没有最终提交，但是会检测出来有redo，会继续执行操作的进行提交。

此时会有一个判断，发现有redo,但是没有提交，两种处理方式。
1、主库进行闪回。【建议】
2、重建【数据量大耗时】

2.4 组复制

全局一致性校验

2.5 多源复制

将多个主库的数据会再陪你过到一台从库，一把用于分析，灾备

2.6 延迟复制

从库延迟一段时间之后重放事务
使用场景：对主库误操作的不久措施，由于从库只接受，未重放，因此可基于时间点恢复。

异步复制 》 组复制 【数据量越大性能越不好】 》 半同步复制