火元素水元素风元素雷元素草元素冰元素岩元素
加载中...
avatar
文章
51
标签
77
分类
6
博客
工具
关于
列表
  • 归档
  • 标签
  • 分类
梦想歌の网络日志使用 MySQL 系统库排查线上问题 返回首页
搜索
博客
工具
关于
列表
  • 归档
  • 标签
  • 分类

使用 MySQL 系统库排查线上问题

发表于2022-06-15|更新于2025-12-10|线上排查
|浏览量:

文章作者: 梦想歌
文章链接: https://mengxiangge.netlify.app/2022/06/15/mysql/使用 MySQL 系统库排查线上问题/
版权声明: 本博客所有文章除特别声明外,均采用 Apache 2.0 License 许可协议。转载请注明来源 梦想歌の网络日志!
数据库MySQL性能优化
赞助
  • 微信
    微信
  • 支付宝
    支付宝
cover of previous post
上一篇
深入浅出 MySQL:Buffer Pool 缓冲池
cover of next post
下一篇
MySQL 从库同步延迟解决方案
问题描述MySQL 主库使用云厂商较高配置,规格为 32U 128G 2.5T,数据空间实际使用 1.5 T,日志空间使用 0.5T,如下图。 MySQL 从库通过 K8s 自行搭建,使用 MySQL 原生镜像,规格为 4U 24G。 由于两者配置差距太大,MySQL 从库经过出现同步延迟或者同步报错的现象,MySQL 从库的 my.cnf 配置如下。 12345678910111213141516171819202122232425262728[mysqld]server_id=服务器唯一标识# 服务器默认字符集character_set_server=utf8# 表名是否忽略大小写:0 表示区分大小写,1 表示不区分大小写,2 表示 Windows 下不区分大小写lower_case_table_names=1 # 启用事件调度器:1 表示启用,0 表示禁用。event_scheduler=1 # 最大并发连接数max_connections=10000# 允许的最大连续连接错误次数max_connect_errors=200# 错误日志中记录的最大错误条目数max_err...
相关推荐
cover
2022-06-25
深入浅出 MySQL:Buffer Pool 缓冲池
cover
2022-06-15
MySQL 从库同步延迟解决方案
问题描述MySQL 主库使用云厂商较高配置,规格为 32U 128G 2.5T,数据空间实际使用 1.5 T,日志空间使用 0.5T,如下图。 MySQL 从库通过 K8s 自行搭建,使用 MySQL 原生镜像,规格为 4U 24G。 由于两者配置差距太大,MySQL 从库经过出现同步延迟或者同步报错的现象,MySQL 从库的 my.cnf 配置如下。 12345678910111213141516171819202122232425262728[mysqld]server_id=服务器唯一标识# 服务器默认字符集character_set_server=utf8# 表名是否忽略大小写:0 表示区分大小写,1 表示不区分大小写,2 表示 Windows 下不区分大小写lower_case_table_names=1 # 启用事件调度器:1 表示启用,0 表示禁用。event_scheduler=1 # 最大并发连接数max_connections=10000# 允许的最大连续连接错误次数max_connect_errors=200# 错误日志中记录的最大错误条目数max_err...
cover
2023-10-25
使用 binlog2sql 工具在线恢复数据
背景生产数据库执行 SQL 脚本,一般会经过正规的审批流程才能运行。但有些情况是例外的,业务部门在提出一些删除数据的需求后打算撤回,或者在运营后台不小心删除了一些数据,然后找到 DBA 团队协助,希望能恢复数据。 经调研,binlog2sql 是大众点评开源的一款用于解析 MySQL binlog 的工具,根据不同选项,可以得到原始SQL、回滚SQL、去除主键的INSERT SQL 等,适用于数据快速回滚(闪回)和主从切换后新 Master 丢数据的修复工作。 目标验证 binlog2sql 工具是否可以快速恢复数据。 步骤准备工作安装 binlog2sql 工具。 123456> git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql# > yum install python3-pip# > whereis pip# > pip3.6 install -r requirements.txt> pip install -r requirement...
cover
2023-02-10
MySQL 存储 emoji 报错问题排查
问题描述我们使用 MySQL 在特定业务场景(帖子、评论、个人签名)存储 emoji 表情。Server 配置和建表语句统一使用 utf8mb4,仍然抛出如下错误:java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x94' for column 'name' at row 1。 原因分析MySQL 的 utf8 编码最多支持 3 个字节,而 emoji 表情需要占用 4 个字节,在早期的版本并没有实现真正意义上的 utf8 字符集。MySQL 从 5.5.3 版本开始支持 utf8mb4 字符集。 我们检查了 Server 的版本和配置,确定字符集用的是 utf8mb4,也检查了客户端连接 Server 的参数,也没发现其他异常。 将代码部署到自建的 MySQL 环境,可以正常存储,但是部署到云数据库 MySQL,就会报错,基本上判断是云厂商配置的问题。 因云数据库的环境不支持在 Server 端配置 character-set-client-handshake 或者 init...
cover
2023-01-10
MySQL 时区相差 5 小时问题排查
问题描述最近经业务部门反馈,我们有个 APP 升级后,在 2023-01-09 22:47 发现,当前账号的最近登录时间为 2023-01-10 03:47,相差了 5 个小时。 第一轮排查:我们第一印象会认为是刚升级的代码出了问题,有可能是日期格式化没处理好,也有可能是 JSON 序列化没有指定时区,经过 Git diff 排查,我们并没有修改相关代码。 第二轮排查:可能是有人动了生产配置!排除了配置中心的改动,也检查了 K8s 的 Deployment 是否正确设置了 TZ=Asia/Shanghai,依然无果。 第三轮排查:提取线上部署的 jar,经过对比,我们发现 MySQL 驱动从原来的 5.1.45 升级到了 8.0.22 版本。 原因分析生产数据库的配置是 time_zone=SYSTEM(对应 system_time_zone=CST,CST 时区没有标准,我们在使用 Java 客户端连接默认会把 CST 解析为时区+3,也就是当时事故出现的 5 小时误差)。 应用配置连接数据库的 jdbc-url 没有显示设置时区。MySQL驱动如果升...
目录
  1. 1.
© 2020 - 2025 By 梦想歌
下一次相逢会在何时,天空必将见证。
搜索
数据加载中