web-dev-qa-db-ja.com

なぜinnodbテーブルが簡単に破損するのですか？

MySQL 5.1を実行しているレガシーシステムをMariaDB 10にアップグレードしています。XAMPPを実行している新しいWindowsサーバーを使用しています。私は自分の時間でたくさんのDB移行を行いましたが、これはMySQL/InnoDB地獄の1週間でした。

テーブルはMyISAMとInnoDBを組み合わせたものです。 MySQLが何らかの理由（何らかの理由）でクラッシュするたびに、1つ以上のInnoDBテーブルが破損するので、手動で削除して再インポートする必要があります。 「手動でドロップする」とは、次のことを意味します。

1）innodb_force_recovery=6を実行しない限り、mysqldは起動時にクラッシュします。これを実行すると、DBが読み取り専用モードになるため、DROP TABLEでテーブルが読み取り専用エラーになるだけです。

2）代わりに、mysqldを停止し、問題のテーブルの.ibdファイルを削除し、innodb_force_recovery=0（これで機能します）でmysqldを再起動し、最後にDROP TABLEを機能させる必要があります。

3）次に、SQLダンプから3〜4 GBのテーブルを再インポートする必要があり、これには時間がかかります。

興味深いことに、これはMyISAMテーブルではなく、InnoDBテーブルです。

Mysql_error.logを確認すると、ほとんどの場合、次のようになります。

2015-12-19  1:39:41 6580 [Warning] InnoDB: Allocated tablespace 234, old maximum was 0
InnoDB: Error: trying to access page number 2601 in space 234,
InnoDB: space name example/foobar,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
2015-12-19 01:39:41 19b4  InnoDB: Assertion failure in thread 6580 in file fil0fil.cc line 5821
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.
151219  1:39:41 [ERROR] mysqld got exception 0x80000003 ;

Mysqldがクラッシュしない限り、テーブルを再作成してインポートした後、すべてが正常に動作します。

悲しいことに、これを簡単に再現する手順を再現できます。私がしなければならないのは、非常に遅いクエリを実行することだけです。たとえば、システムが生成する特定のレポートがあり、その背後のクエリは30秒間簡単に実行されます（これは別の話です）。 mysqldサービスが終了する前に停止した場合、次回mysqldを起動するとすぐにクラッシュし、破損したInnoDBテーブルを処理して上記のすべての手順を繰り返します。

innodb_fast_shutdown = 0を試しましたが、効果がありませんでした。

「そのクエリの実行中にmysqldを停止しないでください」と言うかもしれませんが、システムのライブユーザーがいつでもそのレポートを実行できることを除いて、そのとおりです。つまり、再起動する必要があるときはいつでも何らかの理由でmysqldが再起動しない可能性があるため、もう一度テーブルを作成し直す必要があります。

ここで何が悪いのですか？

pdate 1実行時間の長いクエリは次のとおりです（テーブルの実際の名前が変更されました。それ以外の場合は逐語的です）：

SELECT * FROM `foobar` ORDER BY `daterun` DESC

テーブルには約130,000行があり、サイズは約4GBです。

mysqlinnodbmariadbwindowsmysql-5.1
4
David R.

Innodbはmyisamよりも高度で複雑なエンジンです。理由により、デフォルトのストレージエンジンです...

あなたは、システムが5.1からmariadb 10（eqvから5.6）にアップグレードされたと言いました。アップグレードパスはmysql 5.1-> maria 5.5-> maria 10でしたか？

  • クエリを共有できますか？
  • クエリを強制終了してから再起動した場合、問題は再発しますか？
  • シャットダウン中にクエリを実行する以外に何かありますか？
  • 関連するバグレポートがあるかどうかを調べてみます。

ここで正確なエラーを特定する前に考慮すべき解決策：-レポート用の個別のインスタンス。 -クエリを最適化します。

1
mysql_user