CORRUPT LOG RECORD FOUND - MySQL 8
Description
Environment
cat /etc/centos-release
CentOS Linux release 7.8.2003 (Core)
*********************************************
root@PlayLogia-35 ~]# mysql --version
mysql Ver 8.0.22 for Linux on x86_64 (MySQL Community Server - GPL)
******************************************************************
[root@PlayLogia-35 ~]# xtrabackup --version
xtrabackup: recognized server arguments: --server-id=35 --open_files_limit=100000 --log_bin --datadir=/var/lib/mysql --innodb_log_files_in_group=2 --innodb_log_file_size=2G --innodb_buffer_pool_size=72G --innodb_read_io_threads=32 --innodb_write_io_threads=32 --innodb_io_capacity=2000 --innodb_flush_method=O_DIRECT --innodb_log_buffer_size=64M --innodb_max_dirty_pages_pct=90 --innodb_file_per_table=1 --innodb_flush_log_at_trx_commit=2 --innodb_open_files=8192
xtrabackup version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
is duplicated by
Activity
Thanks Marcelo . when it will support MySQL 8.0.22 ? or should I downgrade to MySQl 8.0.21
Hi There,
Please check https://www.percona.com/blog/2020/10/23/mysql-new-releases-and-percona-xtrabackup-incompatibilities/
Percona Xtrabackup is still not compatible with MySQL 8.0.22 due to new changes introduced to it.
In your case, you are parsing a log record 65:
/** Extend the space */
MLOG_FILE_EXTEND = 65,
WL#13782: InnoDB: Add dynamic config option to use fallocate() on Linux introduced a new redo log record MLOG_FILE_EXTEND which is written on the file extension and doesn’t depend on –innodb-extend-and-initialize option. Unfortunately this time, the redo log format version is not bumped up. Percona XtraBackup 8.0.14 during backup, cannot parse this new redo log record and so backup fails.
This is the xtrbackup command :
xtrabackup --backup --user=<user> --password=<pass> --parallel=1 --compress --compress-threads=1 --target-dir=/backup/35 2>&1|tee /tmp/backup_20201027.log
Details
Details
Assignee
Reporter
Priority
Medium
Trying to back slave or master getting error :
Not clear which log , record , table is corrupted .
We succeed to run backups on these database several days ago
CORRUPT LOG RECORD FOUND ###############
Log record type 0, page 0:0. Log parsing proceeded successfully up to 31907503319163. Previous log record type 65, is multi 0 Recv offset 9523434, prev 9522632
Hex dump starting 100 bytes before and ending 100 bytes after the corrupted record:
len 1002; hex 0000003200000000000000000000000000000000000000255781da664555528181801f08c075f2c41d97003808ab51b48e26c075f2c41d970002000280058000241a4063653964316537663338316334396361386164363632356236343834643364661fc1c075f200000000010ac00000000000000040000002fbefc059d400380204fbef4b0032c059d402fbef4b0036898b04fbef4b0038c059d402fbef4b003c898b04fbefc059d4098bfbff02fbefc059d4098f0004fbefc059d40991fbff02fbefc059d409950004fbef4b002e0108fbef4b104808ab51b48f08fbefc059d4097108ab51b48f1f02fbee989400380204fbee4b0032989402fbee4b0036863d04fbee4b0038989402fbee4b003c863d04fbee9894063dfbff02fbee989406410004fbee98940643fbff02fbee ....