技術資料

ローカルのXAMPP環境でphpMyAdminを開いたところ、MariaDBへの接続が拒否されてログインできなくなりました。

コマンドラインから接続しても同じエラーが発生したため、接続先の設定だけではなく、MariaDB内部の認証情報を確認することにしました。

調査した結果、MariaDB 10.4の認証情報を保持しているmysql.global_privテーブルが破損していました。今回は、データディレクトリをバックアップした上で、テーブルを修復して接続を復旧した手順を紹介します。

なお、MariaDBが破損した直接のきっかけは確認できていません。MariaDB起動中のPCシャットダウンが原因だった可能性はありますが、あくまで推測です。

前提

今回の環境は以下の通りです。

• OS: Windows
• XAMPP
• MariaDB: 10.4.32-MariaDB
• MariaDBのポート: 3306
• phpMyAdminの接続先: 127.0.0.1
• PowerShell

記事中のC:\xamppはXAMPPの配置先を一般化したものです。実際の配置先に合わせて読み替えてください。

MariaDB 10.4では、ユーザーアカウント、パスワード、グローバル権限などがmysql.global_privに保存されます。従来のmysql.userは、このテーブルを参照するビューです。詳しくはMariaDB 10.4の認証に関する公式ドキュメントを参照してください。

発生した症状

phpMyAdminを開くと、次のエラーが表示されました。

mysqli::real_connect(): (HY000/1130):
Host 'localhost' is not allowed to connect to this MariaDB server

コマンドラインから接続しても、同じエラーになります。

cd C:\xampp\mysql\bin

.\mysql.exe `
    --protocol=tcp `
    -h 127.0.0.1 `
    -P 3306 `
    -u root

実行結果は以下の通りです。

ERROR 1130 (HY000): Host 'localhost' is not allowed to connect to this MariaDB server

3306番ポートの接続先を確認する

まず、3306番ポートで待ち受けているプロセスを確認します。

$conn = Get-NetTCPConnection `
    -LocalPort 3306 `
    -State Listen |
    Select-Object -First 1

$conn |
    Format-List LocalAddress, LocalPort, OwningProcess

Get-CimInstance Win32_Process `
    -Filter "ProcessId = $($conn.OwningProcess)" |
    Select-Object ProcessId, ExecutablePath, CommandLine |
    Format-List

今回の確認結果では、3306番ポートを使用していたのは、意図したXAMPP環境のMariaDBでした。

ExecutablePath : C:\xampp\mysql\bin\mysqld.exe
CommandLine    : "C:\xampp\mysql\bin\mysqld.exe"
                 --defaults-file="C:\xampp\mysql\bin\my.ini"
                 --standalone

別のMySQLやMariaDBへ接続しているわけではないことを確認できたため、次にMariaDBのデータとシステムテーブルを確認します。

MariaDBを停止してデータディレクトリをバックアップする

データディレクトリを操作する前に、XAMPP Control PanelからMariaDBを停止します。

停止後、PowerShellでプロセスが残っていないことを確認します。

Get-Process mysqld -ErrorAction SilentlyContinue

何も表示されなければ、mysqldは停止しています。

MariaDBが停止していることを確認したら、データディレクトリを別の場所へコピーします。

$stamp = Get-Date -Format "yyyyMMdd_HHmmss"

Copy-Item `
    "C:\xampp\mysql\data" `
    "C:\xampp\mysql\data_backup_$stamp" `
    -Recurse

ここで作成したバックアップは、復旧作業が完了したあともしばらく保持しておきます。修復に失敗した場合や、別のテーブルにも問題が見つかった場合に、元の状態へ戻すために必要になります。

--skip-grant-tables付きでMariaDBを起動する

通常の認証では接続できないため、MariaDBを一時的に--skip-grant-tables付きで起動します。

このオプションを付けると、権限テーブルを使わずにMariaDBが起動します。認証チェックが無効になり、全ユーザーがすべてのテーブルへアクセスできる状態になるため、復旧作業中だけ使用してください。詳細はMariaDBの--skip-grant-tablesに関する公式ドキュメントを参照してください。

管理者権限のPowerShellで、MariaDBの実行ファイルがあるディレクトリへ移動して実行します。

cd C:\xampp\mysql\bin

.\mysqld.exe `
    --defaults-file="C:\xampp\mysql\bin\my.ini" `
    --skip-grant-tables `
    --console

このPowerShell ウィンドウは、復旧作業が終わるまで開いたままにします。

別のPowerShellから接続する

別のPowerShellを開き、同じMariaDBへ接続します。

cd C:\xampp\mysql\bin

.\mysql.exe `
    --protocol=tcp `
    -h 127.0.0.1 `
    -P 3306 `
    -u root

復旧モードでは認証チェックが無効になっているため、通常起動時に接続できなかったMariaDBへ接続できました。

認証情報テーブルの破損を確認する

まず、MariaDBのバージョンを確認します。

SELECT VERSION();

今回の結果は以下の通りでした。

10.4.32-MariaDB

続いて、ユーザー情報を確認します。

SELECT User, Host, plugin
FROM mysql.user
ORDER BY User, Host;

あわせて、認証情報の実体であるmysql.global_privも確認します。

SELECT Host, User, Priv
FROM mysql.global_priv
ORDER BY User, Host;

どちらのクエリでも、次のエラーが発生しました。

ERROR 1030 (HY000):
Got error 176 "Read page with wrong checksum" from storage engine Aria

このエラーから、Ariaストレージエンジンのテーブルデータを正常に読み取れていないことが分かります。

さらに、CHECK TABLEでテーブルの状態を確認します。

CHECK TABLE mysql.global_priv EXTENDED;

結果は以下の通りでした。

Page 0: Got error: 176 when reading datafile
Corrupt

今回の環境では、MariaDBが接続ユーザーを判定するために参照するmysql.global_privが破損していたことが、接続エラーの原因でした。

mysql.global_privを修復する

バックアップが完了し、対象テーブルの破損を確認できたら、REPAIR TABLEを実行します。

REPAIR TABLE mysql.global_priv;

今回は次の結果になりました。

status | OK

REPAIR TABLEはAria、MyISAM、Archive、CSVのテーブルを対象にした修復処理です。今回のようにAriaテーブルの破損を確認した場合に使える方法ですが、必ず修復できるとは限りません。詳しくはREPAIR TABLEの公式ドキュメントを参照してください。

修復後の状態を確認する

修復が完了したら、もう一度CHECK TABLEを実行します。

CHECK TABLE mysql.global_priv EXTENDED;

今度はOKになりました。

status | OK

ユーザー情報も再度確認します。

SELECT User, Host, plugin
FROM mysql.user
ORDER BY User, Host;

既存のpma@localhostやroot@localhostなどのユーザーを参照できるようになり、ユーザー情報が失われていないことを確認できました。

復旧モードを終了して通常起動へ戻す

MariaDBクライアントでexitを実行します。

exit

次に、--skip-grant-tables --consoleを付けて起動していたPowerShellでCtrl+Cを押し、復旧モードのMariaDBを停止します。

停止後、プロセスが残っていないことを確認します。

Get-Process mysqld -ErrorAction SilentlyContinue

問題がなければ、XAMPP Control PanelからMariaDBを通常どおり起動します。

通常起動後に接続とテーブルを確認する

まず、通常の認証処理を通して接続できることを確認します。

cd C:\xampp\mysql\bin

.\mysql.exe `
    --protocol=tcp `
    -h 127.0.0.1 `
    -P 3306 `
    -u root `
    -e "SELECT CURRENT_USER(), VERSION();"

今回は、以下の結果になりました。

CURRENT_USER() | VERSION()
root@localhost | 10.4.32-MariaDB

phpMyAdminを再読み込みして、ログインできることも確認します。

最後に、全データベースのテーブルをチェックします。

.\mysqlcheck.exe `
    --protocol=tcp `
    -h 127.0.0.1 `
    -P 3306 `
    -u root `
    --check `
    --all-databases

今回の確認では、アプリケーションのテーブル、mysql.global_priv、phpMyAdminの管理テーブルなどはOKでした。mysql.dbでデータファイルサイズに関する警告が出たため、念のため詳細チェックも行いました。

.\mysql.exe `
    --protocol=tcp `
    -h 127.0.0.1 `
    -P 3306 `
    -u root `
    -e "CHECK TABLE mysql.db EXTENDED;"

このチェックも最終的にはOKとなり、追加の修復は不要と判断しました。

今回の原因について

今回、確認できた直接の原因は、ユーザー認証情報を保持するmysql.global_privの破損です。

破損したテーブルをMariaDBが読み取れなかったため、root@localhostなどの接続ユーザーを正常に判定できず、ERROR 1130が発生していました。

一方で、テーブルが破損したきっかけまでは確認できていません。MariaDBを起動したままPCをシャットダウンしたことが影響した可能性はありますが、ログなどで確認できていないため、一般的な原因として断定することは避けます。

既存のMySQL復旧記事との違い

以前、XAMPPのMySQLがデータ破損で起動しなくなったときに、データディレクトリをバックアップして必要なデータを取り出す方法を「XAMPPのMySQLが起動しなくなった時のデータ救出方法」で紹介しました。

今回の記事とは、復旧の対象が異なります。

• 以前の記事: InnoDBデータを取り出すことが目的
• 今回の記事: 認証情報テーブルを修復して接続を復旧することが目的

そのため、今回の症状に対して、以前の記事のようにデータディレクトリを初期状態へ置き換える手順をそのまま適用しないようにしてください。

注意点

• --skip-grant-tablesで起動している間は認証チェックが無効になるため、復旧作業中だけ使用する。
• 復旧モードでMariaDBを起動したまま、ネットワークから接続できる状態にしない。
• my.iniへskip-grant-tablesを恒久的に設定しない。
• MariaDBを停止し、データディレクトリをバックアップしてからテーブルを修復する。
• REPAIR TABLEで修復できない場合は、作成したバックアップを保持したまま、別の復旧方法を検討する。
• システムテーブルを直接更新したり、初期化したりする場合は、影響範囲を確認してから実行する。

まとめ

今回は、XAMPPのMariaDBでERROR 1130が発生し、phpMyAdminやCLIから接続できなくなった場合の復旧手順を紹介しました。

今回の環境では、認証情報を保持するmysql.global_privがAriaテーブルとして破損していました。データディレクトリをバックアップした上で復旧モードを起動し、CHECK TABLEで破損を確認してからREPAIR TABLEを実行することで、既存ユーザーを維持したまま接続を復旧できました。

ただし、データベースのシステムテーブルを修復する作業にはリスクがあります。まずバックアップを作成し、対象のテーブルと症状が一致していることを確認してから、慎重に作業してください。