xtrabackup crashed during apply 5.5 backup set with utf8_general50_ci collation
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB | Status tracked in 2.4 | |||||
2.3 |
Fix Released
|
Medium
|
Vasily Nemkov | |||
2.4 |
Fix Released
|
Medium
|
Vasily Nemkov |
Bug Description
When I recover backup set from PS 5.5 using PXB 2.2/2.3, xtrabackup crashed:
2016-01-13 22:59:45 2ad8f06cf480 InnoDB: Assertion failure in thread 47111234974848 in file ha_innodb.cc line 1615
InnoDB: Failing assertion: cset == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://
InnoDB: about forcing recovery.
14:59:45 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
innobackupex(
innobackupex(
/lib64/
/lib64/
/lib64/
innobackupex() [0x6894a2]
innobackupex(
innobackupex(
innobackupex(
innobackupex(
innobackupex(
innobackupex() [0x5c34e6]
innobackupex(
innobackupex(
innobackupex(
innobackupex() [0x58fac7]
innobackupex(
/lib64/
innobackupex() [0x585ea9]
Please report a bug at https:/
Writing a core file
Aborted
When use the binary complied from source, and run with gdb, the backtrace is
#0 0x00002aaaabbe48a5 in raise () from /lib64/libc.so.6
#1 0x00002aaaabbe6085 in abort () from /lib64/libc.so.6
#2 0x00000000006e9a7e in innobase_
#3 0x00000000006a32f5 in dtype_get_mblen (mtype=13, prtype=16581118, mbminlen=
#4 0x00000000006a5118 in dict_mem_
#5 0x00000000006a470b in dict_mem_
#6 0x000000000075dc87 in dict_load_
#7 0x000000000075df80 in dict_load_columns (table=0x1a3cfd8, heap=0x1a350f0) at percona-
#8 0x00000000007605b9 in dict_load_table (name=0x1a35038 "test/sbtest1", cached=1, ignore_
#9 0x0000000000760c9e in dict_load_
#10 0x00000000007f2123 in dict_table_
#11 0x00000000007f35f9 in dict_table_
#12 0x000000000088bf31 in trx_resurrect_
#13 0x000000000088c743 in trx_lists_
#14 0x00000000008070b9 in trx_sys_
#15 0x00000000006aaad0 in innobase_
#16 0x000000000061779d in innodb_init () at percona-
#17 0x00000000006200ac in xtrabackup_
#18 0x0000000000621883 in main (argc=133, argv=0x1718898) at percona-
With the backtrace, and after reading the source code, I found it is a compatibility problem between PS 5.5 and Oracle/MySQL 5.6.
As we can see from the backtrace, cset=253, corresponding to 'utf8_general50_ci' collation in PS 5.5, which not exists in Oracle/MySQL 5.6, and xtrabackup 2.2/2.3 is compiled against Oracle/MySQL 5.6.
After some google dig, I found a related bug report for Percona Server here https:/
In order to fix some early bugs, PS introduced two collation utf8_general50_ci and ucs2_general50_ci, but Oracle use the other two collations utf8_general_
ucs2_general_
I think a simple fix would be allow 253 collaton in innobase_
BTW, such backup set can be constructed by creating table like this:
CREATE TABLE `sbtest1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) CHARACTER SET utf8 COLLATE utf8_general50_ci NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
and then take a backup.
During backup, please update this table sbtest1 frequently, such as using sysbench.