A strange problem: Last_Errno: 1264 Error 'Out of range value for column 0x322E36343030

Scene environment:

  1. Both master and slave are: Server version: 5.7.16-log MySQL Community Server (GPL)

  2. Operating system: CentOS release 6.7 (Final)

  3. The business side writes hundreds of pieces of data in batches to the main database through SAS software.

 

Received an alarm and found that the slave library show slave status \G; the following alarm

Last_Errno: 1264
Last_Error: Error 'Out of range value for column 'loan_amount' at row 1' on query. Default database: 'chedai'. Query: 'INSERT INTO test_list2 (loan_amount,APPLYUSERGROUPID,lastapplyid,validdate)  VALUES ( 0x322E3634303030303030303030303030303030652B303035 , 0x3131313130313234 , 0x392E3839353230393030303030303030303030652B303036 , 0x323031382D30352D3331 )'
Skip_Counter: 0
View Code

When the slave library applies the main library binlog, it finds that the actual value exceeds the field definition length. But when in doubt: why the main library can be successfully executed, and the slave library reports an error.

The data tables that have been successfully inserted from the main database are:

+-------------+------------------+-------------+------------+
| loan_amount | APPLYUSERGROUPID | lastapplyid | validdate |
+-------------+------------------+-------------+------------+
| 264000 | 11110124 | 9895209 | 2018-05-31 |
| 80000 | 11110122 | 9896660 | 2018-05-31 |
| 216000 | 11111162 | 9900036 | 2018-05-31 |
| 208000 | 11143122 | 9907101 | 2018-05-31 |
| 176000 | 11121775 | 9922122 | 2018-05-31 |
| 110000 | 11111804 | 9928679 | 2018-05-31 |
| 68800 | 11110963 | 9941918 | 2018-05-31 |
| 68000 | 11143124 | 9944861 | 2018-05-31 |
| 50000 | 11111164 | 9949087 | 2018-05-31 |
| 54000 | 11121640 | 9951020 | 2018-05-31 |
+-------------+------------------+-------------+-----------

Parsing the corresponding binlog, indeed all the values ​​have become hexadecimal, the screenshot is as follows:

Doubt: Why is the value parsed by mysqlbinlog in hexadecimal? It also matches the error message on the slave.

Thinking that the binlog_format setting of this library is mixed, the first thought is whether this problem can be avoided if it is changed to ROW format, if the following test is done:

1. mysql>set global binlog_format=row;

2. Ask the students on the R&D side to rewrite the data according to the original steps.

3. Parse the corresponding binlog, and the results are as follows:

So far, mysqlbinlog can be parsed normally, and at the same time, the slave is also synchronized normally.

Conclusion: This environment successfully avoided this problem by modifying binlog_format=row. At the same time, it is also recommended to set this parameter to row in the production environment, but what is the specific reason? A previous article mentioned that the jdbc version is compatible with the mysql server version. For details, see:

http://www.itpub.net/forum.php?mod=viewthread&action=printable&tid=1402633

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325008027&siteId=291194637
Recommended