今天,又掉坑了。 以前踩到过MySQL主键溢出的状况,经过prometheus监控起来了,具体见这篇MySQL主键溢出复盘html
此次遇到的坑,更加的隐蔽。 是一个log表里面的一个int signed类型的列写满了。快速的解决方法固然仍是只能切新表来救急了,而后搬迁老表的部分历史数据到热表。 mysql
亡羊补牢,处理完故障后,赶忙写脚本把生产的其余表都捋一遍。sql
下面是我暂时用的一个检测脚本,还不太完善,凑合用shell
分2个文件(1个sql文件,1个shell脚本)
数据库
check.sql 内容以下:bash
SELECT cast( pow(2, case data_type when 'tinyint' then 7 when 'smallint' then 15 when 'mediumint' then 23 when 'int' then 31 when 'bigint' then 63 end+(column_type like '% unsigned'))-1 as decimal(30,0)) as max_int, ' - ', concat ('(', concat('select ','max(',COLUMN_NAME,')',' from ',TABLE_SCHEMA,'.',TABLE_NAME),')') from information_schema.COLUMNS where TABLE_SCHEMA NOT IN ('information_schema','sys','test','mysql','performance_schema') AND DATA_TYPE IN ('int' ) ;
直接到数据库里面执行,效果相似这样:session
check.sh 内容以下:
dom
#!/bin/bash # 监测int类型的当可用空间少500w的时候,提醒作DDL操做 # 设置 session级别的 max_execution_time为2秒,防止没有索引的大的拖慢数据库,可是这样可能漏判部分列,须要注意下 # 注意:我这里bigint类型的没有检查,若是须要请修改 check.sql where条件中的DATA_TYPE加上 bigint的检查 source /etc/profile set -u mkdir $(date +%F) -pv # step1 检测 for host in {'192.168.1.100','192.168.1.110','192.168.1.120','192.168.1.130'}; do mysql -udts -pdts -h${host} -BN < check.sql 2>/dev/null > sql.log wait echo "说明: | 当前列容许的最大值 | 巡检用的SQL " >> $(date +%F)/$host.log while read line; do ret=$(mysql -udts -pdts -h${host} -BNe "set session max_execution_time=2000;select $line" 2>/dev/null) echo ${ret} if [[ "${ret}" == "NULL" ]]; then continue fi if [ ${ret} -lt 5000000 ] ; then echo "$line 剩余空间 ${ret}, 该表可用水位不足500W,建议作DDL修改成bigint类型" >> $(date +%F)/$host.log fi done < ./sql.log done # step2 将检查的内容打包发邮件(这里可能须要根据本身生产的状况改改) tar czf $(date +%F).tar.gz $(date +%F) sendemail -s 192.168.1.200 -f post@domain.com -t ergou@domain.com -a $(date +%F).tar.gz -u "$(date +%F) int水位线巡检日志" -o message-content-type=html -o message-charset=utf8 -m "内容详见附件" # step3 清理每日生成的以日期命名的目录和tar.gz文件,这里我就不贴命令
再配个天天上午10点的cronjob便可,ide
最终天天收到邮件里面内容大体相似以下:post