微信公众：云计算常见课堂教学
持续出口技术干货，敬请关注！
本文介绍了MySQL主从副本的背景
MySQL主从复制概述
拓扑复制
原理
类型
显示待机状态
01背景
部署主从式复制是基于实际业务需求的。
1、某个SQL语句需要表锁定，系统一时不能提供读取服务，可能会影响正在运行的业务。 使用主从副本，写入主库，让其负责从库中读取，即使在主库中出现锁定表的情况，读取也能保证业务从库中正常动作。
2、可以从库中创建数据热备盘
3、由于体系结构的扩展，业务量越来越大，I/O访问频率太高，单机无法满足。 这种情况下，大多从库中保存，能够提高各个机器的I/O性能。
02概要
复制是指通过二进制日志将主数据库的DDL和DML操作传递到复制服务器(也称为从库)，然后在从库中重新运行这些日志(也称为重做)
MySQL支持从一个主库同时复制到多个从库，从库还可以同时作为其他服务器的主库实现链式复制。
好处：
1、主库出现问题时，可快速切换至由库提供服务；
2、可以在从库中执行查询操作，降低对主库的访问压力；
3 .为了在备份过程中不影响主库的服务，可以在从库中执行备份。
注意：
MySQL实现了异步复制，主从设备之间存在一定的差异。 来自库的查询操作必须考虑这些数据之间的差异。 通常，只能从库中查询不经常更新或不要求实时性的数据。 要求实时性的数据仍然需要从主数据库中检索。
缺点：
主从式复制还会成为性能瓶颈。
1、写操作无法扩展
2、写操作无法缓存
3、复制延迟
4、链表率提高；
5、表变大，现金流量下降。
03复制拓扑
复制具有多个拓扑结构。 一个主库多库、主-主复制、环形复制、树或金字塔类型等等。 常见的三种类型：一个主复制体系结构、多级别复制体系结构和两个主复制/双主体系结构。
3.1一主多从复制体系结构
在主库的读取请求的负荷高的情况下，通过配置从复制体系结构进行读取和写入分离的主库，主库主要负责写入请求的处理，特别是不要求实时性的大量读取请求由于负荷分散
如果主库发生异常停机，可以将一个从库切换为主库，继续提供服务。
3.2多级别复制体系结构
一主多从体系结构可以解决大部分读请求压力特别大的情况下的需求，但MySQL复制将主库“推送”Binlog日志到从库，因此主库的I//引入多级复制体系结构，以解决主库的IO和网络压力问题。
多级复制体系结构在从主库master1到子库slave1、slave2和slave3的复制过程中添加了第二级主库master2。 主库只需要将binlog日志“推送”到一个子库master2，从而减轻主库master1的压力(辅助主库master2从库sllog日志)
多级复制体系结构是异步复制，在多级复制场景中，主库中的数据经过两次复制到达从库，在一个复制场景中只复制一次
3.3双主复制/双主复制
双主/双主体系结构特别适合需要切换主从的场景，如DBA维护。 双主/双主体系结构避免了重建从库的麻烦。
04原理
MySQL复制的原理如下：
1、首先，MySQL主库在提交事务时将数据更改作为事件事件事件记录在二进制日志文件binlog中，MySQL主库中的sync_binlog参数是binlog日志的解码
2、主库将二进制日志文件binlog中的事件推送到库的中继日志Relay Log中，然后根据中继日志Relay Log重新进行数据变更操作，通过逻辑复制的方式进行主库
4.1流程
MySQL通过三个线程在主从库之间复制数据。 其中，Binlog Dump线程是主库，I/O线程和SQL线程在从库中运行。
从库启动“复制”(START SLAVE )时，I/O线程首先连接到主库，主库创建Binlog Dump线程以读取数据库事件并将其发送到I/O线程I/O线程获取事件数据后，从库的中继日志Relay Log更新，从库上的SQL线程更新到从中继日志Relay Log更新的数据库
注意：中继日志文件Relay Log的文件格式、内容与二进制日志文件binlog相同，唯一的区别是，在库中的SQL线程执行当前中继日志文件Relay Log中的事件后，SQL线程自动显示当前
。4.2 复制方式
1、异步复制
MySQL默认的复制是异步复制。
主库在执行完客户端提交的事务后会立即将结果返回客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，如果主库崩溃，主库已经提交的事务可能并没有传到从库，如果强行将从库提升为主库，可能导致新主上的数据不完整。
2、同步复制
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
3、半同步复制
MySQL支持半同步复制。
在MySQL5.5之前，MySQL的复制是异步操作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患：当在主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库磁盘损坏、内存故障等造成主库上该事务binlog丢失，此时从库可能损失这个事务，从而造成数据不一致。
为了解决这个问题，MySQL5.5引入了半同步复制机制。在MySQL5.5之前的异步复制时，主库执行完commit提交操作后，在主库写入binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库。而半同步复制时，为了保证主库上的每一个binlog事务都能够被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到binlog事务并成功写入到中继日志后，主库才返回commit操作成功给客户端。半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的binlog日志上，一份在至少一个从库的中继日志Relay Log上，从而更进一步保证了数据的完整性。
半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT(Round-Trip Time)越小决定了从库的实时性越好。通俗地说，主从库之间网络越快，从库越实时。
05 类型
5.1 基于binlog二进制日志的复制
master用户写入数据，生成event记到binary log中。slave接收master上传来的binlog，然后按顺序应用，重现master上的操作。
可以通过show variables查看binlog格式，binlog支持statement、row、mixed三种格式，也对应了MySQL的三种复制技术。
二进制日志文件binlog的格式有以下3种：
Statement：基于SQL语句级别的binlog，每条修改数据的SQL都会保存在binlog中，存储日志量是最小的。
Row：基于行级别，记录每一行数据的变化，也就是将每行数据的变化都记录到binlog中，记录得非常仔细，但并不记录原始SQL，存储event数据，存储日志量大，但是不能很直接的进行读取；在复制的时候，并不会因为存储过程或触发器造成主从库数据不一致的问题，但是记录的日志量较statement格式要大得多。
Mixed：混合statement和row模式，默认情况下采用statement模式记录，某些情况下会切换到row模式。如果每天数据操作量很大，产生的日志比较多，可以考虑选择使用mixed格式。
注：Row格式比Statement格式更能保证从库数据的一致性(复制的是记录，而不是单纯操作SQL)。当然，Row格式下的Binlog的日志量很可能会增大非常多，在设置时需要考虑磁盘空间问题。
5.2 使用GTID完成基于事务的复制
主从切换后，在传统方式里，需要找到binlog和POS点，然后执行change master to指向新的主库。对于不是很有经验的运维人员来说，往往会找错，造成主从同步复制报错，在MySQL5.6版本里，无须再找binlog和POS点，只需要知道master的IP、端口、账号和密码即可，因为同步复制是自动的，MySQL会通过内部机制GTID(Global Transaction ID)自动找点同步。
工作原理：
1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中；
2、slave端的i/o线程将变更的binlog，写入到本地的relay log中；
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录；
4、如果有记录，说明该GTID的事务已经执行，slave会忽略；
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog；
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
优点：
1、一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次；
2、GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置；
3、减少手工干预和降低服务故障时间，当主机挂了之后通过软件从众多的备机中提升一台备机为主机。
缺点：
1、不支持非事务引擎；
2、不支持create table ... select 语句复制；
3、不允许一个SQL同时更新一个事务引擎表和非事务引擎表；
4、在一个复制组中，必须要求统一开启GTID或者是关闭GTID；
5、开启GTID后，就不再使用原来的传统复制方式；
6、对于create temporary table 和 drop temporary table语句不支持；
7、不支持sql_slave_skip_counter。
06 备机状态
当主从复制正在进行中时，如果想查看从库两个线程运行状态，可以通过执行在从库里执行”show slave statusG”语句，可以通过输出信息获取备机状态信息：
Master_Log_File：上一个从主库拷贝过来的binlog文件
Read_Master_Log_Pos：主库binlog文件被拷贝到从库的relaylog中的位置
Relay_Master_Log_File：SQL线程当前处理中的relaylog文件
Exec_Master_Log_Pos：当前binlog文件正在被执行的语句的位置