[MDEV-17410] mariabackup prepare crashes in Innodb recovery Created: 2018-10-09  Updated: 2019-03-26  Resolved: 2019-03-26

Status: Closed
Project: MariaDB Server
Component/s: mariabackup
Affects Version/s: 10.3.5
Fix Version/s: 10.3.7, 10.4.0

Type: Bug Priority: Major
Reporter: Anton Petin Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: mariabackup
Environment:

linux debian

Issue Links:
Duplicate
duplicates MDEV-16168 Performance regression on sysbench wr... Closed

 Description   

When i try to prepare my mariadb backup, mariabackup always crashes

Command which i use to prepare backup

/usr/bin/mariabackup --defaults-file=/etc/mysql/conf.d/myc10.cnf --prepare --user=root -S /tmp/mysql-c10.sock --password=xxxxx  --target-dir /home/db/innobackupex/2018-10-9

Output

/usr/bin/mariabackup based on MariaDB server 10.3.5-MariaDB debian-linux-gnu (x86_64) 
mariabackup: cd to /home/db/innobackupex/2018-10-9/
 
mariabackup: This target seems to be not prepared yet.
 
mariabackup: using the following InnoDB configuration for recovery:
 
mariabackup:   innodb_data_home_dir = .
 
mariabackup:   innodb_data_file_path = ibdata1:12M:autoextend
 
mariabackup:   innodb_log_group_home_dir = .
 
mariabackup: Starting InnoDB instance for recovery.
 
mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
 
2018-10-09 12:20:59 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
 
2018-10-09 12:20:59 0 [Note] InnoDB: Uses event mutexes
 
2018-10-09 12:20:59 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
 
2018-10-09 12:20:59 0 [Note] InnoDB: Number of pools: 1
 
2018-10-09 12:20:59 0 [Note] InnoDB: Using SSE2 crc32 instructions
 
2018-10-09 12:20:59 0 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
 
2018-10-09 12:20:59 0 [Note] InnoDB: Completed initialization of buffer pool
 
2018-10-09 12:20:59 0 [Note] InnoDB: page_cleaner coordinator priority: -20
 
2018-10-09 12:20:59 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1649373448507
 
2018-10-09 12:20:59 0 [ERROR] InnoDB: ############### CORRUPT LOG RECORD FOUND ##################
 
2018-10-09 12:20:59 0 [Note] InnoDB: Log record type 22, page 0:311333. Log parsing proceeded successfully up to 1649171817589. Previous log record type 4, is multi 1 Recv offset 635, prev 627
 
2018-10-09 12:20:59 0 [Note] InnoDB: Hex dump starting 100 bytes before and ending 100 bytes after the corrupted record:
 
 len 208; hex 62f0ffffffff0400c640162966f0ffffffff0400c64016296af0ffffffff0400c64016296ef0ffffffff0100c4c00000b780fa040000003a812c3b00c4c0250400c6401628f2c4c0250200c4c0250018060200c4c0250044a8b20400c4c0250040c640160400c4c025003c001600c4c025000200c4c025002a560200c4c025003a000400c4c0250046000400c4c025004af0ffffffff0200c4c025004e000400c4c0250050f0ffffffff0200c4c0250054000400c4c025004ac4c0250200c4c025004e2c0400c4c0250050c4c0250200; asc b        @ )f        @ )j        @ )n                  : ,;   %   @ (   %    %       % D      % @ @     % <     %     % *V    % :     % F     % J         % N     % P         % T     % J  %    % N,    % P  %  ;
 
2018-10-09 12:20:59 0 [Note] InnoDB: Set innodb_force_recovery to ignore this error.
 
2018-10-09 12:20:59 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
 
mariabackup: innodb_init() returned 11 (Generic error).
 
181009 12:20:59 completed OK!



 Comments   
Comment by Marko Mäkelä [ 2018-10-09 ]

MariaDB Server 10.3.5 is rather old, but nevertheless already 10.3.4 should support the redo log record type 22, which was restored in MDEV-14848.

Comment by Vladislav Vaintroub [ 2018-10-09 ]

antonp1976, just a small remark, you do not need user and password for --prepare. You not connect to the database.

Passing the baton to Innodb recovery expert marko

I also suggest to retry with most recent 10.3 . You have a pre-GA version, where anything can happen. The first GA was 10.3.7

Comment by Marko Mäkelä [ 2019-03-26 ]

The hex dump suggests that the corrupted record is 0x1600c4c02500.
This decodes to the following:
0x16 = MLOG_UNDO_INIT
0x00 = mach_write_compressed(0)
0xc4c025 = mach_write_compressed(311333)
00 = type(0)
This looks valid to me. This record is preceded by two valid MLOG_4BYTES records that are writing to the same page.
In MariaDB 10.3.5, there was an error in the parsing, which was corrected in MDEV-16168 (MariaDB 10.3.7):

        } else if (type != 1 && type != 2) {
 
                recv_sys->found_corrupt_log = true;

Since the bug fix, all types 0, 1, 2 are allowed.

Generated at Thu Feb 08 08:36:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.