Crash on page 6
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB | Status tracked in 2.4 | |||||
2.4 |
Fix Released
|
High
|
Sergei Glushchenko |
Bug Description
[FATAL] InnoDB: Apparent corruption of an index page [page id: space=0, page number=6] to be written to data file. We intentionally crash the server to prevent corrupt data from ending up in data files.
2017-03-13 13:01:11 0x7f11067fc700 InnoDB: Assertion failure in thread 139711100208896 in file ut0ut.cc line 916
InnoDB: We intentionally generate a memory trap.
This might be related to
https:/
https:/
but I'm not sure at all about that.
This is identical to what happens on this question:
https:/
This happens for me with:
xtrabackup version 2.4.5 based on MySQL server 5.7.13 Linux (x86_64) (revision id: e41c0be)
MySQL 5.6.35
This instance was probably created with 5.5 or before and upgraded to 5.6.
When I stop writes during the backup (stop slave sql_thread) then the apply-log works
When the apply log works:
InnoDB: Resetting invalid page [page id: space=0, page number=3] type 0 to 6.
InnoDB: Resetting invalid page [page id: space=0, page number=5] type 0 to 7.
InnoDB: Resetting invalid page [page id: space=0, page number=6] type 0 to 6.
InnoDB: Resetting invalid page [page id: space=0, page number=7] type 0 to 6.
When it fails:
InnoDB: Resetting invalid page [page id: space=0, page number=16384] type 17855 to 9 when flushing.
InnoDB: Resetting invalid page [page id: space=0, page number=0] type 0 to 8 when flushing.
InnoDB: Resetting invalid page [page id: space=0, page number=5] type 0 to 7 when flushing.
InnoDB: Resetting invalid page [page id: space=0, page number=32768] type 17855 to 9 when flushing.
Note that the '...when flushing' messages come from the recently patched buf_flush_
buf_dblwr_ assert_ on_corrupt_ block() is what is called on page 6.
So it looks like we *might* have to reset page=6 to FIL_PAGE_TYPE_SYS.