Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4.25, 10.4.26
-
Gentoo linux 5.18 and newer, AMD EPYC 7451 CPU
Description
The issue appeared after update to 10.4.25.
While running musqldump for backup (recurses over all the databases present in the dataset), mysqld (a member of galera-26.4.12 cluster) started to crash with symptoms like this:
[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=16968115, page number=3268], should be [page id: space=1668204, page number=37092] |
[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=16968115, page number=3268], should be [page id: space=1668204, page number=37092] |
[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=16968115, page number=3268], should be [page id: space=1668204, page number=37092] |
with following
0x7e5748b7d640 InnoDB: Assertion failure in file /var/tmp/portage/dev-db/mariadb-10.4.26/work/mysql/storage/innobase/btr/btr0pcur.cc line 532 |
InnoDB: Failing assertion: btr_page_get_prev(next_page) == btr_pcur_get_block(cursor)->page.id.page_no()
|
InnoDB: We intentionally generate a memory trap.
|
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/ |
and exiting with signal 6.
This doesn't happen on every backup execution: after umping whole dataset successfully for 4-5 times a crash like this happens.
The server has enough free memory to dump the data. Happened on different servers, however, two conditions were the same: mariadb version and running mysqldump execution (backup).
The behavior looks like serious bug. Whole log can be found attached.
Is there any possible workaround for this issue?
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-