MySQL 主从复制是面试中不可避开的重要一环，里面的知识点虽然基础，但是能回答全的同学不多，今天我们再来老生常谈一下。
本文全文内容如下。
1. MySQL 主从
1.1 什么是 MySQL 主从 ?
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。
1.2 为什么使用 MySQL 主从 ?
MySQL主从复制架构是MySQL集群中最基本也是最常用的一种架构部署，能够满足很多业务需求。大约有以下使用场景
1、数据备份：数据存在多个镜像和数据冗余，可以防止单一主机的数据丢失，提高数据的安全性。另外在从服务器上做数据备份，这样不影响主服务器的正常运行。
2、高可用：主机宕机的时候，可以切换到从服务器上，注意数据的一致性（默认异步复制）。
3、读写分离：在业务上可以实现读写分离。即可以把一些读操作在从服务器上执行，减小主服务器的负担。例如在从服务器上做数据报表和数据统计，这样可以避免生产服务器的访问压力过大。
2. 主从复制
2.1 主从复制原理
说到主从复制，离不开binlog这个东西，先从binlog说起。
binlog是一个二进制文件，主要记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的所有操作。
binlog 是 mysql 的逻辑日志，并且由 Server层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。
在实际应用中， binlog 的主要使用场景有四个：
- 恢复（recovery）：某些数据的恢复需要二进制日志。例如，在一个数据库全备文件恢复后，用户可以通过二进制日志进行point-in-time的恢复。
- 复制（replication）：其原理与恢复类似，通过复制和执行二进制日志使一台远程的MySQL数据库（一般称为slave或者standby）与一台MySQL数据库（一般称为master或者primary）进行实时同步。
- 审计（audit）：用户可以通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻击。
- 用于数据备份，在数据库备份文件生成后，binlog保存了数据库备份后的详细信息，以便下一次备份能从备份点开始。
❝备注：除了上面介绍的几个作用外，binlog对于事务存储引擎的崩溃恢复也有非常重要的作用。在开启binlog的情况下，为了保证binlog与redo的一致性，MySQL将采用事务的两阶段提交协议。
MySQL系统发生崩溃时，事务在存储引擎内部的状态可能为prepared和commit两种。
对于prepared状态的事务，是进行提交操作还是进行回滚操作，这时需要参考binlog：如果事务在binlog中存在，那么将其提交；如果不在binlog中存在，那么将其回滚，这样就保证了数据在主库和从库之间的一致性。
复制基本过程（面试常考）：
- 主库写入数据并且生成binlog文件。该过程中MySQL将事务串行的写入二进制日志，依赖binlog dump线程。
- 在事件写入二进制日志完成后，master通知存储引擎提交事务。
- 从库服务器上的IO线程连接Master服务器，请求从执行binlog日志文件中的指定位置开始读取binlog至从库。
- 主库接收到从库的IO线程请求后，其上复制的IO线程会根据Slave的请求信息分批读取binlog文件然后返回给从库的IO线程。
- Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容。
- 从库服务器的SQL线程会实时监测到本地Relay Log中新增了日志内容，然后把RelayLog中的日志翻译成SQL并且按照顺序执行SQL来更新从库的数据。
- 从库在relay-log.info中记录当前应用中继日志的文件名和位置点以便下一次数据复制。
3. 主从延迟
3.1 主从延迟是怎么回事？
根据前面主从复制的原理可以看出，两者之间是存在一定时间的数据不一致，也就是所谓的主从延迟。
我们来看下导致主从延迟的时间点：
- 主库 A 执行完成一个事务，写入 binlog，该时刻记为T1.
- 传给从库B，从库接受完这个binlog的时刻记为T2.
- 从库B执行完这个事务，该时刻记为T3.
那么所谓主从延迟，就是同一个事务，从库执行完成的时间和主库执行完成的时间之间的差值，即T3-T1。
我们也可以通过在从库执行show slave status，返回结果会显示seconds_behind_master，表示当前从库延迟了多少秒。
seconds_behind_master如何计算的？
- 每一个事务的binlog都有一个时间字段，用于记录主库上写入的时间
- 从库取出当前正在执行的事务的时间字段，跟当前系统的时间进行相减，得到的就是seconds_behind_master，也就是前面所描述的T3-T1。
3.2 主从延迟情况一览
- 从库机器性能：从库机器比主库的机器性能差，只需选择主从库一样规格的机器就好。
- 从库压力大：可以搞了一主多从的架构，还可以把 binlog 接入到 Hadoop 这类系统，让它们提供查询的能力。
- 从库过多：要避免复制的从节点数量过多，从库数据一般以3-5个为宜。
- 大事务：如果一个事务执行就要 10 分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟 10 分钟啦。日常开发中，不要一次性 delete 太多 SQL，需要分批进行，另外大表的 DDL 语句，也会导致大事务。
- 网络延迟：优化网络，比如带宽 20M 升级到 100M。
- MySQL 版本低：低版本的 MySQL 只支持单线程复制，如果主库并发高，来不及传送到从库，就会导致延迟，可以换用更高版本的 MySQL，支持多线程复制。
3.3 怎么减少主从延迟
主从同步问题永远都是一致性和性能的权衡，得看实际的应用场景，若想要减少主从延迟的时间，可以采取下面的办法：
- 降低多线程大事务并发的概率，优化业务逻辑
- 优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成。
- 提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。
- 尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。
- 实时性要求的业务读强制走主库，从库只做灾备，备份。
4. 主从切换
4.1 一主一从
两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。
- 优点：从库支持读，分担了主库的压力，提升了并发度，且一个机器故障了可以自动切换，操作比较简单，公司从库还可以充当数据备份的角色；
- 缺点：一台从库，并发支持还是不够，并且一共两台机器，还是存在同时故障的机率，不够高可用。
4.2 一主多从
在生产环境中，为了满足安全性，高可用性以及高并发等方面的需求，基本上采用的MySQL数据库架构都是MHA、MGR等，搭配自动切换脚本，实现故障自动切换。一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。如果 A 库发生故障，B 库成为主库负责读写，C、D 负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。
- 优点：多个从库支持读，分担了主库的压力，明显提升了读的并发度。
- 缺点：只有一台主机写，因此写的并发度不高。