mysql错误案例
报错案例1--加索引报错
对mysql的一个大于10G的表加索引，出现 repair with keycache
原因如下
查询myisam_max_sort_file_size参数：
mysql> show variables like '%myisam_max_sort_file_size%';
+---------------------------+-------------+
| Variable_name | Value |
+---------------------------+-------------+
| myisam_max_sort_file_size | 10737418240 |
+---------------------------+-------------+
发现设置的是10G，而表的大小已经是10G，这里只需要改为20G即可
mysql> set SESSION myisam_max_sort_file_size = 20971520; #这里为当前会话生效
Query OK, 0 rows affected (0.01 sec)
mysql> set GLOBAL myisam_max_sort_file_size = 20971520; ##这里为全局会话生效
Query OK, 0 rows affected (0.01 sec)
报错案例2
2.1 MySQL从5.1升级到5.6中的报错
在CentOS6.4中对MySQL从5.1升级到5.6的版本之后，
建好表后，想保存备份一下表结构时，提示如下错误：
Cannot load from mysql.proc. The table is probably corrupted
MySQL导出数据库结构出现Cannot load from mysql.proc错误的解决方法
在网上搜了下解决方法，所有的文章几乎都是这么说：
执行以下命令：
mysql_upgrade -uroot -p密码
我试了无数次，在我这里无效，问题还是没有得到解决。
最后让我找到了这篇文章：http://www.linuxidc.com/Linux/2013-12/93864.htm
也就是从mysql5.5的版本开始，proc这张表中的comment字段的列属性已经由char(64)改为text类型，我们需要更改一下数据类型：
ALTER TABLE `proc`
MODIFY COLUMN `comment` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL AFTER `sql_mode`;
最后问题得到了解决。
从库报错--1548错误
mysql5.5 从库报错error caanot load from mysql.proc
网上搜到资料
执行以下命令：mysql_upgrade -uroot -p密码（没尝试）
我是直接执行
stop slave;
set global sql_slave_skip_counter=1;
start slave;
问题解决
报错案例3--1032错误
1032错误----现在生产库中好多数据，在从库误删了，生产库更新后找不到了，现在主从不同步了，再跳过错误也没用，因为没这条，再更新还会报错
报错信息：在master上更新一条记录，而slave上找不到，丢失了数据。
Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND;
the event's master log mysql-bin.000010, end_log_pos 794
解决方案
Part1:临时方案
mysql> stop slave;
Query OK, 0 rows
affected (0.00 sec)
mysql> set global sql_slave_skip_counter=1;
Query OK, 0 rows
affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows
affected (0.00 sec)
Part2:永久方案
end_log_pos 有了它，根据pos值，直接就能找到，找到delete那条数据，反做（变成insert）
1.分析master的binlog日志：
[root@test etc]# /usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000010 | grep -A '10' 794
#120302 12:08:36 server id 22 end_log_pos 794 Update_rows: table id 33 flags: STMT_END_F
# UPDATE hcy.t1
# WHERE
# @1=2 /* INT meta=0 nullable=0 is_null=0 */
# @2='bbc' /* STRING(4) meta=65028 nullable=1 is_null=0 */
# SET
# @1=2 /* INT meta=0 nullable=0 is_null=0 */
# @2='BTV' /* STRING(4) meta=65028 nullable=1 is_null=0 */
# at 794
#120302 12:08:36 server id 22 end_log_pos 821 Xid = 60
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
2.在slave上，查找下更新后的那条记录，应该是不存在的。
mysql> select * from t1 where id=2;
Empty set (0.00 sec)
然后再到master查看
mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
| 2 | BTV |
+----+------+
1 row in set (0.00 sec)
3.把丢失的数据在slave上填补，然后跳过报错即可。
mysql> insert into t1 values (2,'BTV');
Query OK, 1 row affected (0.00 sec)
mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
| 2 | BTV |
+----+------+
1 row in set (0.00 sec)
mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G;
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
总结：从库删除一条数据，查看slave状态正常，当主库的这条数据进行更新时，从库就会报错，如果你临时跳过错误，当下次这条数据再进行更新时，从库会再次报错，所以不要轻易跳过从库报错
案例3参考网址：http://xstarcd.github.io/wiki/MySQL/online_mysqlrepl_error.html
报错案例4--1050错误
mysql从库报错，错误代码1050，查询app这个库并没有这个表，所以判断是临时表。
Last_Errno:1050
Last_Error:Error 'Table 'temp_report' already exists' on query. Default database:'app'.Query:'CREATE TABLE `temp_report`(
`a0` varchar(1) NOT NULL DEFAULT'',
`a1` varchar(5) NOT NULL DEFAULT'',
`v1` varchar(33) DEFAULT NULL,
`v1` varchar(33) DEFAULT NULL
)'
解决办法：
在从库的配置文件中忽略这个临时表
[root@server tmp] vi /etc/my.cnf
replicate-ignore-table = app.temp_report
[root@server tmp] /etc/init.d/mysqld restart
报错案列5--1236错误
报错如下：
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin.001841' at 826366537, the last event read from './mysql-bin.002333' at 2828282975, the last byte read from './mysql-bin.002333' at 2828283169.'
排查过程：
1.查看主节点binlog
[root@cn-mysql03 ~]# /mysql/bin/mysqlbinlog /var/mysql/mysql-bin.002333 --start-position=2828266574 --stop-position=2828282975
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#140123 1:46:33 server id 3 end_log_pos 107 Start: binlog v 4, server v 5.5.32-log created 140123 1:46:33
BINLOG '
+QPgUg8DAAAAZwAAAGsAAAAAAAQANS41LjMyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
'/*!*/;
# at 2828266574
# at 2828267161
# at 2828279625
# at 2828280668
# at 2828281262
# at 2828281779
# at 2828282383
ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 607, event_type: 23
ERROR: Could not read entry at offset 2828282975: Error in log format or read error. #报错binlog位置2828282975，是mysql-bin.002333最后一个position位置
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
查看mysql官网的说明,当binlog最后遇到一个大事务时会将日志记录在这个日志,而不会跨binlog记录一个事务,于是我继续查看看mysql-bin.002334的日志头内容；
[root@cn-mysql03 ~]# /mysql/bin/mysqlbinlog /data/3306/data/mysql-bin.002334 --start-position=107|more
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#140123 1:33:21 server id 3 end_log_pos 107 Start: binlog v 4, server v 5.5.32-log created 140123 1:33:21
BINLOG '
4QDgUg8DAAAAZwAAAGsAAAAAAAQANS41LjMyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
'/*!*/;
# at 107
#140123 2:04:59 server id 3 end_log_pos 267 Query thread_id=5575071 exec_time=1 error_code=0
use `ptmind_56fbce4e`/*!*/;
SET TIMESTAMP=1390413899/*!*/;
SET @@session.pseudo_thread_id=5575071/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=0/*!*/;
SET @@session.auto_increment_increment=2, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP TABLE IF EXISTS `sum_page_visits_stats_olap_m_tmp` /* generated by server */
/*!*/;
这个日志的开头也没有说明是继续上一个binlog的最后一个事务.
确认以上问题后，重新从下一个日志开始启动主从同步；
重新change master指定新binlog恢复主从同步
mysql> change master to
master_host='192.168.16.x',
master_port=3306, master_user='xxx',
master_password='xxxxx',
master_log_file='mysql-bin.002334',
master_log_pos=0;
mysql>
mysql> slave start;
问题总结：
经查询资料此现象可能是mysql binlog bug ，当一个binlog即将用完时，如果此时mysql开启一个新的事务，现在binlog不能够存放事务产生的日志就可能出现此问题。
