InnoDBの破損：mysqldのみを起動しますinnodb_force_recovery = 6
私はバージョン10.0.19-MariaDB-1〜trusty-logを使用していて、mysqldをinnodb_force_recovery = 6でのみ再起動できますが、理由はわかりません。
/ usr/sbin/mysqldの出力は次のとおりです。
root@birdwatch:~> /usr/sbin/mysqld
151112 12:49:53 [Note] /usr/sbin/mysqld (mysqld 10.0.19-MariaDB-1~trusty) starting as process 4603 ...
151112 12:49:53 [Note] InnoDB: Using mutexes to ref count buffer pool pagesfile=hey_prova --log-output=FILE
151112 12:49:53 [Note] InnoDB: The InnoDB memory heap is disabled
151112 12:49:53 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
151112 12:49:53 [Note] InnoDB: Memory barrier is not used
151112 12:49:53 [Note] InnoDB: Compressed tables use zlib 1.2.8
151112 12:49:53 [Note] InnoDB: Using Linux native AIO
151112 12:49:53 [Note] InnoDB: Using CPU crc32 instructions
151112 12:49:53 [Note] InnoDB: Initializing buffer pool, size = 256.0M
151112 12:49:53 [Note] InnoDB: Completed initialization of buffer pool
151112 12:49:53 [Note] InnoDB: Highest supported file format is Barracuda.
151112 12:49:53 [Note] InnoDB: Log scan progressed past the checkpoint lsn 3384148
151112 12:49:53 [Note] InnoDB: Database was not shutdown normally!
151112 12:49:53 [Note] InnoDB: Starting crash recovery.
151112 12:49:53 [Note] InnoDB: Reading tablespace information from the .ibd files...
151112 12:49:53 [Note] InnoDB: Restoring possible half-written data pages
151112 12:49:53 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 3391696
151112 12:49:53 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 2015-11-12 12:49:53 7f3df3bfd700 InnoDB: Assertion failure in thread 139904059168512 in file page0cur.cc line 931
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
151112 12:49:53 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.0.19-MariaDB-1~trusty
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=0
max_threads=102
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759757 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7f3e2004562e]
/usr/sbin/mysqld(handle_fatal_signal+0x457)[0x7f3e1fb845e7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f3e1eb8c340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f3e1d9a5cc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f3e1d9a90d8]
/usr/sbin/mysqld(+0x84287f)[0x7f3e1fe5587f]
/usr/sbin/mysqld(+0x827b1c)[0x7f3e1fe3ab1c]
/usr/sbin/mysqld(+0x82994f)[0x7f3e1fe3c94f]
/usr/sbin/mysqld(+0x914b0c)[0x7f3e1ff27b0c]
/usr/sbin/mysqld(+0x9614b0)[0x7f3e1ff744b0]
/usr/sbin/mysqld(+0x8aa29a)[0x7f3e1febd29a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f3e1eb84182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f3e1da6947d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2日前に私は多くの投稿を読みましたが、同様の状況の後でデーモンを再起動する方法は誰にもわかりません。
この投稿によると： MySQLのInnoDB破損を回復する方法
4を超える値を使用しようとすると、さらに破損する危険性が非常に高くなります。つまり、時間と労力が無駄になります。
これは本当ですか？？
私の主な質問は：
どのようにすればすべてのデータを回復し、問題がある場合はデーモンを再起動できますか？このプロセスを自動化して、今後それを防止したいと考えています。
ゼロ以外のinnodb_force_recoveryは危険なゾーンであり、値を慎重に増やす必要があります。はい、6はデータを永久に破損する可能性がありますが、MySQLがより低い値で開始しない場合、他にどのようなオプションがありますか？さらに、MySQLをinnodb_force_recoveryで起動する必要がある場合、データベースは既にであり、永続的に破損しており、再構築する必要があります。 セカンダリインデックス の破損など、おそらくまれなケースを除きます。
とにかく、MySQLがinnodb_force_recovery=6で始まっている場合は、--order-by-primaryを使用してデータベースをダンプし、--skip-lock-tablesを使用してデータベースをダンプしてください。次にMySQLを停止し、datadirを安全な場所に移動して、データベースを最初から再作成します。
Mysqldumpがクラッシュした場合、破損はinnodb_force_recoveryにとって深刻です。
（ヒント-すべてのテーブルを1つずつダンプして、MySQLクラッシュの原因となっているテーブルを見つけることができます）。
次に、データベースにアップロードし、修復されたSQLダンプをダウンロードして戻すことができる データ回復ポータル を紹介します。あなたがDIYアプローチを好むなら、同じ--- GitHub上のツールキット 。 ブログの投稿の1つ の手順を参照してください。
[〜＃〜]免責事項[〜＃〜]：私は両方のツールの作成者です。