MySQL高可用主从复制原理及常见问题
前言
MySQL高可用的最常见方案就是主从复制,而所有的⾼可 ⽤架构，都直接依赖于binlog,这次我主要分享主备的基本原理,帮助同志们更好的理解高可用的关键
目录
主从复制介绍
主从一致性
主从延迟的常见原因
部署主节点的机器和部署从节点的机器性能差距大
从节点的压力大
数据库中频繁有大的事务操作
解决方案
并行复制加快主从一致性
实时性要求高的查询强制走主库
判断没延迟在进行查询
主从切换
可靠性优先策略
可用性优先策略
总结
判断主库是否出问题
主从复制介绍
主从复制是将一个MySQL主节点的数据自动同步到一个或多个从节点，实现数据冗余、读写分离和负载均衡
主从一致性
MySQL通过binlog日志保证了主从一致性,这里的一致性是最终一致性,因为从主节点到从节点的binlog传递是由延迟的
即使从节点宕机,等它重新启动的时候,binlog日志也会自动补全前面因宕机而没有同步好的数据,所以,只要保证binlog日志不丢失,基本上就是保证了主从的最终一致性
主从延迟的常见原因
部署主节点的机器和部署从节点的机器性能差距大
从节点的压力大
因为一般来说对主节点比较小心,从节点比较随便,最终会导致压力都给了从节点,从节点资源都消耗到业务上面了,影响了同步速度
数据库中频繁有大的事务操作
比如,一个事务执行10分钟,那么MySQL进行主从同步的时候也需要执行10分钟,,这就造成了10分钟延迟
解决方案
并行复制加快主从一致性
除了减缓延迟原因之外,还可以考虑使用并行对从节点进行复制,原则上来说,并行复制只要不是复制的同一张表,基本上是不会又冲突的
实时性要求高的查询强制走主库
对于读写分离架构中,因为读取的都是从节点并且主从可能会出现延迟,所以遇到实时性高的数据读取不准确,此时可以考虑这小部分查询强制走主库来解决实时性要求高的查询
判断没延迟在进行查询
通过判断主从延迟,判断出没有延迟了再进行查询
主从切换
一般来说,,从节点只负责读,主节点可以读写
主从切换常见有两种策略
可靠性优先策略
1、操作主节点和从节点都为只读,就是把主节点的读写,转化为只读
2、判断主从延迟是否结束,即确保同步
3、将从节点改为可以读写
特点: 保证了可靠性,但是会有一段时间用户只能读取数据
可用性优先策略
直接把从节点改成可以读写,直接切库,不管数据的一致性问题,只保证用户可以一直使用
特点: 保证了可用性,但是因主从数据延迟导致数据丢失
总结
实战中建议使用可靠性优先的策略
判断主库是否出问题
主从切换有两种场景，⼀种是主动切换，⼀种是被动切换。⽽其中被动切换，往往是因为主库出问 题了,前面已经介绍了如何切换,接下来我们来搞明白怎么判断主库出问题
判断主库是否出问题需结合多种方法，不能仅依赖SELECT 1这类简单查询，需从进程状态、并发查询、磁盘空间、IO性能、主从状态等多维度综合检测
1、select如果可以执行成功,说明MySQL进程、接口联通性等基础方面正常
2、在mysql库中建立一个简单的表进行定期查询,查看数据库故障 是否因为查询的并行线程达到上线导致的无法执行SQL语句的情况
在mysql库中建立表的原因: 高优先级、资源消耗低、执行快、没有缓存干扰,可以很准确反应问题
如果是因为并发查询线程达到上线导致的数据库无法执行SQL语句出现问题,临时切换主从分担流量可以解决,但是如果需要根治肯定要加服务器配置和增大并发查询线程数量