今天在MySQL 5.1同步到5.5时遇到一则卡库问题,在从库上show slave status \G,报错如下:
今天在MySQL 5.1同步到5.5时遇到一则卡库问题,在从库上show slave status \G,报错如下:
Error 'BIGINT UNSIGNED value is out of range in
'(group.mg_group_var.grp_status_cnt + -(38))'' on query. Default
database: 'group'. Query: 'update mg_group_var set
grp_status_cnt=grp_status_cnt+(-38) where mgid = '302412' and
grp_status_cnt>0'
为何在主库上能执行,在从库上就会失败呢?
追查原因
在从库上,show create table 查看表结构:
*************************** 1. row ***************************
Table: mg_group_var
Create Table: CREATE TABLE mg_group_var (
mgid bigint(20) NOT NULL,
grp_status_cnt int(11) unsigned NOT NULL DEFAULT '0',
grp_member_cnt int(11) unsigned NOT NULL DEFAULT '0',
grp_apply_cnt int(6) DEFAULT NULL,
发现grp_status_cnt 列为无符号的整数类型。 查询一下grp_status_cnt的值:
mysql> select grp_status_cnt from mg_group_var where mgid = '302412';
+----------------+
| grp_status_cnt |
+----------------+
|
27 |
+----------------+
27-38后得到的是负数。
官方手册中有一段话:对于无符号数,如果相减得到负数,mysql会自动转化为最大的正数。
(Subtraction between integer values, where one is of type
UNSIGNED, produces an unsigned result by default. If the
result would otherwise have been negative, it becomes the
maximum integer value)
验证一下
在5.1上执行如下语句:
mysql> SELECT CAST(0 AS UNSIGNED) - 1;
+-------------------------+
| CAST(0 AS UNSIGNED) - 1 |
+-------------------------+
| 18446744073709551615 |
+-------------------------+
但是在5.5上执行的时候就会报错:
mysql> SELECT CAST(0 AS UNSIGNED) - 1;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '()cast(0 as unsigned) - 1)'
按照官方文档的解释,在5.1上,当相减得到负数,马上就被转化为18446744073709551615,而它超出了无符号整数的范围,所以被转化为最大的int类型的无符号数4294967295(但是在5.5上,这个转化报错,因此导致同步中断)。
(When an out-of-range value is assigned to an integer
column, MySQL stores the value representing the corresponding
endpoint of the column data type range. If you store 256 into a
TINYINT or TINYINT UNSIGNED column, MySQL stores 127 or 255,
respectively. )
回到生产数据库,在主库上,执行:
mysql> select grp_status_cnt from mg_group_var where
grp_status_cnt > 300000000 limit 3;
+----------------+
| grp_status_cnt |
+----------------+
|
4294967295 |
|
4294967295 |
|
4294967272 |
+----------------+
可以发现这种溢出的情况很多,它们其实都是从负数转化来的,这些数据从应用的角度来说,都是错误的。
解决方法
解决从库卡库问题的办法很多,常用的有如下几种:
1.跳过指定的错误代码
重启mysql,设置=1069。这需要重启数据库,代价太大,所以不推荐。
用watch -n与mysql命令相结合,每秒跳过一个命令点:
watch -n 1 'mysql -uroot -prootpassword -S /tmp/
mysql4389.sock -e "set global sql_slave_skip_counter=1;start slave;" '
但是watch的时间间隔最小只能到1s,因此只适合跳过少数卡库的命令点。如果从库卡库累积的命令点非常多,此法就不可取了。
用pt-slave-restart工具跳过命令点。这也是推荐的跳过命令点的方法:
2.跳命令点始终只能解决一时的问题,根本上还是应修改代码逻辑,确保不出现无符号减法的溢出。
3.对DBA来说,,采用行格式复制,从根本上可以保证主从数据的一致性。毕竟跳过卡库问题是简单的,但是后续的数据修复过程却是复杂的。
参考资料
--------------------------------------分割线 --------------------------------------
Ubuntu 14.04下安装MySQL
《MySQL权威指南(原书第2版)》清晰中文扫描版 PDF
Ubuntu 14.04 LTS 安装 LNMP Nginx\PHP5 (PHP-FPM)\MySQL
Ubuntu 14.04下搭建MySQL主从服务器
Ubuntu 12.04 LTS 构建高可用分布式 MySQL 集群
Ubuntu 12.04下源代码安装MySQL5.6以及Python-MySQLdb
MySQL-5.5.38通用二进制安装
--------------------------------------分割线 --------------------------------------
本文永久更新链接地址:
本文原创发布php中文网,转载请注明出处,感谢您的尊重!