0

My Percona 5.7.11-4 crashed without cause. Now I can run only with innodb force recovery = 4. Here is backtrace from log. Can you help? Thank you.

> Thread pointer: 0x0 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 = 0
> thread_stack 0x40000
> /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xec0a9c]
> /usr/sbin/mysqld(handle_fatal_signal+0x461)[0x79b8c1]
> /lib64/libpthread.so.0[0x3b47c0f7e0]
> /lib64/libc.so.6(gsignal+0x35)[0x3b47832625]
> /lib64/libc.so.6(abort+0x175)[0x3b47833e05] /usr/sbin/mysqld[0x76a54c]
> /usr/sbin/mysqld(_Z32page_cur_search_with_match_bytesPK11buf_block_tPK12dict_index_tPK8dtuple_t15page_cur_mode_tPmS9_S9_S9_P10page_cur_t+0x969)[0xf7ff69]
> /usr/sbin/mysqld(_Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t+0x97d)[0x10a6cfd]
> /usr/sbin/mysqld(_Z30btr_pcur_open_on_user_rec_funcP12dict_index_tPK8dtuple_t15page_cur_mode_tmP10btr_pcur_tPKcmP5mtr_t+0x96)[0x10b00c6]
> /usr/sbin/mysqld[0x111bbda]
> /usr/sbin/mysqld(_Z39dict_check_tablespaces_and_store_max_idb+0xa29)[0x111d499]
> /usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x45f3)[0x1034253]
> /usr/sbin/mysqld[0xef89b8]
> /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x7fa171]
> /usr/sbin/mysqld[0xcc5566]
> /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x600)[0xccc430]
> /usr/sbin/mysqld[0x79439d]
> /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x62a)[0x7957da]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3b4781ed5d]
> /usr/sbin/mysqld[0x78b575] You may download the Percona Server
> operations manual by visiting
> http://www.percona.com/software/percona-server/. You may find
> information in the manual which will help you identify the cause of
> the crash. 2016-05-18T19:53:28.676862Z mysqld_safe mysqld from pid
> file /var/run/mysqld/mysqld.pid ended
Pavel
  • 417
  • 1
  • 7
  • 17

1 Answers1

1

My help involves pointing you at the relevant documentation. You should read it carefully and be aware of the purpose of innodb force recovery.

In particular

If you are able to dump your tables with an innodb_force_recovery value of 3 or less, then you are relatively safe that only some data on corrupt individual pages is lost. A value of 4 or greater is considered dangerous because data files can be permanently corrupted.

is relevant. As is

Only set innodb_force_recovery to a value greater than 0 in an emergency situation, so that you can start InnoDB and dump your tables. Before doing so, ensure that you have a backup copy of your database in case you need to recreate it.

Once you've done that you should start your database server and then do nothing else but dump all the databases.

Now you can drop the relevant databases/tables and recover them from your dumps.

user9517
  • 115,471
  • 20
  • 215
  • 297
  • Thank you. I react late, but steps - with force recovery 0+, and export and reinstall to new instance was OK. Databases was rescued. Thanks. – Pavel Jun 20 '16 at 14:32