InnoDB: Failing assertion: sym_node->table != NULL

[Jervin R]

It seems with the unified xtrabackup binary, it cannot distinguish or apply the same logic when a backup is taken from an older version and prepared on a newer one i.e. does not honor xtrabackup_binary. For example, when I take a backup from 5.5, and prepare on a server with 5.6 installed and xtrabackup 2.2.5, it tries to prepare the backup with 5.6 code.

xtrabackup version 2.2.5 based on MySQL server 5.6.21 Linux (x86_64) (revision id: )

As workaround I use binaries from xtrabackup 2.1.9

[Alexey Kopytov (akopytov)]

This is intended. What exactly seems to be the problem?

[Jervin R (revin)]

Alexey, makes sense, this is because I get a crash on 2.2.5 - backup was taken from 5.5.34.

InnoDB: Doing recovery: scanned up to log sequence number 2864457776640 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 2864462678777 (99%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 16592982, file name mysql-bin.000750
InnoDB: Last MySQL binlog file position 0 574359709, file name ./mysql-bin.000149
2014-10-19 18:29:44 7f9c26613720 InnoDB: Assertion failure in thread 140308635531040 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
23:29:44 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: 0x2e07eb0
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 = 2e08ec0 thread_stack 0x10000
xtrabackup(my_print_stacktrace+0x35) [0x9f2a9c]
xtrabackup(handle_fatal_signal+0x2bb) [0x7f5cd3]
/lib64/libpthread.so.0() [0x33a7c0f710]
/lib64/libc.so.6(gsignal+0x35) [0x33a7432925]
/lib64/libc.so.6(abort+0x175) [0x33a7434105]
xtrabackup() [0x76b100]
xtrabackup(pars_update_statement(upd_node_t*, sym_node_t*, void*)+0x30) [0x76ba28]
xtrabackup(yyparse()+0xcb1) [0xa5c6b7]
xtrabackup(pars_sql(pars_info_t*, char const*)+0xaf) [0x76d1bd]
xtrabackup(que_eval_sql(pars_info_t*, char const*, unsigned long, trx_t*)+0x85) [0x78dfea]
xtrabackup(row_drop_table_for_mysql(char const*, trx_t*, bool, bool)+0xa98) [0x71fb84]
xtrabackup(row_mysql_drop_temp_tables()+0x24c) [0x72067b]
xtrabackup(recv_recovery_rollback_active()+0x2c) [0x752ff8]
xtrabackup(innobase_start_or_create_for_mysql()+0x17aa) [0x72855c]
xtrabackup() [0x606fae]
xtrabackup() [0x60f6ba]
xtrabackup(main+0xc33) [0x610e5f]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x33a741ed1d]
xtrabackup() [0x603fb9]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
innobackupex: Error:
innobackupex: ibbackup failed at /usr/bin/innobackupex line 2619.

[Alexey Kopytov (akopytov)]

Thanks. This looks like a recently introduced incompatibility between 5.5 and 5.6, which has been reported elsewhere. I have updated the but title. But we still need a reproducible case.

[Alexey Kopytov (akopytov)]

See also bug #1257266.

[Alexey Kopytov (akopytov)]

The previous comment should link to bug #1399471.