MySQL的主从高可用容灾 *

MySQL主从复制原理 #

master-slave MySQL主从复制

MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

MySQL主备切换流程因为readonly设置对超级(super)权限用户是无效的，而用于同步更新的线程，就拥有超级权限。

主备流程图

在备库B上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。
在备库B上执行start slave命令，这时候备库会启动两个线程，就是图中的io_thread和 sql_thread。其中io_thread负责与主库建立连接。
主库A校验完用户名、密码后，开始按照备库B传过来的位置，从本地读取binlog，发给B。
备库B拿到binlog后，写到本地文件，称为中转日志（relay log）。
sql_thread读取中转日志，解析出日志里的命令，并执行。

主备延迟原因
- 备库所在机器的性能要比主库所在的机器性能差
- 备库的压力大 解决方案: I. 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。 II. 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
- 大事务 解决方案: I. 不要一次性地用delete语句删除太多数据 II. 大表DDL场景, 处理方案就是，计划内的DDL，建议使用gh-ost方案.
- 备库的并行复制能力 [3]

由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。

可靠性优先主备切换流程

可靠性优先策略，主库不可用

小结：实际的应用中，我更建议使用可靠性优先的策略。在满足数据可靠性的前提下，MySQL高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高。

早期，不建议使用

{% post_link ‘mysqlLog’ %}