关闭

故障案例:定时备份可能引起的问题

标签: mysqldump故障处理
621人阅读 评论(0) 收藏 举报
分类:

场景1:db内存1.5G,业务很少,平时qps不到10,每天凌晨5点到9点内存使用飙升到100%,内存100%时qps有个激增到20,cpu使用率也有激增


解决方法

1 查看缓冲池大小是900M

mysql> show variables like '%innodb_buffer_pool_size%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 943718400 |
+-------------------------+-----------+
1 row in set (0.00 sec)

2 查看缓冲池使用率 show engine innodb  status,查看还剩41226*16/1024=644M

Buffer pool size   57599
Free buffers       41226
Database pages     16326
Old database pages 6040
Modified db pages  13

3 因为周期性的原因,查看当时的定时备份时间,发现开始时间正好是晚上5点,确认是db备份引起的

backup_count: 7
backup_begintime: 5
backup_duration: 24
manual_backup_count: 3

4 因为mysqldump前会有一个flush tables with read lock的操作来记录下当前状态show master status,如果当前有查询,这个操作会等待所有当前查询完成后才执行。内存较少,建议客户升级内存,优化慢查询。


场景2:主库在每天凌晨3点,连接数突然从600激增到1200以上,并堆积许多慢查询,持续几个小时,其他监控参数都比较正常


解决方法

1 查看到当时的慢查询均是些简单SQL,SQL语句本身不存在问题

2 查看到主库备份时间为凌晨3点,确定是定时备份引起的

3 因为正好存在从库,后续将定时备份移到从库解决,mysqldump --dump-slave=2


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:120758次
    • 积分:2335
    • 等级:
    • 排名:第16017名
    • 原创:100篇
    • 转载:2篇
    • 译文:8篇
    • 评论:26条
    最新评论