MySQL 常见故障处理

【错误过程】：MySQL从5.1升级至5.5后在调用存储过程时报出“Cannot load from mysql.proc. The table is probably corrupted。

【造成原因】：MySQL升级完成后未对相关数据库执行升级.

【解决办法】：在命令行中执行mysql_upgrade -uroot -p 即可~

【错误过程】：多实例调用sp生成临时表的时候导致从断开

【造成原因】：生成临时表会在/tmp下产生临时文件，多个同时调用会出现冲突的情况

【解决办法】：应按实例区分开

【错误过程】：MySQL 主从中断,1236报错

【造成原因】：

sync_binlog=0时 ，master binlog文件的flush log buffer（这个buffer是由于binlog文件的os buffer)  到disk是依赖于OS本身的，但Slave IO 线程在读取master dump 线程的位置，一般是直接读取log buffer的，这个位置，可能远远大于binlog文件实际大小。所以当主机宕机后，binlog buffer未刷盘，当Master主机再次启动后，此时从库的binlog pos已经比实际的binlog文件大小还大了。

【解决办法】：

如果innodb_flush_log_at_trx_commint=1的话，这一般对主从不会有影响的，直接做change master to到当下一个binlog。如果是其他值2或0，可能有点小差别。 

【错误过程】：MySQL 主从中断,1032报错

【造成原因】：

由于主上的binlog-format是mixed，这样在主从同步修改数据的时候会使用rowed模式，直接修改对应数据，如果此时主从数据不一致的话，就会出现找不到记录的1032的错误。

【解决办法】：

保持主从数据一致性

【错误过程】：MySQL 出现大量Too many connections

【造成原因】：

查询发现这算属MySQL的一个bug，不管连接是通过hosts还是ip的方式，MySQL都会对DNS做反查，IP到DNS，由于反查的接续速度过慢（不管是不是isp提供的dns服务器的问题或者其他原因），大量的查询就难以应付，线程不够用就使劲增加线程，但是却得不到释放，所以MySQL会“假死”。

【解决办法】：

在配置文件加上以下参数即可

--skip-name-resolve，不要解析正检查客户端连接的主机名。只使用IP号。如果你使用该项， 授权表中的所有Host列值必须为IP号或localhost。