[MDEV-19916] Corruption after instant ADD/DROP and shrinking the index tree - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: 10.3.2, 10.4.0
Fix Version/s: 10.3.17, 10.4.7
Component/s: Storage Engine - InnoDB
Labels:
- corruption
- instant

Description

A wrong condition in the function btr_lift_page_up() causes a table to remain wrongly reset to "no instant ALTER was performed" state in any operation that involves reducing the B-tree height (such as UPDATE, DELETE, or purge of history):

diff --git a/storage/innobase/btr/btr0btr.cc b/storage/innobase/btr/btr0btr.cc

--- a/storage/innobase/btr/btr0btr.cc

+++ b/storage/innobase/btr/btr0btr.cc

@@ -3453,7 +3453,8 @@ btr_lift_page_up(

 	/* btr_page_empty() is supposed to zero-initialize the field. */

 	ut_ad(!page_get_instant(father_block->frame));

-	if (page_level == 0 && index->is_instant()) {

+	if (index->is_instant()

+	    && father_block->page.id.page_no() == root_page_no) {

 		ut_ad(!father_page_zip);

 		byte* page_type = father_block->frame + FIL_PAGE_TYPE;

 		ut_ad(mach_read_from_2(page_type) == FIL_PAGE_INDEX);

The problem can be repeated with a table whose clustered index consists of at least 2 levels of node pointer pages above the leaf level. The corruption would be noticed after the table is loaded to the InnoDB data dictionary cache (such as after server restart). Here is a test case with debug injection:

diff --git a/mysql-test/suite/innodb/t/instant_alter_debug.test b/mysql-test/suite/innodb/t/instant_alter_debug.test

index e54623b9cbd..1e2dbcd98bb 100644

--- a/mysql-test/suite/innodb/t/instant_alter_debug.test

+++ b/mysql-test/suite/innodb/t/instant_alter_debug.test

@@ -267,4 +267,26 @@ SET DEBUG_SYNC = RESET;

 SELECT * FROM t1;

 DROP TABLE t1;

+CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;

+# Create a tree with 2 levels of node pointers.

+SET @old_limit = @@innodb_limit_optimistic_insert_debug;

+SET GLOBAL innodb_limit_optimistic_insert_debug = 2;

+INSERT INTO t1 VALUES (1),(5),(4),(3),(2);

+SET GLOBAL innodb_limit_optimistic_insert_debug = @old_limit;

+ALTER TABLE t1 ADD COLUMN b INT, ALGORITHM=INSTANT;

+SET @old_defragment = @@innodb_defragment;

+SET GLOBAL innodb_defragment = 1;

+OPTIMIZE TABLE t1;

+SET GLOBAL innodb_defragment = @old_defragment;

+# Exploit MDEV-17468 to force the table definition to be reloaded

+ALTER TABLE t1 ADD vb INT AS (b) VIRTUAL;

+CHECK TABLE t1;

+SELECT * FROM t1;

+DROP TABLE t1;

 SET GLOBAL innodb_purge_rseg_truncate_frequency = @save_frequency;

It would crash at the second ALTER TABLE:

10.3 9053047f3db37a174f6c1333acf189b6558c50c4
mysqld: /mariadb/10.3/storage/innobase/rem/rem0rec.cc:322: void rec_init_offsets_comp_ordinary(const rec_t , const dict_index_t , ulint , ulint, const dict_col_t::def_t , rec_leaf_format): Assertion `index->is_instant()' failed.
…
#7 0x000055ba28037d8d in rec_init_offsets_comp_ordinary (rec=0x7f4a2fb840ab "\200", index=0x7f49d4046838, offsets=<optimized out>, n_core=4, def_val=0x0, format=REC_LEAF_COLUMNS_ADDED) at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:322
#8 0x000055ba2803466e in rec_init_offsets (rec=<optimized out>, index=<optimized out>, offsets=0x7f49d40a8e20, leaf=<optimized out>) at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:603
#9 rec_get_offsets_func (rec=0x7f4a2fb840ab "\200", index=0x7f49d4046838, offsets=0x7f49d40a8e20, leaf=<optimized out>, n_fields=<optimized out>, file=<optimized out>, line=6706, heap=0x7f4a2f102640) at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:864
#10 0x000055ba28171ae8 in btr_estimate_number_of_different_key_vals (index=0x7f49d4046838) at /mariadb/10.3/storage/innobase/btr/btr0cur.cc:6704
#11 0x000055ba28212ee8 in dict_stats_update_transient_for_index (index=0x7f49d4046838) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:890
#12 0x000055ba28213261 in dict_stats_update_transient (table=<optimized out>) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:948
#13 dict_stats_update (table=0x7f49d4045628, stats_upd_option=<optimized out>) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:3359
#14 0x000055ba27f3fae3 in ha_innobase::open (this=0x7f49d41becb0, name=0x7f49d409edf8 "./test/t1") at /mariadb/10.3/storage/innobase/handler/ha_innodb.cc:6154
#15 0x000055ba27d8180e in handler::ha_open (this=0x7f49d41becb0, table_arg=0x7f49d41d4438, name=0x7f49d409edf8 "./test/t1", mode=2, test_if_locked=18, mem_root=0x0, partitions_to_open=0x0) at /mariadb/10.3/sql/handler.cc:2760
#16 0x000055ba27c22d92 in open_table_from_share (thd=0x7f49d4000cf8, share=0x7f49d409e8c0, alias=<optimized out>, db_stat=33, prgflag=<optimized out>, ha_open_flags=0, outparam=0x7f49d41d4438, is_create_table=<optimized out>, partitions_to_open=0x0) at /mariadb/10.3/sql/table.cc:3506
#17 0x000055ba27ae0d04 in open_table (thd=<optimized out>, table_list=<optimized out>, ot_ctx=0x7f4a2f105250) at /mariadb/10.3/sql/sql_base.cc:1979
#18 0x000055ba27bfe223 in mysql_inplace_alter_table (thd=<optimized out>, table_list=0x7f49d4011de0, table=0x0, altered_table=<optimized out>, ha_alter_info=<optimized out>, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=<optimized out>, alter_ctx=<optimized out>) at /mariadb/10.3/sql/sql_table.cc:7631
#19 mysql_alter_table (thd=<optimized out>, new_db=<optimized out>, new_name=<optimized out>, create_info=<optimized out>, table_list=0x7f49d4011de0, alter_info=<optimized out>, order_num=<optimized out>, order=<optimized out>, ignore=<optimized out>) at /mariadb/10.3/sql/sql_table.cc:9797
#20 0x000055ba27c5f320 in Sql_cmd_alter_table::execute (this=<optimized out>, thd=0x7f49d4000cf8) at /mariadb/10.3/sql/sql_alter.cc:500
#21 0x000055ba27b5068f in mysql_execute_command (thd=0x7f49d4000cf8) at /mariadb/10.3/sql/sql_parse.cc:6023
#22 0x000055ba27b4d183 in mysql_parse (thd=0x7f49d4000cf8, rawbuf=0x7f49d4011ce0 "ALTER TABLE t1 ADD vb INT AS (b) VIRTUAL", length=<optimized out>, parser_state=0x7f4a2f1076a0, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /mariadb/10.3/sql/sql_parse.cc:7829

Attachments

Issue Links

is caused by

MDEV-11369 Instant add column for InnoDB

Closed

is duplicated by

MDEV-19743 Crash while reorganizing an index page

Closed

MDEV-19783 Random crashes and corrupt data in INSTANT-added columns

Closed

MDEV-20198 Instant ALTER TABLE is not crash-safe

Closed

MDEV-21075 Corruption in the undo log that is triggered during a purge operation.

Closed

MDEV-24543 corruption in the InnoDB tablespace

Closed

MDEV-25788 server random Crash

Closed

MDEV-30331 MariaDB-Crashed with error message (mysqld got signal 6, mysqld got signal 11)

Closed

relates to

MDEV-20413 Mariadb Galera Cluster Crash and won't restart

Closed

MDEV-21251 CHECK TABLE fails to check info_bits of records

Closed

MDEV-18519 0x7f0118195700 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.3.7/storage/innobase/btr/btr0cur.cc line 4308

Closed

MDEV-19783 Random crashes and corrupt data in INSTANT-added columns

Closed

MDEV-20590 Introduce a file format constraint to ALTER TABLE

Closed

MDEV-24108 Our server crashed and there was no possibility to restart it

Closed

(3 is duplicated by, 6 relates to)

Activity

Ascending order - Click to sort in descending order

Marko Mäkelä created issue - 2019-07-01 15:11

Marko Mäkelä made changes - 2019-07-01 15:11

Field	Original Value	New Value
Link		This issue is caused by ~~MDEV-11369~~ [ ~~MDEV-11369~~ ]

Marko Mäkelä made changes - 2019-07-01 15:36

issue.field.resolutiondate

2019-07-01 15:36:04.0

2019-07-01 15:36:04.549

Marko Mäkelä made changes - 2019-07-01 15:36

Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Marko Mäkelä made changes - 2019-11-12 09:54

Link

This issue relates to ~~MDEV-19783~~ [ ~~MDEV-19783~~ ]

Marko Mäkelä made changes - 2019-11-12 09:59

Link

This issue relates to ~~MDEV-18519~~ [ ~~MDEV-18519~~ ]

Marko Mäkelä made changes - 2019-11-12 10:04

Link

This issue relates to ~~MDEV-19743~~ [ ~~MDEV-19743~~ ]

Marko Mäkelä made changes - 2019-11-12 10:38

Link

This issue relates to ~~MDEV-20590~~ [ ~~MDEV-20590~~ ]

Marko Mäkelä made changes - 2019-11-15 11:54

Link

This issue is duplicated by ~~MDEV-19783~~ [ ~~MDEV-19783~~ ]

Marko Mäkelä made changes - 2019-11-15 11:56

Link

This issue is duplicated by ~~MDEV-19743~~ [ ~~MDEV-19743~~ ]

Marko Mäkelä made changes - 2019-11-15 11:57

Link

This issue relates to ~~MDEV-19743~~ [ ~~MDEV-19743~~ ]

Marko Mäkelä made changes - 2019-11-15 12:00

Link

This issue relates to ~~MDEV-20413~~ [ ~~MDEV-20413~~ ]

Marko Mäkelä made changes - 2019-11-26 09:38

Link

This issue is duplicated by ~~MDEV-20198~~ [ ~~MDEV-20198~~ ]

Marko Mäkelä made changes - 2019-12-09 06:25

Link

This issue relates to ~~MDEV-21251~~ [ ~~MDEV-21251~~ ]

Marko Mäkelä added a comment - 2019-12-09 06:26

For the record, I wanted to see what exactly happens if a table that was corrupted due to this bug is being accessed in a newer version. In order to catch ~~MDEV-19783~~ (before realizing that it is a duplicate of this bug), we added some consistency checks.

I built a debug version of MariaDB 10.3.16 (the last release before this fix) and ran the following (adapted from innodb.instant_alter_debug:

--source include/have_innodb.inc

--source include/have_debug.inc

--echo #

--echo # MDEV-19916 Corruption after instant ADD/DROP and shrinking the tree

--echo #

CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;

# Create an index tree with 2 levels of node pointer pages.

SET @old_limit = @@innodb_limit_optimistic_insert_debug;

SET GLOBAL innodb_limit_optimistic_insert_debug = 2;

INSERT INTO t1 VALUES (1),(5),(4),(3),(2);

SET GLOBAL innodb_limit_optimistic_insert_debug = @old_limit;

ALTER TABLE t1 ADD COLUMN b INT, ALGORITHM=INSTANT;

SET GLOBAL innodb_defragment = 1;

OPTIMIZE TABLE t1;

--source include/restart_mysqld.inc

# restart with a newer MariaDB 10.3

CHECK TABLE t1;

DROP TABLE t1;

After the mariadb-10.3.16 server was shut down, I started up a different one, and immediately got a debug assertion failure in purge, before the CHECK TABLE statement could be executed:

10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82
mysqld: /mariadb/10.3/storage/innobase/include/rem0rec.h:791: bool rec_is_metadata(const rec_t , const dict_index_t ): Assertion `!is \|\| index->is_instant()' failed.
…
#4 0x0000555555f9c9f0 in rec_is_metadata (rec=0x7ffff0bb00ab "\200",
index=0x7fffc40219b8)
at /mariadb/10.3/storage/innobase/include/rem0rec.h:791
#5 0x000055555602a21e in page_cur_search_with_match_bytes (
block=<optimized out>, index=<optimized out>, tuple=<optimized out>,
mode=<optimized out>, iup_matched_fields=<optimized out>,
iup_matched_bytes=<optimized out>, ilow_matched_fields=<optimized out>,
ilow_matched_bytes=<optimized out>, cursor=<optimized out>)
at /mariadb/10.3/storage/innobase/page/page0cur.cc:735
#6 0x00005555561e3729 in btr_cur_search_to_nth_level_func (
index=<optimized out>, level=<optimized out>, tuple=<optimized out>,
mode=<optimized out>, latch_mode=<optimized out>, cursor=<optimized out>,
ahi_latch=0x0,
file=0x5555567279b5 "/mariadb/10.3/storage/innobase/row/row0row.cc",
line=1052, mtr=0x7fffdcff8200, autoinc=0)
at /mariadb/10.3/storage/innobase/btr/btr0cur.cc:1837
#7 0x00005555561051b7 in btr_pcur_open_low (index=0x7fffc40219b8, level=0,
tuple=0x7fffc4015140, mode=PAGE_CUR_LE, latch_mode=<optimized out>,
cursor=0x555557b3eea0, file=0x0, line=1052, autoinc=0, mtr=0x7fffdcff8200)
at /mariadb/10.3/storage/innobase/include/btr0pcur.ic:441
#8 0x0000555556103b83 in row_search_on_row_ref (pcur=0x555557b3eea0, mode=2,
table=0x7fffc401f9c8, ref=0x7fffc4015140, mtr=0x7fffdcff8200)
at /mariadb/10.3/storage/innobase/row/row0row.cc:1052
#9 0x00005555560f3bdb in row_purge_reposition_pcur (mode=2,
node=0x555557b3edf8, mtr=0x7fffdcff8200)
at /mariadb/10.3/storage/innobase/row/row0purge.cc:79
#10 0x00005555560f708c in row_purge_reset_trx_id (node=0x555557b3edf8,
mtr=0x7fffdcff8200) at /mariadb/10.3/storage/innobase/row/row0purge.cc:796
#11 0x00005555560f4f14 in row_purge_record_func (node=<optimized out>,
undo_rec=<optimized out>, thr=0x555557b3ed38,
updated_extern=<optimized out>)
at /mariadb/10.3/storage/innobase/row/row0purge.cc:1210
#12 row_purge (node=<optimized out>, undo_rec=<optimized out>,
thr=<optimized out>)
at /mariadb/10.3/storage/innobase/row/row0purge.cc:1259
#13 row_purge_step (thr=<optimized out>)
at /mariadb/10.3/storage/innobase/row/row0purge.cc:1338

Let us try with innodb_force_recovery=2 instead, so that the purge will be disabled:

10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82
mysqld: /mariadb/10.3/storage/innobase/rem/rem0rec.cc:603: void rec_init_offsets(const rec_t , const dict_index_t , bool, ulint *): Assertion `index->is_instant()' failed.
…
#4 0x000055555607956a in rec_init_offsets (rec=0x7ffff0bb00ab "\200",
index=0x7fffbc13e0d8, leaf=true, offsets=0x7fffbc13dbf0)
at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:603
#5 rec_get_offsets_func (rec=0x7ffff0bb00ab "\200", index=<optimized out>,
offsets=0x7fffbc13dbf0, leaf=true, n_fields=<optimized out>,
file=<optimized out>, line=6701, heap=0x7ffff03b10d8)
at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:869
#6 0x0000555556203a39 in btr_estimate_number_of_different_key_vals (
index=0x7fffbc13e0d8) at /mariadb/10.3/storage/innobase/btr/btr0cur.cc:6699
#7 0x00005555562c3ec2 in dict_stats_update_transient_for_index (
index=0x7fffbc13e0d8)
at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:888
#8 0x00005555562c4241 in dict_stats_update_transient (table=0x7fffbc13ccc8)
at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:946
#9 dict_stats_update (table=0x7fffbc13ccc8, stats_upd_option=<optimized out>)
at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:3352
#10 0x0000555555f4971f in dict_stats_init (table=0x7fffbc13ccc8)
at /mariadb/10.3/storage/innobase/include/dict0stats.ic:165
#11 ha_innobase::open (this=0x7fffbc13c520, name=0x7fffbc13f948 "./test/t1")
at /mariadb/10.3/storage/innobase/handler/ha_innodb.cc:6145
#12 0x0000555555d734db in handler::ha_open (this=0x7fffbc13c520,
table_arg=0x7fffbc13b948, name=0x7fffbc13f948 "./test/t1", mode=2,
test_if_locked=50, mem_root=0x0, partitions_to_open=0x0)
at /mariadb/10.3/sql/handler.cc:2760

This crash occurs at the very start of the CHECK TABLE statement, when attempting to open the table for executing any SQL statement on it. Let us retry once more with a non-debug version of the server, without innodb_force_recovery. It will note the corruption without crashing:

10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82
test.t1 check Warning InnoDB: The B-tree of index PRIMARY is corrupted.
test.t1 check error Corrupt

In the server error log, there is some more detail:

10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82
2019-12-09 8:13:03 4 [ERROR] InnoDB: Record overlaps another: 107+12
2019-12-09 8:13:03 4 [ERROR] InnoDB: Summed data size 14, returned by func 13
2019-12-09 8:13:03 4 [ERROR] InnoDB: Apparent corruption in space 5 page 3 of index `PRIMARY` of table `test`.`t1`
2019-12-09 8:13:03 4 [ERROR] InnoDB: In page 3 of index `PRIMARY` of table `test`.`t1`, index tree level 1

But, unfortunately there is no message about the existence of the metadata record at the start of the index. I think that the proper place for that would be in btr_validate_level(). I filed ~~MDEV-21251~~ for that omission.

Marko Mäkelä added a comment - 2019-12-09 06:26 For the record, I wanted to see what exactly happens if a table that was corrupted due to this bug is being accessed in a newer version. In order to catch MDEV-19783 (before realizing that it is a duplicate of this bug), we added some consistency checks. I built a debug version of MariaDB 10.3.16 (the last release before this fix) and ran the following (adapted from innodb.instant_alter_debug : --source include/have_innodb.inc --source include/have_debug.inc --echo # --echo # MDEV-19916 Corruption after instant ADD/DROP and shrinking the tree --echo # CREATE TABLE t1 (a INT PRIMARY KEY ) ENGINE=InnoDB; # Create an index tree with 2 levels of node pointer pages. SET @old_limit = @@innodb_limit_optimistic_insert_debug; SET GLOBAL innodb_limit_optimistic_insert_debug = 2; INSERT INTO t1 VALUES (1),(5),(4),(3),(2); SET GLOBAL innodb_limit_optimistic_insert_debug = @old_limit; ALTER TABLE t1 ADD COLUMN b INT , ALGORITHM=INSTANT; SET GLOBAL innodb_defragment = 1; OPTIMIZE TABLE t1; --source include/restart_mysqld.inc # restart with a newer MariaDB 10.3 CHECK TABLE t1; DROP TABLE t1; After the mariadb-10.3.16 server was shut down, I started up a different one, and immediately got a debug assertion failure in purge, before the CHECK TABLE statement could be executed: 10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82 mysqld: /mariadb/10.3/storage/innobase/include/rem0rec.h:791: bool rec_is_metadata(const rec_t *, const dict_index_t *): Assertion `!is || index->is_instant()' failed. … #4 0x0000555555f9c9f0 in rec_is_metadata (rec=0x7ffff0bb00ab "\200", index=0x7fffc40219b8) at /mariadb/10.3/storage/innobase/include/rem0rec.h:791 #5 0x000055555602a21e in page_cur_search_with_match_bytes ( block=<optimized out>, index=<optimized out>, tuple=<optimized out>, mode=<optimized out>, iup_matched_fields=<optimized out>, iup_matched_bytes=<optimized out>, ilow_matched_fields=<optimized out>, ilow_matched_bytes=<optimized out>, cursor=<optimized out>) at /mariadb/10.3/storage/innobase/page/page0cur.cc:735 #6 0x00005555561e3729 in btr_cur_search_to_nth_level_func ( index=<optimized out>, level=<optimized out>, tuple=<optimized out>, mode=<optimized out>, latch_mode=<optimized out>, cursor=<optimized out>, ahi_latch=0x0, file=0x5555567279b5 "/mariadb/10.3/storage/innobase/row/row0row.cc", line=1052, mtr=0x7fffdcff8200, autoinc=0) at /mariadb/10.3/storage/innobase/btr/btr0cur.cc:1837 #7 0x00005555561051b7 in btr_pcur_open_low (index=0x7fffc40219b8, level=0, tuple=0x7fffc4015140, mode=PAGE_CUR_LE, latch_mode=<optimized out>, cursor=0x555557b3eea0, file=0x0, line=1052, autoinc=0, mtr=0x7fffdcff8200) at /mariadb/10.3/storage/innobase/include/btr0pcur.ic:441 #8 0x0000555556103b83 in row_search_on_row_ref (pcur=0x555557b3eea0, mode=2, table=0x7fffc401f9c8, ref=0x7fffc4015140, mtr=0x7fffdcff8200) at /mariadb/10.3/storage/innobase/row/row0row.cc:1052 #9 0x00005555560f3bdb in row_purge_reposition_pcur (mode=2, node=0x555557b3edf8, mtr=0x7fffdcff8200) at /mariadb/10.3/storage/innobase/row/row0purge.cc:79 #10 0x00005555560f708c in row_purge_reset_trx_id (node=0x555557b3edf8, mtr=0x7fffdcff8200) at /mariadb/10.3/storage/innobase/row/row0purge.cc:796 #11 0x00005555560f4f14 in row_purge_record_func (node=<optimized out>, undo_rec=<optimized out>, thr=0x555557b3ed38, updated_extern=<optimized out>) at /mariadb/10.3/storage/innobase/row/row0purge.cc:1210 #12 row_purge (node=<optimized out>, undo_rec=<optimized out>, thr=<optimized out>) at /mariadb/10.3/storage/innobase/row/row0purge.cc:1259 #13 row_purge_step (thr=<optimized out>) at /mariadb/10.3/storage/innobase/row/row0purge.cc:1338 Let us try with innodb_force_recovery=2 instead, so that the purge will be disabled: 10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82 mysqld: /mariadb/10.3/storage/innobase/rem/rem0rec.cc:603: void rec_init_offsets(const rec_t *, const dict_index_t *, bool, ulint *): Assertion `index->is_instant()' failed. … #4 0x000055555607956a in rec_init_offsets (rec=0x7ffff0bb00ab "\200", index=0x7fffbc13e0d8, leaf=true, offsets=0x7fffbc13dbf0) at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:603 #5 rec_get_offsets_func (rec=0x7ffff0bb00ab "\200", index=<optimized out>, offsets=0x7fffbc13dbf0, leaf=true, n_fields=<optimized out>, file=<optimized out>, line=6701, heap=0x7ffff03b10d8) at /mariadb/10.3/storage/innobase/rem/rem0rec.cc:869 #6 0x0000555556203a39 in btr_estimate_number_of_different_key_vals ( index=0x7fffbc13e0d8) at /mariadb/10.3/storage/innobase/btr/btr0cur.cc:6699 #7 0x00005555562c3ec2 in dict_stats_update_transient_for_index ( index=0x7fffbc13e0d8) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:888 #8 0x00005555562c4241 in dict_stats_update_transient (table=0x7fffbc13ccc8) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:946 #9 dict_stats_update (table=0x7fffbc13ccc8, stats_upd_option=<optimized out>) at /mariadb/10.3/storage/innobase/dict/dict0stats.cc:3352 #10 0x0000555555f4971f in dict_stats_init (table=0x7fffbc13ccc8) at /mariadb/10.3/storage/innobase/include/dict0stats.ic:165 #11 ha_innobase::open (this=0x7fffbc13c520, name=0x7fffbc13f948 "./test/t1") at /mariadb/10.3/storage/innobase/handler/ha_innodb.cc:6145 #12 0x0000555555d734db in handler::ha_open (this=0x7fffbc13c520, table_arg=0x7fffbc13b948, name=0x7fffbc13f948 "./test/t1", mode=2, test_if_locked=50, mem_root=0x0, partitions_to_open=0x0) at /mariadb/10.3/sql/handler.cc:2760 This crash occurs at the very start of the CHECK TABLE statement, when attempting to open the table for executing any SQL statement on it. Let us retry once more with a non-debug version of the server, without innodb_force_recovery . It will note the corruption without crashing: 10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82 test.t1 check Warning InnoDB: The B-tree of index PRIMARY is corrupted. test.t1 check error Corrupt In the server error log, there is some more detail: 10.3 e5e5877740f248de848219ee3a1d2881cd5c5b82 2019-12-09 8:13:03 4 [ERROR] InnoDB: Record overlaps another: 107+12 2019-12-09 8:13:03 4 [ERROR] InnoDB: Summed data size 14, returned by func 13 2019-12-09 8:13:03 4 [ERROR] InnoDB: Apparent corruption in space 5 page 3 of index `PRIMARY` of table `test`.`t1` 2019-12-09 8:13:03 4 [ERROR] InnoDB: In page 3 of index `PRIMARY` of table `test`.`t1`, index tree level 1 But, unfortunately there is no message about the existence of the metadata record at the start of the index. I think that the proper place for that would be in btr_validate_level() . I filed MDEV-21251 for that omission.

Marko Mäkelä made changes - 2020-01-03 13:37

Link

This issue is duplicated by ~~MDEV-21075~~ [ ~~MDEV-21075~~ ]

Marko Mäkelä made changes - 2020-11-03 13:32

Link

This issue relates to ~~MDEV-24108~~ [ ~~MDEV-24108~~ ]

Marko Mäkelä made changes - 2021-01-07 07:18

Link

This issue is duplicated by ~~MDEV-24543~~ [ ~~MDEV-24543~~ ]

Marko Mäkelä made changes - 2021-05-27 07:04

Link

This issue is duplicated by ~~MDEV-25788~~ [ ~~MDEV-25788~~ ]

Sergei Golubchik made changes - 2021-12-06 21:49

Workflow

MariaDB v3 [ 97897 ]

MariaDB v4 [ 156420 ]

Marko Mäkelä made changes - 2023-01-03 07:56

Link

This issue is duplicated by ~~MDEV-30331~~ [ ~~MDEV-30331~~ ]

Jira Automation (IT) made changes - 2024-07-04 03:50

Zendesk Related Tickets

187711 119185 110645 118253 151694

People

Assignee:: Marko Mäkelä

Reporter:: Marko Mäkelä

Votes:: 1 Vote for this issue

Watchers:: 6 Start watching this issue

Dates

Created:: 2019-07-01 15:11

Updated:: 2024-07-07 22:47

Resolved:: 2019-07-01 15:36

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration