共计 644 个字符,预计需要花费 2 分钟才能阅读完成。
上一篇文章介绍了 MySQL 主从同步的原理和利用,本文总结了 MySQL 主从提早的起因和解决办法。如果主从提早过大,会影响到业务,该当采纳适合的解决方案。
MySQL 主从提早的体现
先 insert 或 update 写入更新操作,再立刻 select 查问,然而得不到最新的后果。
可通过 show slave status 命令,后果中的 Seconds_Behind_Master 列,查看主从提早的秒数。
MySQL 主从提早的起因
- 读写拆散时,写操作走主库,读操作走从库,然而主库的变更还未同步至从库
- 网络传输提早:从库发动 dump 申请,主库推送 binlog 文件,从库写入本地 relay log
- 从库串行执行 sql 语句:主库并发的事务提交,然而在从库上只能串行执行,速度比主库慢
MySQL 主从提早解决办法
业务优化
如果业务场景容许,先写入更新操作,期待一小段时间后再查问。比方,新增一条记录,前端成心提早半秒再调后端接口查问。
技术优化
- 拆库 + 并行复制:MySQL 反对库级别的并行复制,拆库后每个分库的数据质变小,主从提早天然也变小了。
慢 sql 优化除慢 sql,也能升高主从提早
终结计划
以上方法治标不治本,只能起到缓解主从提早的作用,彻底根治还需这么做。
- 显式查主库:不同的分片中间件做法不一样,client 侧分片可在每次查问前设置查主库的标记(ThreadLocal 变量),proxy 侧分片开启事务
长处:实现简略,毛病:受 MySQL QPS 限度,QPS 极高时不举荐 - 双写数据库和缓存,查缓存:防止 MySQL 主从提早
长处:可撑持高并发场景
正文完