- I have created backup of sysbench database during OLTP_RW workload
./innobackupex --ibbackup=./src/xtrabackup_55 /backup --compact
- I have started apply-log & rebuild-indexes
./innobackupex --ibbackup=./src/xtrabackup_55 --apply-log --rebuild-indexes --use-memory=10G /backup/.../
- I got a crash:
121227 21:55:37 InnoDB: Warning: allocated tablespace 10, old maximum was 9
Expanding ./sbtest16t5M/sbtest1.ibd
Expanding ./sbtest16t5M/sbtest2.ibd
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 67207168
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 10737418240 bytes for buffer pool (set by --use-memory parameter)
121227 21:56:16 InnoDB: The InnoDB memory heap is disabled
121227 21:56:16 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121227 21:56:16 InnoDB: Compressed tables use zlib 1.2.3
121227 21:56:16 InnoDB: Initializing buffer pool, size = 10.0G
121227 21:56:17 InnoDB: Completed initialization of buffer pool
121227 21:56:17 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 24227725102
121227 21:56:17 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 24232967680 (8 %)
InnoDB: Doing recovery: scanned up to log sequence number 24238210560 (17 %)
InnoDB: Doing recovery: scanned up to log sequence number 24243453440 (26 %)
InnoDB: Doing recovery: scanned up to log sequence number 24248696320 (35 %)
InnoDB: Doing recovery: scanned up to log sequence number 24253939200 (43 %)
InnoDB: Doing recovery: scanned up to log sequence number 24259182080 (52 %)
InnoDB: Doing recovery: scanned up to log sequence number 24264424960 (61 %)
InnoDB: Doing recovery: scanned up to log sequence number 24269667840 (70 %)
InnoDB: Doing recovery: scanned up to log sequence number 24274910720 (78 %)
InnoDB: Doing recovery: scanned up to log sequence number 24280153600 (87 %)
InnoDB: Doing recovery: scanned up to log sequence number 24285396480 (96 %)
InnoDB: Doing recovery: scanned up to log sequence number 24287470095 (100 %)
InnoDB: 57 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 95 row operations to undo
InnoDB: Trx id counter is 33A00
121227 21:56:20 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Starting in background the rollback of uncommitted transactions
121227 21:56:33 InnoDB: Rolling back trx with id 337A0, 1 rows to undo
121227 21:56:33 InnoDB: Waiting for the background threads to start
121227 21:56:33 InnoDB: Assertion failure in thread 140605271824128 in file buf0buf.c line 3965
InnoDB: Failing assertion: recv_sys->n_addrs
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
NOTE: this bug was only ever in the compact-backups branch, and before it was merged into trunk.