引言
内容为慕课网的《高并发 高性能 高可用 MySQL 实战》视频的学习笔记内容和个人整理扩展之后的笔记，这一节讲述搭建Mysql三高架构中的复制，Mysql的复制在实战中实现比较简单，但是Mysql针对复制的内部优化却是一直在进行，这样说明这是值得重视和学习的内容，所以本节针对复制这一特征介绍相关的理论内容。
如果内容比较难可以跟随《Mysql是怎么样运行》个人读书笔记专栏补补课：
地址如下：从零开始学Mysql。
什么是“三高”架构？
三高架构比较好理解，这里简单过一遍：
- 高并发：同时处理多条事务数高
- 高性能：SQL 执行效率高
- 高可用：系统可用率达到99%以上。
三高是目的不是手段
三高架构的关键在于三个关键字：复制，扩展，切换。
复制：数据冗余，binlog传送，并发量提升，可用性提高。缺点是复制会加大服务器的性能开销。
扩展：扩展容量，数据库分片分表，性能和并发量提升。缺点是降低可用性。
切换：主从库提高高可用，主从身份切换，并发量提升。缺点是丢失切换时刻的数据。
这三点对应CAP的理论，CAP中最多只能满足CP或者AP，CAP的理论知识这里略过，结合上面三点可以简单梳理。
三高实现本质：
三高的本质其实就是如何结合复制、扩展、切换三个方法实现三高，我们需要思考下面的三个问题：
- 如何将数据进行冗余？
- 如何有效扩展容量，提高并发性能？
- 如何做主从备份切换，提高高可用？
针对上面三个问题在回到开头提到的三高最终Mysql的三高总结来说就是下面三点：
高并发：复制和拓展，分散多节点
高性能：复制提升速度，拓展容量
高可用：节点之间切换。
复制
复制是Mysql中实现高可用的重要功能，复制类型分为三种：异步复制和半同步复制，组复制的模式以及新版本带来的GTID复制增强模式。
- 异步复制
- 半同步复制
- 组复制（mysql5.7新特性）
- GTID 复制模式（Mysql5.6.5之后新增）（减少复制故障）
复制原理
异步复制
异步复制是非常传统的Mysql复制方式也是实现方式最为简单的一种，异步复制和其名字的意义一样主库在写入binlog之后通知从库数据已经发送然后自己干自己的事情去了，此时从库会主动发起IO请求建立和主库的连接，接着是binlog拷贝到本地写入到relay log中进行重放日志最终sql线程重放然后在最后达到数据一致的效果。
基本的处理步骤如下：
- 主节点执行备份线程，读取binlog文件并且发送给从库。
- 从库的io线程和主库建立连接，使用二进制转储线程读取到binlog文件，如果数据是同步的则睡眠等待主库发送同步信号，否则获取数据把binlog文件保存为relay log，注意从库不会立马执行主库发来的sql，而是会放入到redo log中。
- 从库会通过sql线程定时读取最新的relay log文件，对于relay log重放，重放之后自己再记录一次binlog日志。（自己再记录一次主要是因为从库本身也有可能是其他子从库的主库，整个过程按照相同的步骤处理）
异步复制的问题：
- 读取binlog文件的时候主节点的状态？是否需要锁表？
主节点此时依然可以正常执行，不需要锁表，因为操作的是二进制的binlog文件。- 重放relay log是啥意思？
relay log：中继日志，relay
relay：中继。
重放：重新播放可以认为是重读- 从库复制涉及多少线程
两个，一个IO线程一个SQL线程，IO线程负责从主库获取binlog文件，SQL负责将中继日志进行重放。- 为什么从库最后还需要记录一次binlog？
因为从库也有可能存在自己的子节点，所以也需要按照同样的步骤复制给自己的子节点。- 为什么需要relay log中继日志？
如果备库直接连接主库进行拷贝并且直接执行可能会存在问题，如果此时主库频繁的往binlog塞日志，那么很容易出现主库和备库之间长时间连接并且备库无法正常工作。
异步复制流程图：根据流程图可以看到，在主库执行完sql之后会记录binlog文件并且commit事务，通过异步的方式把binlog发给其他分片上的从库，从库会根据主库的binlog重放relay log之后最终记录到binlog，然后和主库一样完成提交的动作保证数据同步。
问题： 如果主库写入binlog但是此时突然断电，但是Binlog已经发送给从节点，此时会出现什么情况？ 没有影响，因为记录binlog意味着已经完成了事务的操作，即时断电主库也可以通过redo log和bin log恢复数据，由于事务已经提交了，发送给从库出现新增数据也是正常的。
异步复制有下面的特点：
- 对于网络延迟具有一定要求
- 实现方式和原理简单。
- 不能保证日志被送到备库可能会出现日志丢失。
通过上面的特点介绍，可以发现异步复制的最大问题就在于异步两个字，由于网络环境的复杂性主库和备库之间是互相分离的，为了确保数据确实送到了从库，Mysql在此基础上改进复制的流程，后面提到的半同步复制其实就在提交之前进行一次“确认”的操作。
半同步复制：
如上面所说的，半同步复制其实就在主库发送binlog文件之后没有立马提交事务，而是等待所有的从库接收到了binlog并且写入到relay log之后才进行事务提交，注意这里并不是等所有的从库提交再提交，而是确认接受到binlog转为relay log之后立马就进行提交。
半同步的复制是延迟了主库一定的提交时间，确保主备数据同步。
问题 ：
半同步复制时间等待过久怎么办？
rpl_semi_sync_master_timeout参数可以配置脱扣时间，脱扣时间是主备库之间的同步过了多少时间超时。
组复制（Mysql Group Replication）
组复制是MySQL5.7版本出现的新特性，组复制的核心是确保数据的强一致性，缺点也很明显会导致数据库系统的响应速度受到影响。
介绍：复制组由多个MySQL Server组成，组中的每个成员可以在任何时候独立执行事务，他们内部使用十分复杂的共识算法进行识别
（核心团体通信系统（GCS）协议），组复制的特点是在复制的时候需要保持强一致性，如下面的图构造显示，和上面提到了复制方式不
同，在组复制的模式下所有的节点是近似平级关系，通过广播的形式通知改动，当主节点发生binlog变动的时候，需要让其他的同级节点
收到通知验证之后才能进行事务的提交。
读者可能会误解组复制让Mysql实现集群了，然而只是有其行没有其本质组复制只不过是用了些新的对概念包装了一些旧东西罢了，可
以看到组复制的最大痛点在于强一致性的等待时间，看起来很美好，数据似乎永远都不会出现故障绝对能保持一致，实际上这个组复制的
等待时间在很多高并发的系统是没法接受的。
组复制的概念出现于比较新的Mysql版本并且在Mysql8.0中被最终完善，这里找了两篇文章供大家拓展阅读：
- MySQL 5.7 基于组复制(MySQL Group Replication) - 运维小结 - 散尽浮华 - 博客园 (cnblogs.com)
- 官方用了一个大节专门吹组复制：MySQL :: MySQL 8.0 Reference Manual :: 18 Group Replication
主从复制实战
这里仅仅记录操作，建议读者根据自己的版本进行实验，注意下面的实验在默认的情况下是异步复制：
- 为了模拟复制可以先弄两台linux虚拟机，比如现代144和146两台服务器，安装了同样为5.7版本的Mysql，这个实验中144为主库，146位从库。
- 两个实验数据库的数据库内容如下：
- 两个服务器都需要修改配置ini文件并且开放binlog，图中为部分配置：
systemctl restart mysqld重启主库的服务器，此时可以通过命令show master status和show slave status来判断是否构成主备架构。- Mysql命令连接主库同时执行
flush tables with read lock加上全局锁来进行第一次主备数据全量同步，此时可以使用show master status查看当前binlog的写入的位置，使用mysqldump命令进行全量备份。
全量备份的使用可以阅读："三高"Mysql - Mysql备份概览中关于Mysqldump复制这一部分的内容。
- 把备份文件到从库上执行
source xxx.sql实现主备数据之间的同步，注意此时从库需要和主库一样需要将binlog的日志的写入位置进行同步，而binlog文件的写入位置通过主库的show master status进行查看，比如这里从库就需要同步到主库的.000012的194位置。
- **关键步骤：**从库如果是slave状态需要通过命令
stop slave停止slave主库，并且执行reset slave重置状态，为了和主库保持同步，需要通过下面的命令同步binlog的写入位置，完成之后通过show slave status检查两边是否同步：
- 最后检查是否正常主备复制同步：
至此，异步主从复制的实战流程结束，如果我们想要实验半同步复制，需要在my.ini中配置半同步的插件 ，因为半同步复制并不是原生支持的，需要额外的插件支持。
最后通过show variances like 'rpl_semi_sync_master_timeout'可以查看脱扣时间， 通过show processlist命令可以查看主节点的当前线程情况。
主节点有下面的线程，可以看到有一个等待Binlog 写入的线程，这是从库等待主库改动binlog的一个线程任务
从节点有两个线程，也可以通过show processlist方法查看IO现场和重放relay log的两个线程。
