前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Mysql 高可用与主备数据一致性

Mysql 高可用与主备数据一致性

作者头像
执生
发布2020-12-01 10:45:51
3120
发布2020-12-01 10:45:51
举报
文章被收录于专栏:立权的博客

之前的文章提到过,Mysql 是支持互为主从的,这种结构可以在 某台库宕机后,将客户端的请求转发到 另外一个库 来实现故障迁移的效果。

但是如果直接转移,不等B消费掉 relay log 的话,会发生 数据不一致的现象。

同样举 A,B 两个库。A 充当写库,B充当 从库。

当 A 挂掉的时候,假设 B 已经接收到 A 的所有 binlog (另一种可能的情况是 A 有的 binlog 没发出去,没有被 B 接收到)

一部分 binlog 可能还以 relay log 的形式 存在于 从库,如果不将这部分 消化掉,就可能导致 B 无法承接上 之前 A 的状态,导致数据不一致(如果A没能发出 所有 binlog ,那么注定不一致,但是当前情况是假设都发出了)

从库从 主库取得 binlog 之前会通过 SELECT UNIX_TIMESTAMP() 来校正时间,并且binlog 上的每一条语句都会 记录时间,这样的话,在从库执行完 事务之后会 将当前时间 和 binlog 上的事务的时间相减,得出的差值就是主备延迟,可通过 show slave status 查看 seconds_behind_master 得出

导致 B 久久无法消化完所有 binlog 的原因 可能有:

  1. B库上的 读压力太大,之前B库做为 从库,可能担负了很多的读请求,但是实际上B库还需要写 从 A 上传来的 binlog 的记录,如果 B 之前负责了 大部分读请求,那么之前就会较慢地消耗 传来的binlog。同理,B库的配置差的话,也会有同样的后果。

  2. 主库执行了 长事务,主库的长事务传过来了,从库也要执行,这样的话,从库要长时间执行这个 长事务,那么之后的 binlog 都被堵住了。

  3.另一种情况是 锁的问题,比如虽然 从库上开了 readonly = true,但是其他客户端连接执行一个 begin ; select * from table;

   如果此时恰巧主库发来 针对 t 的ddl,那么超级线程(这个线程相当于一个链接,用来执行 relay log 的内容)将被卡住,直到上述事务完成

   如果上述事务一直不提交,那么将是灾难性的。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2020-11-27 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档