mysqldをクラッシュリカバリ用に開始する前にInnoDB REDOログをクリアする方法
System： Windows Server 2012 R2、MariaDB 10.2.8
現在、準クラッシュから回復しようとしています（通常のシャットダウンでしたが、mysqldは再起動しません）。起動中にInnoDBのREDOログに問題があります。 innodb_force_recovery=0で始まる場合、プロセスはログに記録されるポイントに到達します
2019-06-14 9:29:41 14580 [Note] InnoDB: Starting final batch to recover 1150 pages from redo log.
そしてそこに行き詰まります。それ以降のログエントリはないため、さらに時間がかかるか、静かに失敗するかは不明です。 22時間待ってみましたが、目立った進歩はありませんでした。プロセスは、1％未満のCPU使用率と不変のメモリ使用率で実行されたため、おそらく黙って停止します。
次に、innodb_force_recoveryの数を増やしてみました。6になると、REDOログを完全にスキップして、サーバーが最終的に再起動します。残念ながら、これも読み取り専用で始まります。したがって、innodb_fast_shutdown=0を使用してログをクリアしても、シャットダウン時に何も実行されないように見えます。
ここで必要なのは、mysqldがオフラインのときにREDOログをクリアする方法です。ログファイルib_logfile0とib_logfile1を削除するだけではうまくいきません。これは、起動時に何らかの形で再作成され、上記と同じ問題が発生するためです。データが何らかの形でibdata1に保存されていると想定していますが、そこからテーブルスペースを削除せずにデータを削除することはできません。
最後の手段として、破損したデータベースのディレクトリをディスクから削除し（MySQL内では読み取り専用で始まるため削除できないため）、次にinnodb_force_recovery=3で開始して、もう一度プロセスを実行して、破損したデータベースを削除しようとしましたデータベースが存在しないため、REDOログの実行を試みて停止します。
どうやら、やり直しログを実行したり事前に消去したりせずにmysqldを起動し、破損したデータベースを削除してバックアップから復元するのが最善策のようです。しかし、REDOログで試行して失敗しない限り、書き込みモードで開始することはできません。ファイルを直接操作してクリアする方法はありますか？
あなたがしなければならないことは、
- mysqldプロセスを終了します。 MySQLサービス（またはサービスと呼ばれるもの）がサービスとして実行されている場合は、無効にします。
- 最新の10.2にアップグレードします（現在、すでに10.2.24にあり、非常に古いバージョンを使用しています）
- サービスを有効にして、再度開始してください。
再起動する場合しない、それがハングしている間にmysqldプロセスミニダンプを取得し、JIRAにバグを送信 https：// jira .mariadb.org/browse/MDEV
これは、Innodb REDOログを削除して「回復」しようとするよりも間違いなく便利です（これは、行うべきではないことの1つです）。