Mysql基础课十二：高可用部署

一主一备

1. 一主一备：读写都在主库，备库只同步数据，保持和主库一致，建议将备库设置为 readonly，备库是通过获取主库的 bin log 来同步数据的；

2. bin log 有两种格式，一种是 statement，表示 bin log 记录 SQL 语句的原文，另一种是 row，记录 SQL 语句在哪个库操作了哪一行；

	// 注意 statement 可能会有主从库执行不一致的现象，如果主从库使用不同的索引扫描，可能导致删除数据不一致
	delete from t where a>=4 and t_modified<='2018-11-10' limit 1

3. 大多数设置 bin log 为 row 格式，不仅可以解决主从库执行不一致的问题，还对于恢复数据十分友好，因为 row 格式会记录对磁盘数据页每一条记录的操作，而 statement 只是记录 SQL 语句；

双 M 结构

1. 双 M 结构，即数据库节点互为主备关系，这样主备切换时，不用再修改主备关系，是生产比较常用的方式，但要避免出现循环复制，节点 A 将其 bin log 同步到节点 B，节点 B 执行后又生成自己的 bin log，又同步到节点 A，导致如此循环；

2. 循环赋值的解决办法是，规定主备节点的 server_id 必须不同，通过 bin log 中的 server id，每个节点收到同步的 bin log后，先判断 server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃；

3. 主备同步的操作流程图：
   

主备延迟

1. 主备切换时，主备延迟是一个非常重要的问题，如果延迟大，切换后从备库读到的数据就会出现不一致；

2. 主备延迟时间，是将备库执行完主库同步的 bin log 的时刻，减去主库写入 bin log 的时刻，造成延迟的原因有：网络通信，备库性能，备库执行运营分析，大事务等原因；

	执行 show slave status 命令，返回结果 seconds_behind_master 记录了延迟时间

3. 主备切换后，如果要等到主备延迟为 0，才切换请求到备库，这就是可靠性优先的原则，中间可能出现一定的不可用时间，如果不需要等到主备延迟为 0，先切换请求，就是可用性优先原则，可能出现数据不一致的现象，需要事后补数据，不推荐使用；

4. 可靠性优先，首先判断备库 B 的 seconds_behind_master，如果小于某个值，比如 5 秒，就继续下一步，否则持续重试直到小于该值；第二步，把主库 A 改成只读状态，判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；最后，把备库 B 改成可读写状态，把业务请求切到备库 B；

5. 可用性优先，就是首先将备库 B 改为可读写状态，并切换业务请求到备库 B，然后将主库A 改为只读状态；

6. 所以，生产中要时刻监视主备延迟，出现延迟超过阈值，要及时处理，防止异常场景下，主备切换需要时间过长；

一主多从

1. 为了扩展 Mysql 的读性能，往往采用一主多从，读写分离的部署方案，主库提供读写功能，从库提供读功能，需要关注这类方案带来的 过期读 和 主备切换 的问题；

2. 图中 A 和 A’ 互为主备关系，B，C，D 为节点 A 的从节点；
   

读写分离

1. 读写分离，通常由两种部署方案，一种是，客户端主动做负载均衡，由客户端来选择具体的数据库节点进行查询，另一种是，引入代理层 Proxy，代理层根据请求类型和上下文来决定请求的分发，这种方案更复杂，但对客户端更友好；

2. 过期读，即因为主从延迟，可能出现从库读到的数据过期，常用的解决方案有：强制走主库，等主库位点和等 GTID 等等；

3. 强制走主库，是指将请求进行分类，对于不允许过期读的场景，将请求发至主库，而对于可以接受读到旧数据的场景，将请求发至从库；

4. 等主库位点方案和等GTID方案，都是在发往从库进行查询前，对从库是否在该事务上存在主从延迟的情况，进行判断，如果无延迟，从库查询返回，如果有延迟，将请求发送到主库查询；这样查询就不会有过期读的现象；

主备切换

1. 如上图，完成业务请求发送 A’，并且 B，C，D 节点复制新的节点 A’，其中 B, C，D 节点改变主节点，需要执行 change master 命令，有 host , port，user，pwd ，master_log_file，master_log_post 参数，最后两个参数，是指要从主库对应的文件名和日志偏移量继续同步 bin log，也被称为同步位点；

2. 所以主备切换时，就涉及找新节点的同步位点，不过这种方式较复杂，且容易出错，Mysql 5.6 版本之后，引入了 GTID，很好的解决了该问题，推荐使用；

3. GTID，即全局事务 ID，是一个事务的唯一标识；使用 GTID 方式做主备切换，就在 change master 命令，加入参数 master_auto_position=1，接下来节点 B 会将自己的 GTID 集合发送给节点 A’，节点 A’ 会比较节点 B 和 自身的 GTID 集合，将不存在节点 B 的 GTID 的对应的 bin log 发送给节点B，开始同步数据；

Mysql 的健康检测

1. HA 系统，需要定时对 Mysql 实例做健康检测，一旦出问题，就会触发主备切换；

2. 健康检测，通常有 外部检测和内部检测，外部检测，通常是通过 select 1，update 语句进行检测，其中 update 语句能够检测出，因并发查询线程过多 和 磁盘占满 导致不可用的场景，而 select 1 操作是不行的；

3. 内部检测，是为了防止外部检测的随机性，通过对 performance_schema 库中的 file_summary_by_event_name 表中的统计信息，进行分析，得出 Mysql 的健康状况；