当前位置: 首页 > news >正文

MySQL 优化从库延迟的一些思路

作者:孙绪宗,新浪微博 DBA 团队工程师,主要负责 MySQL、PostgreSQL 等关系型数据库运维。

爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

本文约 1000 字,预计阅读需要 3 分钟。

引言

在数据库运维过程中,无论是迁移扩容还是生产投量,都必不可少的会遇到从库迁移追不上的问题。这些问题令人头疼。

以下列举几个我个人遇到过的原因:

  • buffer_pool设置过大,导致 MySQL 使用 SWAP
  • 备份导致 SQL_THREAD 回放等待 MDL
  • 大事务
  • 慢查询导致从库性能低下
  • 并行复制导致从库延迟监控一直为 1s
  • 网络问题

具体情况具体分析,这里不赘述。

如果你在常规排查之后,依然无法解决。接下来,我将根据自身的一些经验,提供一些参数调整思路,供大家参考。

思路一:sync 相关

我们在追延迟的情况,可以调整一下参数,增加日志落盘效率。后续上线从库可以再设置回来。

sync_binlog=0 sync_master_info=10000 #default sync_relay_log=10000 #default sync_relay_log_info=10000 #default

思路二:buffer 和并发等相关

可以考虑增加一下buffer_pool,SQL_THREAD 回放执行的更快。

如果内存空间不足的话,可以适当调整change buffer的比例(前提是无读,正常情况下延迟库均为无业务连接)。

innodb_buffer_pool_size=24G #24*1024*1024*1024 innodb_change_buffer_max_size=50 innodb_thread_concurrency=0 innodb_adaptive_hash_index=0

增大innodb_buffer_pool_size风险点:

  1. 内存过度分配导致 SWAP 触发或 OOM,需预留足够内存给系统和 MySQL 其他组件,建议缓冲池不超过物理内存的 70%;
  2. 调整需分步进行,结合系统内存监控,避免一次性设置过大。

思路三:slave 相关

考虑开启并行复制

开启并行复制,8.0+ 版本考虑用 writeset。复制线程可以多观察一下,如果没够的话,可以考虑增加。但不建议超过 CPU 核心数或者innodb_thread_concurrency参数值。

slave_preserve_commit_order会加一层锁,追延迟的时候建议关闭,后续上线从库可以再打开。

slave_parallel_type=LOGICAL_CLOCK slave_parallel_workers=16 slave_preserve_commit_order=OFF

个人不建议修改以下参数,性能虽然会有所增长,但同时会导致主库commit等待。当然部分非实时类业务可以调整。

binlog 的组提交的两个有关参数:

  • binlog_group_commit_sync_delay参数,表示延迟多少微秒后才调用 fsync 刷盘;
  • binlog_group_commit_sync_no_delay_count参数,表示累积多少次以后才调用 fsync。

考虑关闭 log_slave_updates

log_slave_updates这个需要重启生效。但是有 gdb 经验的小伙伴可以 gdb 修改,不需要重启,只需要重启 slave 复制即可生效。无 gdb 经验可能会导致 crash 不建议。

同时注意需要了解架构,没有 binlog 备份或者级联库,且无业务连接,建议可以关闭。

思路四

MGR 架构可以考虑先改为异步复制,关闭slave_preserve_commit_order,待延迟追完后再加入到集群。

思路五

其他性能参数按照模板理论上不会有太大问题,这套操作下来延迟大概率会有所下降,降为 0 只是时间问题。

附录

并行复制积压日志解析:

2021-01-10T16:08:39.947611+08:00 85441 [Note] Multi-threaded slave statistics for channel '';seconds elapsed = 120;events assigned = 4005889;worker queues filled over overrun level = 0;waited due a Worker queue full = 0;waited due the total size = 0;waited at clock conflicts = 6918018179200 waited (count) when Workers occupied = 0 waited when Workers occupied = 0 -------------------------------- Multi-threaded slave statistics for channel ”: seconds elapsed = 120; 每隔120s输出 eventsassigned = 4005889; 总共有多少个event被分配执行 queues filled over overrun level = 0; 多线程同步中,worker 的私有队列长度超长的次数 waited due aWorker queue full = 0; 因为worker的队列超长而产生等待的次数 waited due the total size = 0; 超过最大size的次数 waited at clock conflicts= 6918018179200;因为逻辑时间产生冲突的等待时间,单位是纳秒 waited (count) when Workers occupied = 0 因为workder被占用而出现等待的次数。(总计值) waited when Workers occupied = 0 因为workder被占用而出现等待的总时间,总计值,单位是纳秒
http://www.jsqmd.com/news/216118/

相关文章:

  • 文件的逻辑块按顺序存放在磁盘的连续物理块中,支持高效的顺序和随机访问
  • 中小企业降本妙招:M2FP CPU版镜像免费部署,省去GPU成本
  • 发电机的“赛博感官”:在线监测如何预知核电的每一次心跳
  • Meta广告过审难?掌握这些技巧,让过审率提升至 95%
  • M2FP在游戏开发中的角色动画应用
  • 客服工单自动翻译:提升跨国企业响应速度实战
  • 路径完整地描述了从根目录到目标文件的路径,符合 MS-DOS 的命名规范
  • langchain代理调用本地模型:摆脱对云服务的依赖
  • 云启数智一站式元宇宙综合解决方案
  • 从选型到落地:脉冲输出模块在工业自动化中的全场景应用
  • 收藏!Meta超级智能实验室首篇论文:彻底重构RAG,效率飙升30倍
  • JY-DAM-DI08-AC8路交流状态采集模块
  • 亲测!专业模拟面试公司效果超棒
  • 如何验证翻译质量?CSANMT提供可读性评估参考
  • 文件的逻辑结构指文件在用户视角下的组织形式
  • 无需深度学习背景:普通开发者也能驾驭的大模型应用
  • M2FP模型在游戏开发中的角色生成技术
  • 包装机械智能改造:8路脉冲输出模块的实战落地
  • 基于单片机的智能小车设计
  • Docker镜像大小优化:仅1.2GB,传输部署更快速
  • 西门子1200 PLC与威伦触摸屏三轴单平台螺丝机程序详解:博图V15软件下的电机轴定位运动控...
  • 美国 FCC 认证的材料要求与有效期
  • 欧盟 CE 认证的材料要求与有效期
  • remix框架和next.js框架有什么不同?
  • M2FP+Flask:快速搭建人体解析API服务
  • 8个降AI率工具推荐!本科生高效降AIGC神器合集
  • 从零开始:使用M2FP构建人体解析WebUI全流程
  • 亲测!专业模拟面试公司实践效果
  • BQB 蓝牙资格认证的材料分类和有效期核
  • 2026年营销全案咨询公司权威推荐:专业方案与高效执行口碑