从MySQL看主从架构高可用性实现( 二 ) _架构

master上解析binglog日志：
mysqlbinlog -v --base64-output=decode-rows --start-position=exec_master_log_pos relay_master_log_file如果发现卡在操作某表上：
1））检查表结构

没有索引：stop slave 可能会卡主，建议关闭mysql ，启动后先加索引，然后start slave
有索引：只能等，大事务需要做拆分，不要操作太多数据

2））大事务：M上session回话使用statement格式，使用语句级别的复制
3）查看MySQL状态

机器性能（CPU、IO等）：从库配置适当高一点，使用新硬件PCI-E或SSD设备
表结构: 设计要合理，必须有主键，主键要短小，为查询字段建索引
业务程序：适当使用缓存，减少数据库压力

分析MySQL进程并结合源码：
perf top `pidof mysqld`4）参数临时优化

主库开启group commit
从库开启writeset
从库设置sync_binlog=0 && innodb_flush_log_at_trx_commit=2

5）检查锁情况
show engine innodb statusG;2 主备切换策略2.1 可靠性优先策略在双M结构下，主备切换的流程如图：

文章插图
图片

判断备库 B 现在的 seconds_behind_master（SBM），如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；这里主从延迟时间短，说明当前没有大事务，延迟比较低，减少因为延迟造成数据不可靠的几率；
把主库 A 改成只读状态，即把 readonly 设置为 true；
判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
把业务请求切到备库 B 。

这个切换流程，一般是由专门的 HA 系统来完成的，我们暂时称之为可靠性优先流程。

文章插图
图片
这个切换流程中是有不可用时间的。因为在步骤 2 之后，主库 A 和备库 B 都处于 readonly 状态，也就是说这时系统处于不可写状态，直到步骤 5 完成后才能恢复。
在这个不可用状态中，比较耗费时间的是步骤 3，可能需要耗费好几秒的时间。这也是为什么需要在步骤 1 先做判断，确保 seconds_behind_master 的值足够小。
2.2 可用性优先策略如果是直接将第4和第5步提前，保证了系统几乎么有不可用时间，但是可能造成数据不一致。
其实这就是CAP中的C和A，MySQL主库在写完binlog后就给客户端响应了，没等binlog同步到一个或多个备库，这种策略是在C和A之间选择了A，牺牲了C，如果主库宕机了，但binlog的最后一个或几个事务没同步到备库，那备库成为主库后，数据就丢了。其它的NoSQL很多是给用户提供了选择，比如Mongo，用户可以设置日志同步到几个Slave后再给客户端响应，同步的Slave越多，C越强，A越弱，比如同步到X个Slave后再给客户端响应，那即使任何X个节点宕机，集群中仍然有1个节点有最新日志，它会成为主节点，数据没丢，集群还可以工作。
在满足数据可靠性的前提下，MySQL 高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高。
2.3 常见切换技术semi-sync在网络故障超时的情况下会退化成async，这个时候如果刚好主库掉电了，有些binlog还没有传给从库，从库无法判断数据跟主库是否一致，如果强行切换可能会导致丢数据，在金融业务场景下只能＂人工智能＂来做切换，服务中断时间长。AliSQL采用双通道复制更容易判断主备数据是否一致，如果一致可以自动切换，如果不一致才需要人工恢复数据。

【从MySQL看主从架构高可用性实现】