故障分析 | MySQL 参数设置不当导致复制中断

土匪 2023-07-18 16:44:12  50449

分类专栏：资讯

1前言

在日常的运维工作中，偶尔会遇到一些意想不到的线上问题，多数因为设置不当导致故障。前段时间，DMP 数据库运维平台^[1] 报错主从复制 SQL 线程断开，就是因为一个参数设置异常导致的。本文分享一下当时的情况。

2故障描述

DMP 收到告警 MySQL 从库的 SQL 线程停止了工作，去从库后台执行 show slave status\G：

可以看到 SQL 线程确实停止工作了，根据提示查看：select * from performance_schema.replication_applier_status_by_worker;

报错为：

Worker 1 failed executing transaction '44bbb836-19b4-11eb-aae3-98f2b315b1a5:216718523' at master log mysqlbin.000492, end_log_pos 533198991; Could not execute Delete_rows event on table cmbc_msearch.search_hotword_item; Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again, Error_code: 1197; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log mysqlbin.000492, end_log_pos 533198991

我们可以看到报错信息比较明显，是 max_binlog_cache_size 参数设置出现了问题。

查看主从的 max_binlog_cache_size 的大小，主库为 10G，从库为 10M。

3原理描述

官方文档^[2]了解 max_binlog_cache_size 参数：

binlog 是 MySQL 用来记录所有修改数据库数据的操作的二进制日志。在主从复制中，主库会把自己的 binlog 传输给从库，供从库执行相同的操作，以保证数据的一致性。而 max_binlog_cache_size 则是 MySQL 设置的最大 binlog 缓存大小。当事务过于复杂，多语句事务执行，需要写入 binlog 的数据量超过了这个值时，就会出现上述错误。

此时还要注意另一个参数 binlog_cache_size，这个参数给每个客户端分配用来存储二进制日志的缓存，而 max_binlog_cache_size 则表示所有客户端缓存使用的最大值。

4问题解决

从库为 10M 的历史原因也追溯不到，但主从设置参数不一致，且一个很大一个很小，是不合理的，也是导致本文中报错的主要因素。

max_binlog_cache_size 参数是可以通过在线动态修改的，现场解决方案，将从库的该值调大：

mysql> set global max_binlog_cache_size=10240000000;
Query OK, 0 rows affected (0.00 sec)

然后再开启主从复制，就正常了。

5总结

在运维过程中，合理配置和及时调整参数是确保系统稳定性和性能优化的重要环节，在修改一些参数的时候要充分了解相关知识概念，并且要掌握复制集群中相同参数的配置情况，确保合理合规修改，减少生产故障。

参考资料

[1]

云树 DMP: https://www.actionsky.com/cloudTreeDMP

[2]

max_binlog_cache_size: https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-options-binary-log.html

本文关键字：#MySQL# #复制# #参数配置#

阅读推荐

故障分析 | MySQL：我的从库竟是我自己！？

故障分析 | 一个 Kill 不掉的 MySQL 会话

技术分享 | OceanBase写入限速源码解读

故障分析 | innodb_thread_concurrency 导致数据库异常的问题分析

故障分析 | OceanBase 频繁更新数据后读性能下降的排查

故障分析 | MySQL 升级到 8.0 变慢问题分析

技术分享 | 一招解决 MySQL 中 DDL 被阻塞的问题

故障分析 | 一条本该记录到慢日志的 SQL 是如何被漏掉的

Gdevops 全球敏捷运维峰会北京站

7.21 爱可生开源社区将亮相【Gdevops 全球敏捷运维峰会北京站】，期待与您线下交流。

爱可生技术专家苏鹏，将带来主题演讲《大模型与向量数据库：敏捷运维的创新引擎》，敬请期待。

议题要点

大模型具备强大的语言理解和生成能力，向量数据库能高效存储和索引大规模向量数据。将两者结合，可实现高速数据访问、智能决策和快速问题解决。通过大规模数据分析与大模型预测，我们能快速发现关键问题、优化系统、提升可靠性和效率。本议题将深入探讨原理、优势和应用场景，分享创新解决方案和成功案例，具体包括以下内容：

智能决策和问题解决：如何利用大模型的语言理解和生成能力，结合向量数据库的相似性搜索，快速做出敏捷决策和解决问题；
系统优化和故障排查：如何通过对大规模运维数据的分析和挖掘，结合大模型的预测能力，快速发现系统优化和故障排查的关键问题；
数据驱动的运维策略：如何利用大模型和向量数据库的结合，实现数据驱动的运维策略，提升系统的可靠性、效率和安全性。

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=26622

赞同 0

评论 0 条