InnoDB: Assertion failure in thread 140092789208896 in file log0recv.cc line 2413

Bug #1487328 reported by Sreejith
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
New
Undecided
Unassigned

Bug Description

Was trying to use xtrabackup, faced an issue while Preparing the Base Backup.

Following are the steps followed.

1. Created a full backup

xtrabackup --backup --target-dir=/home/sreejith/base/

2. Created two incremental backups.

xtrabackup --backup --target-dir=/home/sreejith/base/inc/tue/ \--incremental-basedir=/home/sreejith/base/

xtrabackup --backup --target-dir=/home/sreejith/base/inc/wed/ \--incremental-basedir=/home/sreejith/base/

Finally while trying to prepare the base backup, it threw me a signal 6 error.

3. Preparing base backup

xtrabackup --prepare --apply-log-only --target-dir=/home/sreejith/base/

the following error was encountered.

xtrabackup: Transaction log of lsn (3493410093) to (3493410102) was copied.
root@TKSWS20:/home/sreejith# xtrabackup --prepare --apply-log-only --target-dir=/home/sreejith/base/
xtrabackup version 2.2.12 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 8726828)
xtrabackup: cd to /home/sreejith/base/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(3493410093)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3.4
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 3493410093
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 3493410102 (0%)
InnoDB: ############### CORRUPT LOG RECORD FOUND
InnoDB: Log record type 56, space id 0, page number 0
InnoDB: Log parsing proceeded successfully up to 3493410093
InnoDB: Previous log record type 999999, is multi 0
InnoDB: Recv offset 0, prev 0
InnoDB: Hex dump of corrupt log starting 100 bytes before the start
InnoDB: of the previous log rec,
InnoDB: and ending 100 bytes after the start of the corrupt rec:
 len 200; hex 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002102000000000003800000000d039352d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000; asc 8 95- ;
InnoDB: Set innodb_force_recovery to ignore this error.
2015-08-21 11:16:41 7f69e4efb740 InnoDB: Assertion failure in thread 140092789208896 in file log0recv.cc line 2413
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.
05:46:41 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
xtrabackup(my_print_stacktrace+0x24) [0x8ee734]
xtrabackup(handle_fatal_signal+0x254) [0x72fff4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f69e4aedcb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f69e30630d5]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f69e306683b]
xtrabackup() [0x6c05cf]
xtrabackup(recv_scan_log_recs(unsigned long, unsigned long, unsigned char const*, unsigned long, unsigned long, unsigned long*, unsigned long*)+0xa17) [0x6c3a77]
xtrabackup() [0x6c42db]
xtrabackup(recv_recovery_from_checkpoint_start_func(unsigned long, unsigned long, unsigned long, unsigned long)+0x574) [0x6c4874]
xtrabackup(innobase_start_or_create_for_mysql()+0x16d1) [0x5d4851]
xtrabackup(main+0xc7b) [0x58b80b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f69e304e76d]
xtrabackup() [0x59c965]

Sreejith (jithu212)
Changed in percona-xtrabackup:
assignee: nobody → Sreejith (jithu212)
assignee: Sreejith (jithu212) → nobody
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1345

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.