##########################################################################
# Bug 1192834: Crash during apply with index compaction enabled #
##########################################################################
vlog "Restoring MySQL datadir"
mkdir -p $mysql_datadir
innobackupex --copy-back $backup_dir
start_server
Crash:
InnoDB: Starting in background the rollback of uncommitted transactions
2015-04-28 16:07:16 10aa60000 InnoDB: Rolling back trx with id 1920, 16049 rows to undo
InnoDB: 128 rollback segment(s) are active.
InnoDB: Progress in percents: 1InnoDB: Waiting for purge to start
2015-04-28 16:07:16 10aa60000 InnoDB: Assertion failure in thread 4473618432 in file btr0cur.cc line 700
InnoDB: Failing assertion: fil_page_get_type(page) == 17855
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.
09:07:16 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.
Test case #2:
####### ####### ####### ####### ####### ####### ####### ####### ####### ####### #### ####### ####### ####### ####### ####### ####### ####### ####### ####### ####
# Bug 1192834: Crash during apply with index compaction enabled #
#######
. inc/common.sh
start_server --innodb_ file_per_ table
load_dbase_schema sakila
load_dbase_data sakila
function start_uncomitte d_transaction( )
{
run_cmd $MYSQL $MYSQL_ARGS sakila <<EOF
START TRANSACTION;
DELETE FROM payment;
SELECT SLEEP(10000);
EOF
}
start_uncomitte d_transaction &
job_master=$!
sleep 2
backup_ dir="$topdir/ backup"
innobackupex --no-timestamp --compact $backup_dir
vlog "Backup created in directory $backup_dir"
kill -SIGKILL $job_master
stop_server
# Remove datadir
rm -r $mysql_datadir
# Restore sakila
innobackupex --apply-log --rebuild-indexes $backup_dir
vlog "Restoring MySQL datadir"
mkdir -p $mysql_datadir
innobackupex --copy-back $backup_dir
start_server
Crash:
InnoDB: Starting in background the rollback of uncommitted transactions
2015-04-28 16:07:16 10aa60000 InnoDB: Rolling back trx with id 1920, 16049 rows to undo
InnoDB: 128 rollback segment(s) are active.
InnoDB: Progress in percents: 1InnoDB: Waiting for purge to start get_type( page) == 17855 bugs.mysql. com. dev.mysql. com/doc/ refman/ 5.6/en/ forcing- innodb- recovery. html
2015-04-28 16:07:16 10aa60000 InnoDB: Assertion failure in thread 4473618432 in file btr0cur.cc line 700
InnoDB: Failing assertion: fil_page_
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.
09:07:16 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: 0x10aa60000 platform. dylib 0x00007fff826dcf1a _sigtramp + 26 cur_search_ to_nth_ levelP12dict_ index_tmPK8dtup le_tmmP9btr_ cur_tmPKcmP5mtr _t + 4500 pcur_open_ lowP12dict_ index_tmPK8dtup le_tmmP10btr_ pcur_tPKcmP5mtr _t + 195 search_ index_entryP12d ict_index_ tPK8dtuple_ tmP10btr_ pcur_tP5mtr_ t + 166 undo_mod_ del_unmark_ sec_and_ undo_updatemP9q ue_thr_ tP12dict_ index_tP8dtuple _t + 610 undo_mod_ del_mark_ secP11undo_ node_tP9que_ thr_t + 472 undo_modP11undo _node_tP9que_ thr_t + 738 undoP11undo_ node_tP9que_ thr_t + 523 undo_stepP9que_ thr_t + 207 thr_stepP9que_ thr_t + 990 run_threads_ lowP9que_ thr_t + 298 run_threadsP9qu e_thr_t + 206 rollback_ activeP5trx_ t + 646 rollback_ resurrectedP5tr x_tm + 400 rollback_ or_clean_ recoveredm + 737 or_clean_ all_recovered + 99 pthread. dylib 0x00007fff8ee9d268 _pthread_body + 131 pthread. dylib 0x00007fff8ee9d1e5 _pthread_body + 0 pthread. dylib 0x00007fff8ee9b41d thread_start + 13
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
0 xtrabackup 0x0000000101cab9c8 my_print_stacktrace + 72
1 xtrabackup 0x00000001023efd15 handle_fatal_signal + 597
2 libsystem_
3 ??? 0x0000000000000005 0x0 + 5
4 libsystem_c.dylib 0x00007fff82ddeb53 abort + 129
5 xtrabackup 0x0000000101d704e4 _Z27btr_
6 xtrabackup 0x000000010200b103 _ZL17btr_
7 xtrabackup 0x000000010200b706 _Z22row_
8 xtrabackup 0x0000000102029032 _ZL43row_
9 xtrabackup 0x0000000102024ba8 _ZL25row_
10 xtrabackup 0x0000000102023f12 _Z12row_
11 xtrabackup 0x000000010202bb4b _ZL8row_
12 xtrabackup 0x000000010202b79f _Z13row_
13 xtrabackup 0x0000000101f88d2e _ZL12que_
14 xtrabackup 0x0000000101f883aa _ZL19que_
15 xtrabackup 0x0000000101f8810e _Z15que_
16 xtrabackup 0x000000010207b5b6 _ZL19trx_
17 xtrabackup 0x00000001020788e0 _ZL24trx_
18 xtrabackup 0x0000000102078551 _Z31trx_
19 xtrabackup 0x0000000102078a53 trx_rollback_
20 libsystem_
21 libsystem_
22 libsystem_