MariaDBのエラーログを分析し、正しく解釈する

エラーログの役割と限界

仝 MariaDB エラーログ これは、サーバープロセスの運用ログです。特に、起動および停止の操作、重大なサーバーイベント、ならびにテーブルやストレージエンジンに関する問題を示唆する可能性のある情報などが記録されます。このログは常に有効ですが、出力チャネルの設定は状況に応じて変更可能です。

そこには、例えばプラグインの初期化失敗、読み取れないファイル、アクセス拒否、あるいは接続に関するメッセージなどが表示されます。 しかし、「Access denied」という行が表示されたとしても、それはあくまで、送信されたデータによるログインが受け入れられなかったことを示すに過ぎません。原因がパスワード、ユーザーとホストの対応関係、認証方式、あるいは呼び出し元のアプリケーションのいずれにあるかは、状況から判断する必要があります。

また、エラーログは、アプリケーションのすべてのSQLエラーを網羅した完全なアーカイブではありません。そのためのものは、別途用意されている SQL_ERROR_LOG プラグイン; 発生したSQLエラーを別のファイルに書き込むことができ、その際、クライアントに届く前にコンディションハンドラーによって処理されたエラーも対象となります。 このプラグインはデフォルトではインストールされていません。そのエントリには、ユーザー、ホスト、データベース、およびSQLに関する情報が含まれる可能性があるため、使用前にアクセス制御とデータ最小化の方針を明確にしておく必要があります。

のために MySQLのトラブルシューティング したがって、断片的な最終行よりも、時系列の順序の方が重要です。 まず、その事象の前後にある一連のログを確実に確保してください。具体的なエラーメッセージの後に複数のエントリが続き、最終的に処理が中断される場合、最初の関連する異常は、最後に確認されたエラーよりも原因に近いことが多いのです。また、発生時刻、観察された症状、およびその時点でアプリケーションやシステムに加えられた変更も、評価の対象となります。

保存場所を確実に特定する

拡張子が .err これは、MariaDBが何もログを記録していなかったという意味ではありません。 エラーログは、ファイル、標準エラー出力、またはSyslogを介してsystemdジャーナルに書き込まれることがあります。Windowsでは、イベントビューアーにも記録されます。どの方式が有効になるかは、サーバーのオプション、パッケージ構成、および具体的なインストール環境の起動メカニズムによって異なります。

オプション log_error ファイルベースの出力において、出力先を指定します。相対ファイル名はデータディレクトリを基準として解釈されますが、絶対パスはそれとは無関係です。名前が明示的に指定されていない場合、ドキュメントでは「ホスト名＋」という形式でファイルが記述されます。 .err データディレクトリ内。ただし、これに基づいて固定のパスを推測してはなりません。常に実際に有効な設定を確認してください。

以下のコマンドは、オプションファイルからオプションのみを読み込みます。そのため、これらは log_error、ただし、これらが必ずしも実行中のプロセスの完全な設定を反映しているとは限りません。追加の起動パラメータや、systemdユニット、あるいはドロップイン・オーバーライドによって値が補足されたり変更されたりする場合があるため、これらについては個別に確認する必要があります。

最新のMariaDBドキュメントでは、このサーバープロセスは mariadbd; mysqld インストール環境によっては、引き続き互換性名として表示される場合があります。したがって、バージョンやインストールの状況を考慮せずに、これら2つの名称を同一視しないでください。これらのコマンドは、サービスやデータに変更を加えることはありません。

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

ドキュメントによると、2番目のコマンドはMariaDB 10.11以降で提供されるものであり、3番目のコマンドは、以前のプログラム名でインストールされた環境に関連するものです。 オプションファイルに明確なファイル指定が見つからない場合は、推測したログパスを作成するのではなく、ジャーナルやSyslog、および実際に起動されたサービスのパラメータを確認してください。これにより、診断と実行時の設定の不一致を防ぐことができます。

行の形式と文脈を正しく読み取る

10.1.5以降の最新のMariaDBバージョンにおけるファイルベースのエラーログでは、各行は基本的に「タイムスタンプ、スレッドID、レベル、メッセージ」という形式で構成されています。その タイムスタンプ このイベントを分類し、スレッドIDによって同じサーバー接続の他のエントリと関連付けることができ、レベルはメッセージの種類を表します。このメッセージは、これらのフィールドと組み合わせて初めて、診断のための信頼性の高い手がかりとなります。

MariaDB 10.1.4 までは、時刻の形式がより短く、表示が新しいスキーマとは異なります。 そのため、現在の形式の固定フィールド位置を想定しているパーサーや検索機能は、古いログを誤って解析してしまう可能性があります。さらに、Galera環境では、外部のSSTスクリプトによって、スレッドIDやレベルが欠落した行が書き込まれることがあります。このような特殊な行は、必ずしもログデータが破損していることを意味するわけではありません。

以下の抜粋は、起動シーケンスが失敗した場合の読み取り順序を示す、あくまで概略的な例に過ぎません。実際のインスタンスは使用しておらず、起動時の出力全体や有効なオプションの確認に代わるものではありません。重要な点は、設定の不一致が、最終的な中止メッセージよりも前に発生していることです。

2026-09-23 08:14:02 0 [Note] Starting MariaDB
2026-09-23 08:14:02 0 [ERROR] unknown variable 'example_option=1'
2026-09-23 08:14:02 0 [ERROR] Aborting

こちらです unknown variable 最初に調査すべき所見：そのオプションの記述が間違っているか、このバージョンでは利用できないか、あるいは間違った設定ファイルに配置されている可能性があります。 Aborting これに対し、これは起動シーケンスの終了点を示しています。そのため、最初の関連するメッセージまで遡って検索し、その後、続く行を記録してください。これにより、考えられる原因、サーバーの反応、および データベースエラー 互いにきちんと区別して。

リスクを伴う変更を伴わない初期導入

メッセージを解析したり設定を変更したりする前に、 運用コンテキスト: パッケージやディストリビューションの追加情報を含むMariaDBの完全なバージョン、OS、起動メカニズム、発生時刻、および目に見える症状。再起動、ログインの失敗、レプリケーションの停止は、それぞれ異なる事象です。これらの情報がなければ、同じログ行を信頼性を持って評価することはできません。

また、単一のヒットではなく、最初に目立った事象の前後を含む一連の区間をコピーしてください。 ユーザーやアプリケーションで問題がいつ発生し始めたか、またその時期に設定、デプロイ、ネットワークの変更が並行して行われていたかどうかを記録してください。そうすることで、トリガー、連鎖するエラー、および通常の起動・停止の順序を時間軸上で区別することができます。

以下のコマンドは、オプションファイルから設定情報を読み取るだけであり、サービスやデータを変更することはありません。これらは、特にそこに設定されたオプションを log_error で見つけることができます。ただし、これらはサービスが実際に起動された際のすべての値を自動的に表示するわけではありません。追加の起動パラメータ、systemdユニットファイル、およびドロップインについては、別途確認してください。

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

MariaDB 10.11 以降、MariaDB では以下のように記載されています my_print_defaults --mariadbd このクエリに対して。名前 mariadbd 今日のサーバープロセスを指す； mysqld 多くのインストール環境では、旧称や互換性確保のための名称として残されている。したがって、これら2つの名称を、同じ具体的なサーバーバージョンや同じサービス名を示すものとして扱わないでください。

ログがsystemd-Journalにある場合は、システム上で確認したユニット名に基づいて時間範囲を絞り込んでください。 必要に応じて、ユニットファイルや既存のドロップインも確認し、追加の起動パラメータが見落とされないようにしてください。また、症状が特定のアプリケーションで発生している場合は、その期間のアプリケーションログをこの抜粋に追加してください。

journalctl -u <geprüfte-mariadb-unit> --since "2026-09-23 08:00" --until "2026-09-23 09:00"

レベルと開始時のエラーの分類

ラベルはMariaDBのエラーログを整理する役割を果たしますが、原因の分析に代わるものではありません。 重大度 これは行の分類を示すものであり、必ずしも被害の程度や緊急度を示すものではありません。特に起動時の問題においては、順序が重要になります。つまり、より早い段階で表示された具体的なエラーメッセージが、後の問題を説明していることがよくあります。 Aborting、一方、それ以前の注記には通常の初期化に関する記述が含まれている場合もあります。

MariaDB が起動しない場合は、まずログ内の直近の起動シーケンスを特定し、そこから逆方向に読み進めてください。特に以下の項目を探してください。 unknown variable、ファイルの欠落や読み取り不能、権限の問題、プラグインの初期化時のエラーなど。MariaDBでは、起動に失敗した場合、主な情報源としてエラーログを参照するよう推奨しています。手動で起動した場合は、原因がコンソールにも表示されることがあります。

A 設定エラー これは、たいていの場合、読み込まれたファイル内の未知のオプション、記述方法、または不適切な値が原因です。その場合は、データ自体に手を加える前に、まず有効なオプションとバージョンの対応関係を確認してください。 一方、データファイルを開く際のエラーやInnoDBの警告は、権限、パス、ストレージ、またはデータの状態に関連している可能性があり、より慎重な判断が求められます。

強制的に起動させるために、複数のパラメータを同時に変更しないでください。ログの該当部分を保存し、エラーが発生する直前にどのような変更が行われたかを記録しておいてください。検証済みの設定やリソースに最初の関連メッセージが紐付けられて初めて、的を絞った、追跡可能な修正計画を立てることができます。

頻繁に報告される事象の診断的評価

繰り返し現れる表現は検索時間を短縮しますが、それだけでは診断につながることはめったにありません。各メッセージを、発生した時間帯、影響を受けたホストまたはスレッド、および観察された症状に割り当ててください。 この表には、意図的に診断のための次のステップのみを記載しています。これにより、接続、ファイル、またはレプリケーションに関する手がかりから、データベースサーバーに原因があると早合点することを防ぎます。

時点では アクセス拒否 まず重要なのは、どのユーザーおよびクライアントホストに対してログインが拒否されたかという点です。パスワードだけを単独で調べるのではなく、使用されているアプリケーションの設定や発生したタイミングも確認してください。 このメッセージは、ログイン情報の誤り、ホスト名の不一致、または認証方法の不一致によって発生する可能性があり、データベースが破損していることを示すものではありません。

A 接続が切断されました これは、アプリケーションのタイムアウト、ネットワーク回線の切断、プロキシ、またはパケット通信の不具合によるものと考えられます。 クライアントホストとスレッドIDをアプリケーションログと照合してください。カウンターについては、セッションごとの値ではなくグローバルな値を使用してください。そうしないと、新たに確立されたセッションで、誤解を招くほど低い値が表示される可能性があります。

SHOW GLOBAL STATUS LIKE 'Aborted%';

このクエリではカウンター値は表示されますが、完全な原因や個々のクライアントへの割り当ては表示されません。したがって、適切な期間にわたるログの抜粋と併せて、変化を評価してください。 レプリケーションやGTIDに関するメッセージが表示された場合は、その直後の行も記録し、専用のステータス情報を用いてレプリケーションの状態を確認してください。エラーログの行だけでは、レプリケーションの完全な診断には不十分です。

データ損失のリスクなしにInnoDBリカバリを評価する

予期せぬ停止の後、「Recovering after a crash」、「Starting crash recovery」といったメッセージや、処理が正常に完了したことを示すメッセージが表示されることがあります。これらは、まずサーバー起動時の自動クラッシュリカバリについて説明しています。バイナリログや tc.log また、トランザクションの調整に関する情報が含まれている場合もあります。これらの行だけでは、テーブルの破損やデータ損失の証拠とはなりません。

復元時に [ERROR] 起動が中断されたり、メッセージに「読み取れない」あるいは「破損した」ファイルが指定されたりする場合があります。その場合は、起動シーケンス全体を時系列順に読み、バージョン、障害発生時刻、および該当部分の全文を記録してください。Binary Log や tc.log への言及があっても、それに続くエラーがない限り、修復依頼とはみなされません。

データの問題が疑われる場合、単に起動を強制することだけを目的としたファイルの削除やその他の操作を行ってはなりません。まず、その措置の目的を明確にしてください。それは、エラーの範囲を特定すること、アクセス可能なデータを制御しながら読み出すこと、あるいは本番環境のインスタンスを復旧することです。 その際、ログの抜粋、既存のバックアップ、および影響を受けたインスタンスの状態を個別に記録しておいてください。

制御された読み出しが可能な場合、影響を受けた環境を「修復済み」とみなすのではなく、クリーンなターゲットインスタンスへの移行を計画に組み込む必要があります。関連するトランザクションの仕組みを理解するには、以下の記事が参考になります。 管理者向け MariaDB アンドゥログ。繰り返しクラッシュが発生したり、原因不明のファイルエラーが発生したりした場合は、起動を試み続けるよりも、専門家のデータ復旧サポートを受ける方が賢明です。

レプリケーションとSQLエラーを区別する

エラーログには、レプリケーション処理中にスレッド、位置、GTID、またはリレーログが表示されることがあります。こうした情報は、まず当該期間の状況を把握する手がかりにはなりますが、それだけでは完全なエラー診断には至りません。 該当エントリの前後にある行を保存し、それぞれ個別にレプリケーションの状態を確認してください。スレッドが正常に終了したのか、それとも中断が発生したのかは、単一のログ行からは確実に判断できません。

に関するニュース 事前設定された取引 一方、クラッシュ後の処理には特に注意が必要です。 ヒューリスティックなリカバリは、そのオプションに応じてコミットまたはロールバックの決定を行い、その際、トランザクション調整に関する情報を無視します。これは一般的なMySQLのトラブルシューティングの手順ではなく、レプリカや業務データに及ぼす影響を事前に評価する必要がある特殊なケースです。

エラーログはサーバーのイベントを記録しますが、すべてのエラーが発生したSQL文を網羅的に記録するものではありません。バイナリログは主に変更の記録とレプリケーションを目的としており、その役割については以下の記事で解説されています。 MariaDBのバイナリログとそのパフォーマンスの仕組み. スロークエリログは処理に時間がかかるクエリの分析に役立ち、一般クエリログは接続やクエリの包括的な監視に役立ち、監査ログは別の監査目的で利用されます。

発生したSQLエラーについては、別途 SQL_ERROR_LOG プラグイン. また、コンディション・ハンドラーによって処理され、技術的な理由からクライアントには送信されないエラーも記録できます。このプラグインは自動的にインストールされるわけではありませんが、MariaDB 10.11.5 以降では、適切な設定を行うことで警告も記録できるようになります。 ログエントリには、ユーザー情報やホスト情報、データベース名、SQL文などが含まれる可能性があります。そのため、本番環境で追加のログ記録を有効にする前に、厳格なアクセス権限の設定、保存期間、およびローテーションを計画してください。

運用、エスカレーション、および今後の対応

目立つ場合は、 データベースエラー まず、タイムスタンプ付きの連続したログの抜粋を記録してください。最後の行だけではなく。 その際、MariaDBのバージョンとパッケージID、起動メカニズム、観察された症状、およびデプロイ、再起動、インフラストラクチャのイベントとの時間的な相関関係を記録してください。これらのデータにより、考えられる原因と結果を区別し、アプリケーション、オペレーティングシステム、データベースからの情報を総合的に比較することが可能になります。

その後、想定されるデフォルト設定を変更するのではなく、実際に読み込まれたオプションと意図した設定を比較してください。 これは、パッケージ構成、MariaDBのバージョン、互換性名によってオプションへの影響が異なる可能性があるため、特に重要です。設定ミスが発生した場合、メモリやInnoDBの破損の可能性とは異なる方法で対処計画を立てることができます。

再起動、復旧作業、または設定変更を行う前に、利用可能なバックアップとその有効性を確認しておくことは、賢明な安全対策です。 また、予定されている変更内容と復旧手順を文書化してください。これは原因分析の代わりにはなりませんが、診断措置によって初期状態が不明瞭になったり、復旧が困難になったりするリスクを軽減します。

単発のアクセス拒否や接続切断については、それが再発せず、アプリケーションやサービスが安定して動作している限り、当面は様子を見てもよい。こうした事象が頻発する場合は、クライアントホスト、アプリケーション、プロキシ、ネットワークを調査対象に含めること。 一方、起動の繰り返し失敗、読み取り不能なデータファイル、クラッシュリカバリの失敗、または準備中のトランザクションの兆候が見られる場合は、バックアップ済みのオリジナルデータを用意した上で、速やかにエスカレーションを行う必要があります。

正常に機能するログであっても、運用ルールが必要です。監視してください ログローテーション また、メモリ使用量にも注意が必要です。ログの出力レベルを上げたり、SQLエラーログを追加したりすると、ファイルサイズが急速に肥大化する可能性があるためです。ログには技術的な詳細や、場合によっては機密性の高いクエリの内容が含まれているため、ログへのアクセスは制限してください。 恒久的な変更は、原因の文書化、復旧計画の策定、およびデータ保護と容量への影響の検証を経て初めて、妥当なものとなります。