Mariadb und ein "InnoDB: (Duplicate key) writing word node to FTS auxiliary index table"-Fehler

13. September 2022

Der Morgen begann heute mit Schreckensmeldungen vom Datenbankserver. Dieser startete dauernd neu und konnte sich einfach nicht beruhigen. Fehlermeldungen a la [ERROR] InnoDB: Failed to read page 12 from file './mysql/innodb_index_stats.ibd': Page read from tablespace is corrupted ließen die mysql-error.log auf mehrere Megabyte ansteigen.

Diese Hürde ließ sich durch das temporäre Hinzufügen eines innodb_force_recovery = 1 in den [mysqld]-Bereich der Config überwinden. Vermutlich hätte auch --innodb_force_recovery=1 als temporärer Parameter geholfen. Nähere Informationen zu den einzelnen Recovery-Modes finden sich in der Wissensdatenbank von Mariadb.

Damit fing der Spaß aber auch erst an. Obwohl standardmäßig mysqlcheck mit --auto-repair -A drübergejagt wurde, um etwaige noch existente Fehler zu korrigieren, stürzte Mariadb komplett ab, sobald in einer Datenbank ein Insert erfolgte. Die Fehlerlogdatei erhielt nun Einträge InnoDB: (Duplicate key) writing word node to FTS auxiliary index table mit längeren Crashdumps, die aber nicht wirklich Aufschluss gaben.

Die Fehlermeldung ließ auf einen korrupten Index mit irgendeinem doppelten Eintrag schließen. Da mysqlcheck mit einem Autorepair und auch die Optimierung nicht halfen, riet eine Standardrecherche zu einem Rebuild des bzw. der Indizes. Das sollte mit einem Dump der entsprechenden Datenbank und dem darauffolgenden Import dieses Abbilds erreicht werden.

Also zuerst ein mysqldump datenbank tabellenname > datenbank.sql und dann ein mysql datenbank < datenbank.sql versucht. Das brachte keinen Erfolg. Warum ist unklar. Völlig entnervt dann die zweitbeste Lösung bei der entsprechenden Datenbanktabelle probiert.

ALTER TABLE datenbanktabelle ENGINE=InnoDB;

Und siehe da. Das Problem verschwand. Bleibt nur noch den Auslöser des ersten Crashs zu finden.

In der mysql-error.log fand sich auch so etwas, was aber nicht wirklich weiterhalf:

Server version: 10.6.9-MariaDB-1:10.6.9+maria~deb10-log
key_buffer_size=524288
read_buffer_size=131072
max_used_connections=42
max_threads=202
thread_count=43
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 445299 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f79f0000c18
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f7af4428d98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55c40db8fb0e]
??:0(handle_fatal_signal)[0x55c40d675555]
??:0(__restore_rt)[0x7f7c7fd7f730]
??:0(gsignal)[0x7f7c7f8d67bb]
??:0(abort)[0x7f7c7f8c1535]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55c40d31b3d2]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55c40d3071ca]
??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::_M_realloc_insert<unsigned long>(__gnu_cxx::__normal_iterator<unsigned long*, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x55c40dafebb9]
??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::_M_realloc_insert<unsigned long>(__gnu_cxx::__normal_iterator<unsigned long*, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x55c40daec3ff]
??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::_M_realloc_insert<unsigned long>(__gnu_cxx::__normal_iterator<unsigned long*, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x55c40daf0ba1]
??:0(void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag))[0x55c40d9ea0a3]
??:0(void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag))[0x55c40d9ed307]
??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const*))[0x55c40d95b894]
??:0(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool))[0x55c40d4f5290]
??:0(Sql_cmd_alter_table::execute(THD*))[0x55c40d55aa26]
??:0(mysql_execute_command(THD*, bool))[0x55c40d45b5ae]
??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55c40d44bf32]
??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55c40d456b3a]
??:0(do_command(THD*, bool))[0x55c40d4581f7]
??:0(do_handle_one_connection(CONNECT*, bool))[0x55c40d555d17]
??:0(handle_one_connection)[0x55c40d55605d]
??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x55c40d891b0e]
??:0(start_thread)[0x7f7c7fd74fa3]
??:0(clone)[0x7f7c7f997eff]

Stichworte: Innodb, Linux, Mariadb, Mysql
Kategorien: Linux

Linuxspicker