[MDEV-27852] InnoDB: Failing assertion: dict_tf2_is_valid(flags, flags2) Created: 2022-02-15  Updated: 2022-06-27  Resolved: 2022-06-27

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.4.22, 10.5.15
Fix Version/s: 10.3.36, 10.4.26, 10.5.17, 10.6.9, 10.7.5, 10.8.4, 10.9.2, 10.10.1

Type: Bug Priority: Major
Reporter: Manuel Arostegui Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: None
Environment:

debian bullseye

Issue Links:
Duplicate
duplicates MDEV-26577 InnoDB: Failing assertion: dict_tf2_i... Closed
is duplicated by MDEV-28512 InnoDB: Assertion failure in file ./s... Closed

 Description   

This bug is similar than https://jira.mariadb.org/browse/MDEV-22627 but it happens also with an ALTER table.

I am able to reproduce as soon as I try the alter table.

Table:

show create table aawiki.templatelinks\G
 
*************************** 1. row ***************************
 
       Table: templatelinks
 
Create Table: CREATE TABLE `templatelinks` (
 
  `tl_from` int(8) unsigned NOT NULL DEFAULT 0,
 
  `tl_namespace` int(11) NOT NULL DEFAULT 0,
 
  `tl_title` varbinary(255) NOT NULL DEFAULT '',
 
  `tl_from_namespace` int(11) NOT NULL DEFAULT 0,
 
  PRIMARY KEY (`tl_from`,`tl_namespace`,`tl_title`),
 
  KEY `tl_namespace` (`tl_namespace`,`tl_title`,`tl_from`),
 
  KEY `tl_backlinks_namespace` (`tl_from_namespace`,`tl_namespace`,`tl_title`,`tl_from`)
 
) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8

ALTER:

ALTER TABLE templatelinks ADD  tl_target_id BIGINT UNSIGNED DEFAULT NULL

Full trace:

Feb 15 17:01:30 db2074 mysqld[3307939]: 2022-02-15 17:01:30 18 [Note] Slave I/O thread: Start semi-sync replication to master 'repl@db2105.codfw.wmnet:3306' in log 'db2105-bin.004048' at position 4
 
Feb 15 17:01:30 db2074 mysqld[3307939]: 2022-02-15 17:01:30 18 [Note] Slave I/O thread: connected to master 'repl@db2105.codfw.wmnet:3306',replication starts at GTID position '171978787-171978787-3148314508,0-171966669-4075095254,171966669-171966669-4196523483,171966508-1>
 
Feb 15 17:01:35 db2074 mysqld[3307939]: 2022-02-15 17:01:35 0x7f5edc2dd700  InnoDB: Assertion failure in file /root/mariadb-10.4.22/storage/innobase/dict/dict0mem.cc line 152
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: Failing assertion: dict_tf2_is_valid(flags, flags2)
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: We intentionally generate a memory trap.
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: If you get repeated assertion failures or crashes, even
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: immediately after the mysqld startup, there may be
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: corruption in the InnoDB tablespace. Please refer to
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
 
Feb 15 17:01:35 db2074 mysqld[3307939]: InnoDB: about forcing recovery.
 
Feb 15 17:01:35 db2074 mysqld[3307939]: 220215 17:01:35 [ERROR] mysqld got signal 6 ;
 
Feb 15 17:01:35 db2074 mysqld[3307939]: This could be because you hit a bug. It is also possible that this binary
 
Feb 15 17:01:35 db2074 mysqld[3307939]: or one of the libraries it was linked against is corrupt, improperly built,
 
Feb 15 17:01:35 db2074 mysqld[3307939]: or misconfigured. This error can also be caused by malfunctioning hardware.
 
Feb 15 17:01:35 db2074 mysqld[3307939]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
Feb 15 17:01:35 db2074 mysqld[3307939]: We will try our best to scrape up some info that will hopefully help
 
Feb 15 17:01:35 db2074 mysqld[3307939]: diagnose the problem, but since we have already crashed,
 
Feb 15 17:01:35 db2074 mysqld[3307939]: something is definitely wrong and this may fail.
 
Feb 15 17:01:35 db2074 mysqld[3307939]: Server version: 10.4.22-MariaDB-log
 
Feb 15 17:01:35 db2074 mysqld[3307939]: key_buffer_size=134217728
 
Feb 15 17:01:35 db2074 mysqld[3307939]: read_buffer_size=131072
 
Feb 15 17:01:35 db2074 mysqld[3307939]: max_used_connections=5
 
Feb 15 17:01:35 db2074 mysqld[3307939]: max_threads=2010
 
Feb 15 17:01:35 db2074 mysqld[3307939]: thread_count=10
 
Feb 15 17:01:35 db2074 mysqld[3307939]: It is possible that mysqld could use up to
 
Feb 15 17:01:35 db2074 mysqld[3307939]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4753048 K  bytes of memory
 
Feb 15 17:01:35 db2074 mysqld[3307939]: Hope that's ok; if not, decrease some variables in the equation.
 
Feb 15 17:01:35 db2074 mysqld[3307939]: Thread pointer: 0x7efe2c001538
 
Feb 15 17:01:35 db2074 mysqld[3307939]: Attempting backtrace. You can use the following information to find out
 
Feb 15 17:01:35 db2074 mysqld[3307939]: where mysqld died. If you see no messages after this, something went
 
Feb 15 17:01:35 db2074 mysqld[3307939]: terribly wrong...
 
Feb 15 17:01:35 db2074 mysqld[3307939]: stack_bottom = 0x7f5edc2dc760 thread_stack 0x30000
 
Feb 15 17:01:35 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(my_print_stacktrace+0x2e)[0x55667bd4fdbe]
 
Feb 15 17:01:35 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(handle_fatal_signal+0x54d)[0x55667b81188d]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f5f359c3140]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f5f3550cce1]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7f5f354f6537]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0x5b967a)[0x55667b4d967a]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0x5cc8c7)[0x55667b4ec8c7]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0xad631f)[0x55667b9f631f]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0xad9f18)[0x55667b9f9f18]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0x7697e8)[0x55667b6897e8]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(_Z17mysql_alter_tableP3THDPK25st_mysql_const_lex_stringS3_P14HA_CREATE_INFOP10TABLE_LISTP10Alter_infojP8st_orderb+0x3e94)[0x55667b696384]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(_ZN19Sql_cmd_alter_table7executeEP3THD+0x347)[0x55667b6ef8b7]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(_Z21mysql_execute_commandP3THD+0x631f)[0x55667b5efe6f]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x223)[0x55667b5f1e13]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(_ZN15Query_log_event14do_apply_eventEP14rpl_group_infoPKcj+0x6e6)[0x55667b925a26]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0x619b04)[0x55667b539b04]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(handle_slave_sql+0x1662)[0x55667b543a22]
 
Feb 15 17:01:36 db2074 mysqld[3307939]: /opt/wmf-mariadb104/bin/mysqld(+0xddf482)[0x55667bcff482]
 
Feb 15 17:01:37 db2074 mysqld[3307939]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7)[0x7f5f359b7ea7]
 
Feb 15 17:01:37 db2074 mysqld[3307939]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f5f355cedef]
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Trying to get some variables.
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Some pointers may be invalid and cause the dump to abort.
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Query (0x7efe2c014eb5): ALTER TABLE templatelinks ADD  tl_target_id BIGINT UNSIGNED DEFAULT NULL
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Connection ID (thread ID): 19
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Status: NOT_KILLED
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_ke>
 
Feb 15 17:01:37 db2074 mysqld[3307939]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
 
Feb 15 17:01:37 db2074 mysqld[3307939]: information that should help you find out what is causing the crash.
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Writing a core file...
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Working directory at /srv/sqldata
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Resource Limits:
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Limit                     Soft Limit           Hard Limit           Units
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max cpu time              unlimited            unlimited            seconds
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max file size             unlimited            unlimited            bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max data size             unlimited            unlimited            bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max stack size            8388608              unlimited            bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max core file size        0                    0                    bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max resident set          unlimited            unlimited            bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max processes             2063462              2063462              processes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max open files            200001               200001               files
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max locked memory         65536                65536                bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max address space         unlimited            unlimited            bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max file locks            unlimited            unlimited            locks
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max pending signals       2063462              2063462              signals
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max msgqueue size         819200               819200               bytes
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max nice priority         0                    0
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max realtime priority     0                    0
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Max realtime timeout      unlimited            unlimited            us
 
Feb 15 17:01:37 db2074 mysqld[3307939]: Core pattern: /var/tmp/core/core.%h.%e.%p.%t
 
Feb 15 17:01:37 db2074 systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT


mysql:root@localhost [information_schema]> select * from innodb_sys_tables where name like 'aawiki/templatelinks';
 
+----------+----------------------+------+--------+--------+------------+---------------+------------+
 
| TABLE_ID | NAME                 | FLAG | N_COLS | SPACE  | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
 
+----------+----------------------+------+--------+--------+------------+---------------+------------+
 
|   185034 | aawiki/templatelinks |    1 |      7 | 185029 | Compact    |             0 | Single     |
 
+----------+----------------------+------+--------+--------+------------+---------------+------------+
 
1 row in set (0.275 sec)



 Comments   
Comment by Manuel Arostegui [ 2022-02-15 ]

stack trace

(gdb) bt
 
#0  0x00007ffff7683ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 
#1  0x00007ffff766d537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 
#2  0x0000555555b0d67a in ut_dbg_assertion_failed (expr=expr@entry=0x5555565d00d0 "dict_tf2_is_valid(flags, flags2)", file=file@entry=0x5555565d0098 "/root/mariadb-10.4.22/storage/innobase/dict/dict0mem.cc", line=line@entry=152) at /root/mariadb-10.4.22/storage/innobase/ut/ut0dbg.cc:60
 
#3  0x0000555555b208c7 in dict_mem_table_create (name=name@entry=0x7f9efc020e18 "aawiki/#sql-329474_f", space=space@entry=0x0, n_cols=5, n_v_cols=n_v_cols@entry=0, flags=flags@entry=9, flags2=flags2@entry=80) at /root/mariadb-10.4.22/storage/innobase/dict/dict0mem.cc:152
 
#4  0x000055555602a31f in prepare_inplace_alter_table_dict (ha_alter_info=0x7fff9c2e9e30, altered_table=0x7fff9c2e9ed0, old_table=0x7f9efc017e58, table_name=0x7f9efc0156cf "templatelinks", flags=9, flags2=80, fts_doc_id_col=<optimized out>, add_fts_doc_id=<optimized out>, add_fts_doc_id_idx=<optimized out>) at /root/mariadb-10.4.22/storage/innobase/handler/handler0alter.cc:6479
 
#5  0x000055555602df18 in ha_innobase::prepare_inplace_alter_table (this=<optimized out>, altered_table=<optimized out>, ha_alter_info=<optimized out>) at /root/mariadb-10.4.22/storage/innobase/handler/ha_innodb.h:698
 
#6  0x0000555555cbd7e8 in mysql_inplace_alter_table (thd=0x7f9efc001538, table_list=0x7f9efc00c768, table=0x7f9efc017e58, altered_table=0x7fff9c2e9ed0, ha_alter_info=0x7fff9c2e9e30, alter_ctx=0x7fff9c2eb6e0, target_mdl_request=<optimized out>) at /root/mariadb-10.4.22/sql/sql_table.cc:7787
 
#7  0x0000555555cca384 in mysql_alter_table (thd=thd@entry=0x7f9efc001538, new_db=new_db@entry=0x7f9efc005b50, new_name=new_name@entry=0x7f9efc005f78, create_info=create_info@entry=0x7fff9c2ec2d0, table_list=<optimized out>, table_list@entry=0x7f9efc00c768, alter_info=alter_info@entry=0x7fff9c2ec210, order_num=0, order=0x0, ignore=false) at /root/mariadb-10.4.22/sql/sql_table.cc:10253
 
#8  0x0000555555d238b7 in Sql_cmd_alter_table::execute (this=<optimized out>, thd=0x7f9efc001538) at /root/mariadb-10.4.22/sql/sql_alter.cc:520
 
#9  0x0000555555c23e6f in mysql_execute_command (thd=0x7f9efc001538) at /root/mariadb-10.4.22/sql/sql_parse.cc:6192
 
#10 0x0000555555c25e13 in mysql_parse (thd=0x7f9efc001538, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7fff9c2ee430, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /root/mariadb-10.4.22/sql/sql_parse.cc:7995
 
#11 0x0000555555f59a26 in Query_log_event::do_apply_event (this=0x7f9efc014b08, rgi=0x7f9efc000c40, query_arg=0x7f9efc014c45 "ALTER TABLE templatelinks ADD  tl_target_id BIGINT UNSIGNED DEFAULT NULL", q_len_arg=<optimized out>) at /root/mariadb-10.4.22/sql/sql_class.h:221
 
#12 0x0000555555b6db04 in Log_event::apply_event (rgi=0x7f9efc000c40, this=<optimized out>) at /root/mariadb-10.4.22/sql/log_event.h:1492
 
#13 apply_event_and_update_pos_apply (ev=ev@entry=0x7f9efc014b08, thd=thd@entry=0x7f9efc001538, rgi=rgi@entry=0x7f9efc000c40, reason=<optimized out>) at /root/mariadb-10.4.22/sql/slave.cc:3807
 
#14 0x0000555555b75d23 in apply_event_and_update_pos (ev=ev@entry=0x7f9efc014b08, thd=thd@entry=0x7f9efc001538, rgi=rgi@entry=0x7f9efc000c40) at /root/mariadb-10.4.22/sql/slave.cc:3969
 
#15 0x0000555555b77a22 in exec_relay_log_event (serial_rgi=0x7f9efc000c40, rli=0x555742283e68, thd=0x7f9efc001538) at /root/mariadb-10.4.22/sql/slave.cc:4288
 
#16 handle_slave_sql (arg=arg@entry=0x5557422824a0) at /root/mariadb-10.4.22/sql/slave.cc:5462
 
#17 0x0000555556333482 in pfs_spawn_thread (arg=0x7f9f2c011938) at /root/mariadb-10.4.22/storage/perfschema/pfs.cc:1869
 
#18 0x00007ffff7b2eea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
 
#19 0x00007ffff7745def in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Manuel Arostegui [ 2022-02-15 ]

More gbd:

(gdb) print *user_table
 
$1 = {id = 185034, id_hash = 0x0, name = {m_name = 0x7f9f0c013a10 "aawiki/templatelinks", static part_suffix = "#P#"}, name_hash = 0x0, heap = 0x7f9f0c016ce0, data_dir_path = 0x0, space = 0x55573db615e0, space_id = 185029, flags = 1, flags2 = 80, skip_alter_undo = 0, file_unreadable = 0, cached = 1, to_be_dropped = 0, n_def = 7, n_cols = 7, n_t_cols = 7, n_t_def = 7, n_v_def = 0, n_v_cols = 0, persistent_autoinc = 0, can_be_evicted = 1, corrupted = 0, drop_aborted = 0, cols = 0x7f9f0c01a1b8, v_cols = 0x7f9f0c01a298, s_cols = 0x0, instant = 0x0, col_names = 0x7f9f0c01a2f0 "tl_from", v_col_names = 0x0, vers_start = 0, vers_end = 0, is_system_db = false, dict_frm_mismatch = DICT_FRM_CONSISTENT, fts_doc_id_index = 0x0, indexes = {count = 3, start = 0x7f9f0c01afe8, end = 0x7f9f0c023fa8, node = &dict_index_t::indexes}, freed_indexes = {count = 0, start = 0x0, end = 0x0, node = &dict_index_t::indexes}, foreign_list = {count = 0, start = 0x0, end = 0x0, node = &dict_foreign_t::heap}, referenced_list = {count = 0, start = 0x0, end = 0x0, node = &dict_foreign_t::heap}, table_LRU = {prev = 0x7f9f4800da78, next = 0x7f9f24007878}, fk_max_recusive_level = 0, n_foreign_key_checks_running = {m_counter = {<std::__atomic_base<int>> = {static _S_alignment = 4, _M_i = 0}, <No data fields>}}, query_cache_inv_trx_id = 0, def_trx_id = 0, foreign_set = std::set with 0 elements, referenced_set = std::set with 0 elements, stat_initialized = 1, stats_last_recalc = 0, stat_persistent = 0, stats_auto_recalc = 0, stats_sample_pages = 0, stat_n_rows = 306, stat_clustered_index_size = 1, stat_sum_of_other_index_sizes = 3, stat_modified_counter = 0, stats_bg_flag = 0 '\000', stats_error_printed = false, autoinc_lock = 0x7f9f0c01a298, autoinc_mutex = {<std::__mutex_base> = {_M_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}, <No data fields>}, autoinc = 0, n_waiting_or_granted_auto_inc_locks = 0, autoinc_trx = 0x0, fts = 0x0, quiesce = QUIESCE_NONE, n_rec_locks = 0, n_ref_count = {m_counter = {<std::__atomic_base<unsigned int>> = {static _S_alignment = 4, _M_i = 1}, <No data fields>}}, locks = {count = 0, start = 0x0, end = 0x0, node = &lock_table_t::locks}, update_time = 0, vc_templ = 0x0}


root@db2074.codfw.wmnet[aawiki]> show create table templatelinks;
 
+---------------+----------------------------------------------------------------------------------------------------------------------
 
| Table         | Create Table
 
+---------------+----------------------------------------------------------------------------------------------------------------------
 
| templatelinks | CREATE TABLE `templatelinks` (
 
  `tl_from` int(8) unsigned NOT NULL DEFAULT 0,
 
  `tl_namespace` int(11) NOT NULL DEFAULT 0,
 
  `tl_title` varbinary(255) NOT NULL DEFAULT '',
 
  `tl_from_namespace` int(11) NOT NULL DEFAULT 0,
 
  PRIMARY KEY (`tl_from`,`tl_namespace`,`tl_title`),
 
  KEY `tl_namespace` (`tl_namespace`,`tl_title`,`tl_from`),
 
  KEY `tl_backlinks_namespace` (`tl_from_namespace`,`tl_namespace`,`tl_title`,`tl_from`)
 
) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8

And the relevant entry from show table status:

 
 
| templatelinks                | InnoDB |      10 | Compact    |   306 |             53 |       16384 |                0 |        49152 |         0 |           NULL | 2022-02-01 08:35:54 | NULL                | NULL                | binary    |     NULL | row_format=COMPRESSED key_block_size=8 |         |                0 | N         |

Comment by Marko Mäkelä [ 2022-02-15 ]

It looks like the problem is a mismatch between the .frm file and the InnoDB data dictionary. InnoDB thinks that the table is in ROW_FORMAT=COMPACT (the default between MySQL 5.0.3 and MySQL 5.7.8), while the .frm file says ROW_FORMAT=COMPRESSED. I think that this table must have been created when the setting innodb_file_format=antelope was in effect, and thus the creation of COMPRESSED or DYNAMIC tables was forbidden. This setting was deprecated and ignored in MySQL 5.7 and MariaDB 10.2.

You should be able to rebuild the table if you specify ALGORITHM=COPY or set old_alter_table=1 (or MDEV-13134 alter_algorithm=copy).

Comment by Manuel Arostegui [ 2022-02-16 ]

marko, first of all thanks a lot for all the live troubleshooting we did last night. Thanks for taking the time to look into this until you find what the issue was and provided a workaround. This was amazing to see and I am so grateful for it.

I can now confirm that I left the workaround running and I have attempted to alter the tables again and replication is flowing normally - the tables are being altered after being rebuilt during the night and I am seeing no more crashes.

It is certainly possible that those tables were created like that, as these hosts and their data are probably more than 10 years old, and went thru several migrations (including from mysql to mariadb).

I have added a bit more details for our specific case in our internal tracking system: https://phabricator.wikimedia.org/T301313#7713692
Not sure what to do with this ticket, so I would leave it up to you how you want to proceed with it - I guess it can be closed if there's nothing to do from MariaDB's side?

Thanks a lot for the time spent yesterday, you were so helpful and dedicated. Much much much appreciated it.

Comment by Marko Mäkelä [ 2022-02-17 ]

Hi marostegui, I think that this is a bug that should be fixable in some way. A simple fix could be to refuse native ALTER TABLE when the ROW_FORMAT in the .frm file disagrees with the InnoDB definition.

It should be possible to create an mtr test case for this, by moving some .frm files around to inject this kind of a fault.

I do not promise anything, though.

Comment by Manuel Arostegui [ 2022-02-21 ]

Thanks marko, if that is fixable or we can have a way to prevent the crashes that'd be great. Thank you!

Comment by Marko Mäkelä [ 2022-06-27 ]

I finally took the time to figure out how to reproduce this, in MDEV-26577. The key part was an ALGORITHM=INSTANT or ALGORITHM=NOCOPY operation such that the .frm file incorrectly claimed the table to be in ROW_FORMAT=COMPRESSED.

Generated at Thu Feb 08 09:56:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.