スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MySQLのログの内容をテーブルで確認する

非同期レプリケーション接続フェイルオーバについて に続いて、先月リリースされた MySQL 8.0.22 のリリース情報から執筆しようと思います。

MySQL8.0.22 からエラーログの内容を従来のログファイルだけでなく performance_schema.error_log テーブルで確認できるようになりました。

また、当ブログでもご紹介しました Oracle Cloud の MySQL Database Service では、リリース当初はログ内容を確認する事ができなかったのが、このリリースにより、ログの内容を確認できるようになっています。
(現在の MySQL Database Service では、MySQL8.0.22 が稼働できるようになっています。)

今回は performance_schema.error_log テーブルについて、確認したいと思います。
詳細は、以下のリファレンスに記載されていますので、一読される事をお勧めします。

テーブルの構成・出力内容

テーブルの構成は以下のようになっています。

各カラムに格納する値は以下のようになります。
“DATA” カラムには、インデックスが存在しないので、イベントメッセージで検索する際は(そのようなケースはないかと思いますが)、注意が必要です。

カラム 説明
LOGGED イベント出力日時。
THREAD_ID イベント対象のスレッドID。バックグラウンドスレッドの場合は 0 が表示される。
PRIO イベントの優先度。System Error Warning Noteのいずれかが出力される。
ERROR_CODE イベントのエラーコード。
SUBSYSTEM イベントが発生したサブシステム。
DATA イベントメッセージ。

格納されているデータを参照すると、以下のようになっています。

実際のログファイルを見てみると、ログファイルと同じ情報が出力されている事が分かります。

performance_schema.error_log と ログファイルで、イベント出力日時が異なっていますが、これは検証した環境の以下のパラメータの違いによるものです。

  • performance_schema.error_log
    以下の設定に従いJSTの日時で出力。
  • ログファイル
    以下の設定に従いUTCの日時で出力。

performance_schema.error_log を参照する際は、time_zone の設定を変更する事で、イベント出力日時を任意のタイムゾーンに変更して出力する事が可能です。
例えば、現状の設定から、UTCの日時で出力したい場合には、以下のように実行します。

※Oracle Cloud の MySQL Database Service では、デフォルトで system_time_zone=UTC に設定されている為、time_zone を以下のように設定してから抽出することで、イベント出力日時を日本時間で表示できます。

また、このエラーログテーブルのみを参照するユーザを作成したい場合には、以下のようにユーザに権限を割り当てます。

テーブルに関するステータス変数

リファレンスに記載がありますが、performance_schema.error_log のデータは、新しいイベントを格納する為に、必要に応じて古いイベントが自動的に削除されるようです。
そういった情報に関するステータス変数も追加されています。

変数名 説明
Error_log_buffered_bytes テーブルで使用される容量。(バイト数)
Error_log_buffered_events テーブルに存在するイベント数。
Error_log_expired_events テーブルから破棄されたイベント数。
Error_log_latest_write テーブルへの最後の書き込み日時。

古いイベントの自動削除検証

前述しましたが、performance_schema.error_log のデータは必要に応じて古いイベントが削除されるという事なので、どの位のデータが格納されれば削除されるのか、簡単に検証しました。
検証方法は、log_error_verbosity=3 を設定して、ログイン認証エラーをエラーログに出力するようにし、以下のように、認証エラーを繰り返します。

また、上記の実行中に、エラーログに関するステータス変数を1秒ごとに取得しておきます。

実行結果は以下のようになりました。

イベント数が、43,682 ~ 43,688 の間で、イベントの削除が発生しています。
その後は、イベント数が 43,690 となった以降は、イベント数の増加がありませんでした。
(出力されるイベントメッセージ等によって変動する事が考えられますので、参考程度の情報となります。)

また、Error_log_buffered_bytes についても 5MB 付近から上昇が見られなくなりました。
検証後の最も古いデータは認証エラーのデータになっており、古いデータが削除された事が分かります。

イベントの削除について

テーブルに格納されているイベントの削除方法については、リファレンスに明記されておらず、削除できないようです。
rootユーザで試しに実行してみましたが、エラーとなり削除できませんでした。

また、テーブルには PERFORMANCE_SCHEMA ストレージエンジンを使用しておりますが、MySQLインスタンスの再起動に伴ってデータがクリアされる事はありません。

まとめ

OSログインせずともエラー内容が確認できるようになった事で、恩恵をうける方も多いのではないでしょうか。
最初に記載した通り、この機能リリースに伴い、Oracle Cloud の MySQL Database Service でエラーログの内容が確認できるようになったのですが、個人的な所感となりますが、MySQL Database Service を意識した機能であるように思います。
(今回は検証を簡単に行う為に、ローカル環境での確認となりましたが、、)

今後も、MySQL Database Service に関連するような更新情報もあるかと思いますので、そういった観点からもリリース内容を確認していきたいと思います。


MySQL

 

Return Top