Failed to take full backup -> CORRUPT LOG RECORD FOUND
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB | Status tracked in 2.4 | |||||
2.4 |
Triaged
|
Low
|
Sergei Glushchenko |
Bug Description
Testing same scenario -> https:/
With -> https:/
1. Run python script (altering master key) -> leave running
2. alter table sbtest1 compression='zlib';
3. /usr/local/
Using server version 5.7.11-4
/usr/local/
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /home/sh/
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
InnoDB: Number of pools: 1
InnoDB: Encryption information in the redo log of space 31 is invalid
InnoDB: ############### CORRUPT LOG RECORD FOUND ##################
InnoDB: Log record type 30, page 31:0. Log parsing proceeded successfully up to 186608742. Previous log record type 30, is multi 0 Recv offset 90, prev 0
InnoDB: Hex dump starting 0 bytes before and ending 100 bytes after the corrupted record:
len 190; hex 9e1f00289600536
InnoDB: Set innodb_
160719 15:31:07 >> log scanned up to (186609243)
xtrabackup: Generating a list of tablespaces
Changed in percona-xtrabackup: | |
importance: | High → Medium |
Setting to low because bug is only reproducible in 5.7.11