使用MySQL的业务,大多都会用到MySQL的Replication,做读写分离,HA,热备份或者增量都少不了利用主从机制.
不过,很多情况下都会报 1032 和 1205 错误.tudou@Gyyx
首先1032.
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;
造成1032错误的根本原因是主从数据库数据不一致,导致同步操作在从库上无法执行.
目前我所遇到的情况分为两种:
1 Replication 时使用了 主--binlog-do-db=db_name或者从--replicate_do_db=db_name.
假设 有两个库 pubs 和 test,忽略的是test,结果有这样一条sql 在 主上的test库执行:insert into pubs.tname values(XXXXX);
那么根据服务的配置,主上执行成功,从上没有执行,就会引发1032错误
2 TRIGGER 和 PROCEDURE的版本问题,如果在主从上版本不一致,例如主上的某个PROCEDURE执行后写入了5条数据,而从上执行后只写入了1行数据,这时,必然会引发1032错误
解决方法:
1 不使用 --binlog-do-db 和 --replicate_do_db=db_name
改为 从上 --replicate_wild_do_table=db_name.%
2 保证 主从 TRIGGER 和 PROCEDURE的版本一致
再说说 1205:
这个错误就比较好理解了,一般都是主上的操作连接是autocommit的,结果运行超时失败,从库上进行同步时就会报错.
两种做法:
1 在主上设置my.cnf innodb_rollback_on_timeout=1,超时时rollback
2 在从上忽略1052.my.cnf--slave-skip-errors=1205
主库上发生1205,往往是因为锁超时。例如对某张表使用事务,结果一个事务迟迟没有提交,另一个事务等待前一个事务提交,锁等待超时,后一个事务就挂了。这时主库上就发生1205错误。最常见的是一张表中有自增长id,一个insert开启的事务因为若干原因迟迟不能提交,这样后面的事务,再向表中做insert 操作时就要等待前面的insert操作commit。这些都需要DBA与R&D配合完成。服务表现是cpu使用率不高,但是load值奇高。查innodb status可以随机抓到锁冲突。
另外再某些网络中还会报[ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
一般的情况下三种情况会造成2013错误
1 反向解析
2 max_allowed_packet 不一致
3 网络问题
解决方法
1 skip-name-resolve 禁用反向解析
2 配置主从max_allowed_packet为相同的值
3 调整 net_write_timeout 的值
小插曲,在我写手记的时候一个朋友报2013错误,使用了上面三种方案都不见效,并且非常准时的出现Lost connection to MySQL server ,最后查出竟然是网络代理程序控制了连接超过30分钟自动挂断....