web-dev-qa-db-ja.com

保留中のトランザクションがあるMySQLテーブルを削除する

MySQLで保留中のトランザクションがあるInnoDBテーブルまたはデータベースを（好ましくはファイルシステムレベルで）削除する方法はありますか？

どうした：

MySQL 5.5.28を使用してLOAD DATA INFILE…を実行し、巨大なデータセット（300M行）をInnoDBテーブルにインポートしました。以前はset autocommit = 0;を使用していませんでした。残念ながら、mysqldはインポートの途中で停止されました。

mysqlを再起動すると、トランザクションがロールバックされ、次のようなメッセージがシステムログに記録されます。

mysqld_safe [4433]：121212 16:58:52 InnoDB：1つのアクティブなトランザクションが完了するのを待機しています

問題は、ロールバックが25時間以上実行され、その間mysqldがソケット接続を受け入れないことです。

このマシンには他にもInnoDBデータベース/テーブルがあるため、/var/lib/mysql/*を削除して最初から始めることはできません。ただし、問題のあるテーブルは、別のデータベース内の唯一のテーブルです。後ですべてのデータを再インポートできるため、テーブル全体またはデータベース全体を削除しても問題ありません。

mysqlinnodbtransactionrollback
10
dasup

UNDOテーブルスペースibdata1 を介してロールバックが実行されているため、実際にできることはありません。 。

Mysqldプロセスを終了してmysqlを再起動すると、クラッシュリカバリサイクルの一部として中断したところから再開されます。

免責事項：データ損失の責任はありません

他のテーブルのデータが失われる可能性がありますが、InnoDBの通常のクラッシュリカバリサイクルを回避するためにできることがいくつかあります。

innodb_force_recovery という起動オプションがあり、InnoDBクラッシュリカバリのさまざまな段階をバイパスできます。

MySQLドキュメンテーションの強制に関するInnoDBリカバリ によると、設定とその効果は次のとおりです。

1 (SRV_FORCE_IGNORE_CORRUPT)

破損したページを検出した場合でも、サーバーを実行します。 SELECT * FROM tbl_nameが破損したインデックスレコードとページを飛び越えられるようにしてください。これはテーブルのダンプに役立ちます。

2 (SRV_FORCE_NO_BACKGROUND)

マスタースレッドが実行されないようにします。パージ操作中にクラッシュが発生した場合、この回復値によりクラッシュが防止されます。

3 (SRV_FORCE_NO_TRX_UNDO)

クラッシュリカバリの後にトランザクションロールバックを実行しないでください。

4 (SRV_FORCE_NO_IBUF_MERGE)

挿入バッファーのマージ操作を防止します。クラッシュの原因となる場合は、実行しないでください。テーブル統計を計算しません。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

データベースの起動時に取り消しログを確認しないでください。InnoDBは、不完全なトランザクションもコミットされたものとして扱います。

6 (SRV_FORCE_NO_LOG_REDO)

リカバリに関連してREDOログのロールフォワードを実行しないでください。

トランザクションの変更がUNDOおよびREDOログに埋め込まれていると、

  • 書き込まれるはずのデータを失う
  • 削除対象のデータを保持する

悪い副作用が予想される場合は、/ var/lib/mysql全体をバックアップし、ibdata1、ib_logfile0、およびib_logfile1をコピーして通常のリカバリを再試行する場合に備えて、どこかに置きます。

Mysqlがいずれかのモードで完全に起動している場合

  • mysqldumpは問題のテーブルを除くすべてのデータ
  • mysqlのシャットダウン
  • / var/lib/mysql/mysqlを除く/ var/lib/mysql内のすべてを削除します
  • mysqlを起動する
  • mysqldumpをリロードします

警告：すべてをバックアップしてください!!!

これが役に立てば幸いです!!!

8
RolandoMySQLDBA

今週も同じような状況でした。

そして、テストサーバーに完全バックアップを復元し、巨大な保留中のトランザクションを含むテーブルを削除、削除、または削除しようと4回繰り返した後、最終的に金曜日の午後に到達し、そのまま実行することにしました。 3日間で、サーバーの負荷はごくわずかでトランザクションは終了し、データベースは正常でした。これは、試行して失敗した.frmファイルとmysqlテーブルに対する手動操作よりもはるかに優れていました。

私の解決策：削除しないでください。数日間他の操作を延期したり、ディスク容量をどこかに見つけたり、スレーブサーバーに負荷をかけたりする必要がある場合でも、保留中のトランザクションを終了させます。

1
andrew lorien