XAMPPのMariaDBが「Aria recovery failed」で起動しなくなったときの復旧記録

WindowsのXAMPP環境でMySQLを起動しようとしたところ、起動直後に停止するようになりました。
使っていたのはMariaDB 10.4.32です。XAMPPのコントロールパネルから何度か起動し直しても状況は変わりませんでした。
今回はエラーログを確認し、Ariaのログファイルだけを削除したところ、データを失うことなく起動できました。以下はそのときに行った切り分けと復旧作業の記録です。

この手順は、手元の環境で実際に復旧できた方法です。同じように見える起動障害でも原因が異なることがあるため、必ずログを確認し、作業前にバックアップを取ってください。

MariaDBが起動直後に停止する

環境は次のとおりです。

• OS：Windows
• XAMPP
• MariaDB：10.4.32-MariaDB
• データディレクトリ：C:\xampp\mysql\data
• 実行ファイルのディレクトリ：C:\xampp\mysql\bin

MariaDBのログを見ると、起動時に次のエラーが出ていました。

Cannot find checkpoint record at LSN (1,0x5ba5)
[ERROR] mysqld.exe: Aria recovery failed. Please run aria_chk -r on all Aria tables and delete all aria_log.######## files
[ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.

その後には、次のエラーも続いていました。

[ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
[ERROR] Failed to initialize plugins.
[ERROR] Aborting

ここだけを見るとMariaDB全体が壊れたようにも見えますが、同じログには次の行もありました。

InnoDB: 10.4.32 started; log sequence number 113149434; transaction id 81787

InnoDBは起動まで進んでいる一方、Ariaではチェックポイントを見つけられず、リカバリとストレージエンジンの登録に失敗しています。
そこで今回は、InnoDBのデータファイルではなく、ストレージエンジンのAriaのログまたはチェックポイントの不整合が原因だと判断しました。

最初にdataディレクトリをバックアップ

ファイルを削除する前に、MariaDBのデータディレクトリを丸ごとコピーしました。
Windowsのエクスプローラ上でコピーしても良いですが、コマンドで作業履歴残せるので、個人適にはPowerShellで実行しています。（お好み）

Copy-Item "C:\xampp\mysql\data" "C:\xampp\mysql\data_backup_20260822" -Recurse

復旧作業では、想定外の状態になる可能性があります。すぐ元に戻せるよう、バックアップが完了してから次へ進みました。

mysqldが停止していることを確認

MariaDBが動いたままログファイルを削除しないよう、mysqldプロセスの有無を確認しました。

Get-Process mysqld -ErrorAction SilentlyContinue

このときは何も表示されず、mysqldが停止していることを確認できました。
もしプロセスが表示される場合は、ファイルを操作する前にXAMPPからMariaDBを停止する必要があります。

Ariaのログファイルを確認

次に、データディレクトリにあるAria関連のログを確認しました。

Get-ChildItem "C:\xampp\mysql\data\aria_log*"

手元の環境では、次の2ファイルが存在していました。

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2026/08/22     14:56          24576 aria_log.00000001
-a----        2026/08/22     12:29             52 aria_log_control

エラーに出ていた aria_log.######## に該当するのは、ここでは aria_log.00000001 です。

aria_log.*だけを削除

バックアップと停止確認を済ませたうえで、次のコマンドを実行しました。

Remove-Item "C:\xampp\mysql\data\aria_log.*" -Force

この指定で削除したのは、aria_log.00000001 のように名前が aria_log. で始まるログファイルです。
aria_log_control は名前にピリオドがないため対象にならず、今回は削除していません。

削除後、MariaDBのサービスを起動すると、正常に起動しました。
壊れていたと考えられるAriaログは起動時に再生成されましたが、直前で作成していた作業用ユーザーが消えていたので再度手動操作して復旧しました。

ibdata1には触らなかった

XAMPPでMySQLが起動しない場合の対処法を調べると、次のような手順を見かけることがあります。

• ibdata1を削除する
• dataディレクトリを作り直す
• XAMPPのbackupディレクトリからファイルを上書きする

ただし、今回のログではInnoDBは起動していました。
その状態で最初からInnoDB関連のファイルに手を入れるのは、障害の範囲に対して変更が広すぎると思ったので、今回は次のファイルを削除も変更もしていません。

• ibdata1
• ib_logfile0
• ib_logfile1

ログに案内されていた aria_chk -r によるAriaテーブルの修復の方が良い気もしますが今回はホビー環境というのと、サクッと復旧させたかったのでaria_log.*の削除だけで起動できたため、そこで作業を止めました。

今回うまくいったポイントは、起動しないという現象だけで判断せず、ログからInnoDBとAriaの状態を分けて見たことでした。
データディレクトリをバックアップし、mysqldの停止を確認したうえで、原因と考えられるAriaログだけに操作を絞れました。

同じ Aria recovery failed でも、テーブル自体の修復が必要なケースはあり得ます。
まずは大きな変更を加えず、ログに現れている障害箇所から順に確認するのが大事なと改めて実感しました。