MySQLのログファイル
- On 2020年6月17日
ログは貴重です。クライアントに重要なデータへのアクセスを提供するバックエンドのリソースによって生成されるログは、単に価値があるだけではありません。ログがどこにあるかを知り、その情報を管理・理解できるかどうかで、スムーズで安全な操作ができるかどうか、パフォーマンスが低下するかどうか、あるいはアプリケーションの致命的な障害が発生するかどうかが決まります。
MySQL サーバは基本的なログを生成します。ここでは、どのログが重要なのか、なぜ重要なのか、どこにあるのか、そしてログを最大限に活用するために何ができるのかを見ていきます。
MySQLのログ
日々のIT運用において最も重要な3つのログは、エラーログ、低速なクエリのログ、(程度は低いですが)一般的なクエリのログです。これらのログのデフォルトフォーマットはテキストで、機能的な問題やセキュリティの問題の検出や診断、パフォーマンスの向上、サーバ操作やサーバへのアクセス履歴を追跡するのに役立ちます。
バイナリログ、リレーログ、DDLログはすべてバイナリ形式で、主にMySQL自身が使用するように設計されており、特にサーバのレプリケーションやデータリカバリなどのタスク用に設計されています。
どこで、どのように
まず、様々なMySQLディストリビューションがどのように、どのような状況下でデフォルトのログファイルの場所を設定しているのかを簡単に見てみましょう。
MySQLディストリビューションには、基本的に3つのタイプがあります。Windows、特定のプラットフォーム固有のUNIX/Linux、一般的なUNIX/Linuxです。一般的に、プラットフォーム固有のディストリビューションでは、ログの配置と有効化のためのデフォルト設定がありますが、一般的なUNIX/Linuxディストリビューションでは、手動設定でログを管理することを前提としています。
Windows
公式の MySQL Windows ディストリビューションでは、インストールの各段階でユーザーが選択可能なオプションを備えた MSI インストーラを使用しています。ロギングオプションのページでは、ログの有効化と場所のデフォルトが表示され、必要に応じて調整を行うことができます。
エラー、低速クエリ、バイナリログは、デフォルトで有効になっていますが、一般的なクエリログは有効になっていません。各ログのデフォルトの場所は、MySQL Data ディレクトリ(C:¥ProgramData¥MySQL Server [バージョン]¥Data)で、デフォルトのログ名はコンピュータのデバイス名に基づいています。
一般的なクエリ、低速クエリ、バイナリログはインストーラの GUI を通じて手動で有効/無効にできますが、エラーログはできません。また、各ログの名前とパスを手動で設定することもできます。
インストール後、ログの設定はユーザーが編集可能な C:¥ProgramData¥MySQL¥MySQL Server [バージョン]¥my.ini で管理されます。このファイルでログ名やパス、有効/無効を設定できます。
プラットフォーム固有のUNIX/Linux
特定の UNIX/Linux プラットフォーム用の公式ディストリビューションは、一般的にスクリプトでインストールされ、対話的な設定はほとんど、あるいは全く行われません。いくつかのインストールパッケージ(Yum や APT を含む)は、エラーログを /var/log/ や /var/log/mysql/ に error.log や mysqld.log のような名前で作成します。データディレクトリは通常 /var/lib/mysql/ またはそれに類似したものになり、代わりのパスがなくてもログのデフォルトの保存先として有効に機能します。
ログの設定は /etc/mysql/my.cnf のようなユーザーが編集可能な設定ファイルで管理します。これらの設定には、ログ名やパス、スイッチの有効化/無効化などが含まれます。起動とシャットダウンは通常 mysqld_safe(あるいは一部のディストリビューションでは systemd)によって管理されており、ログ設定オプションを見つけて適用します。
一般的な UNIX/Linux
一般的なインストールは、主に手動で行います。インストールプロセス中に、コマンドライン、スクリプトの実行、または適切な設定ファイルの編集により、ログの有効化と設定を行うことができます。MySQL オンラインリファレンスマニュアル(https://dev.mysql.com/doc/refman/5.7/en/server-logs.html)で、これらのオプションについて詳しく説明しています。
【訳注】MyQL5.6日本語リファレンスマニュアルは、https://dev.mysql.com/doc/refman/5.6/ja/ にあります。
エラーログ
timestamp thread ID [error type] [error code] [MySQL subsystem] Error message text
Error types include System, Warning, Note, and ERROR. Typical log entries might look like this:
2020-05-24T11:55:27.611014Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.20) starting as process 36070
2020-05-24T12:14:51.002836Z 2 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 2
2020-05-24T12:41:45.059924Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-05-24T12:41:45.086628Z 0 [ERROR] [MY-011825] [InnoDB] Failed to delete file ./#innodb_temp/temp_7.ibt
エラーログは常に有効で、利用可能なオプションでは、ログ出力先、冗長レベル、タイムゾーンを設定することができます。
可能なエラーログの出力先は、ファイルまたはコンソールです。Windows では出力先オプションが指定されていない場合、エラーログはデータディレクトリの host_name.err(host_name はホストシステム名)に書き込まれます。UNIX/Linux
システムでは、オプションが指定されていない場合のデフォルトの保存先はコンソールです。
UNIX/Linux と Windows ベースの MySQL の両方のインストールでは、–log-error オプションを指定すると(ファイル名やパスを指定せずに)、エラーログを Data ディレクトリの host_name.err に送信します。 –log-error=”G:¥TMP¥mysql_logs¥mysql_error.err” や、
–log-error=/var/log/mysql/error.log
のようにファイル名とパスを指定すると、エラーログは指定されたファイルに書き込まれます。Windows のコンソールにエラーログを送信するには –console オプションを使用する必要があります。 一般的なクエリログと低速クエリログ
2020-05-26T08:01:39.429740Z 17 Query INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
同じイベントの低速クエリログのエントリは、次のようになります。
# Time: 2020-05-26T08:01:50.095050Z
# User@Host: root[root] @ localhost [::1] Id: 17
# Query_time: 10.699002 Lock_time: 0.037315 Rows_sent: 0 Rows_examined: 0
use sakila;
SET timestamp=1590480099;
INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
遅いクエリログでは、実行に異常に長い時間を必要とするクエリを特定することができます。一般的なクエリログでは、すべてのクライアントのSQL文を追跡することができ、エラーの追跡や潜在的なセキュリティ問題の特定に役立ちます。
クエリログはデータを急速、大量に蓄積することがあるため、ディスク容量を消費するだけでなく、システムのパフォーマンスにも影響を与える可能性があります。特に一般的なクエリログは非常に速く増える可能性があり、ほとんどのインストールパッケージではデフォルトでクエリログと低速クエリログの両方が無効になっています(ただし、Windows MySQL インストーラは例外で、上述の通りです)。
一般クエリログと低速クエリログは、–general-log と –slow-query-log オプションを使用して別々に有効化します。デフォルトの出力先はデータディレクトリで、ファイル名は[ホスト名].log と [ホスト名]-slow.log です。ログ名とパスを設定するには、–general-log-fileと–slow-log-fileオプションを使用します。
両方のログの形式は、単一のオプション –log-output で制御され、FILE、TABLE、またはNONEの値をとり、FILEがデフォルト値です。TABLE は両方のログをテーブルとして保存し、SQL クエリで読み込んで管理することができます。FILEとTABLEはカンマで区切って一緒に使用することができます。NONE は、両方のログの出力を無効にします。 バイナリ、リレー、DDLログ
バイナリログとリレーログはサーバのレプリケーションに必要なもので、DDL ログは mysqld 操作中のメタデータを管理するためにシステムによって使用されます。これらのログは診断のための用途は限られていますが、データ復旧プロセスの一部として mysqlbinlog ユーティリティを使用してバイナリログやリレーログにアクセスする必要があるかもしれません。
すべてをまとめる
実は、比較的少ないサーバログから、MySQLは多くのログデータを生成することができます。同時に、そのデータの要素は、エラー追跡、パフォーマンス、セキュリティの観点から重要なものである可能性があります。知りたいことを見つけるために、MySQL サーバログを整理して並べ替えるには、どのような方法があるでしょうか。
Sumo Logic App for MYSQL は、エラーや低速クエリログから重要なメトリクスやデータ項目を自動的に抽出し、読みやすいダッシュボードに表示します。Sumo Logic を使用すると、パフォーマンスの問題、異常な動作やアクティビティのパターン、重要なエラーを簡単に特定できます。システムの健全性、レプリケーションの状態、サーバのパフォーマンスをひと目で確認でき、低速クエリ(ホスト、IP、ユーザー名などの情報)、ログインの失敗(ユーザー、ホスト、ロケーション)、レプリケーションとサーバの問題に関する詳細なリアルタイム情報を掘り下げて確認することができます。
ログファイルを調べるのに何時間も費やす必要はありません。Sumo Logic に仕事を任せて、顧客サービスに専念できるようにしましょう。
Michael Churchman
Michael Churchman氏は、ゲーム業界の初期の何でもありの時代に、脚本家、編集者、プロデューサーとしてスタートしました。’90年代の大半を大きなプレッシャーがかかるバンドルソフトウェア業界で過ごしましたが、そこはすでにウォーターフォールから高速リリースへの移行が進んでおり、継続的リリースと自動化されたデプロイメントがすでにデファクトスタンダードとなっていました。
この間、彼は15以上の言語でローカリゼーションを管理するための半自動システムを開発しました。過去10年間、彼はソフトウェア開発プロセスと関連するエンジニアリング管理の問題の分析に携わってきました。彼はFixate.ioの定期的なコントリビューターです。
本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
- MySQLのログ
日々のIT運用において最も重要な3つのログは、エラーログ、低速なクエリのログ、(程度は低いですが)一般的なクエリのログです。これらのログのデフォルトフォーマットはテキストで、機能的な問題やセキュリティの問題の検出や診断、パフォーマンスの向上、サーバ操作やサーバへのアクセス履歴を追跡するのに役立ちます。
バイナリログ、リレーログ、DDLログはすべてバイナリ形式で、主にMySQL自身が使用するように設計されており、特にサーバのレプリケーションやデータリカバリなどのタスク用に設計されています。
どこで、どのように
まず、様々なMySQLディストリビューションがどのように、どのような状況下でデフォルトのログファイルの場所を設定しているのかを簡単に見てみましょう。 MySQLディストリビューションには、基本的に3つのタイプがあります。Windows、特定のプラットフォーム固有のUNIX/Linux、一般的なUNIX/Linuxです。一般的に、プラットフォーム固有のディストリビューションでは、ログの配置と有効化のためのデフォルト設定がありますが、一般的なUNIX/Linuxディストリビューションでは、手動設定でログを管理することを前提としています。Windows
公式の MySQL Windows ディストリビューションでは、インストールの各段階でユーザーが選択可能なオプションを備えた MSI インストーラを使用しています。ロギングオプションのページでは、ログの有効化と場所のデフォルトが表示され、必要に応じて調整を行うことができます。 エラー、低速クエリ、バイナリログは、デフォルトで有効になっていますが、一般的なクエリログは有効になっていません。各ログのデフォルトの場所は、MySQL Data ディレクトリ(C:¥ProgramData¥MySQL Server [バージョン]¥Data)で、デフォルトのログ名はコンピュータのデバイス名に基づいています。 一般的なクエリ、低速クエリ、バイナリログはインストーラの GUI を通じて手動で有効/無効にできますが、エラーログはできません。また、各ログの名前とパスを手動で設定することもできます。 インストール後、ログの設定はユーザーが編集可能な C:¥ProgramData¥MySQL¥MySQL Server [バージョン]¥my.ini で管理されます。このファイルでログ名やパス、有効/無効を設定できます。プラットフォーム固有のUNIX/Linux
特定の UNIX/Linux プラットフォーム用の公式ディストリビューションは、一般的にスクリプトでインストールされ、対話的な設定はほとんど、あるいは全く行われません。いくつかのインストールパッケージ(Yum や APT を含む)は、エラーログを /var/log/ や /var/log/mysql/ に error.log や mysqld.log のような名前で作成します。データディレクトリは通常 /var/lib/mysql/ またはそれに類似したものになり、代わりのパスがなくてもログのデフォルトの保存先として有効に機能します。 ログの設定は /etc/mysql/my.cnf のようなユーザーが編集可能な設定ファイルで管理します。これらの設定には、ログ名やパス、スイッチの有効化/無効化などが含まれます。起動とシャットダウンは通常 mysqld_safe(あるいは一部のディストリビューションでは systemd)によって管理されており、ログ設定オプションを見つけて適用します。一般的な UNIX/Linux
一般的なインストールは、主に手動で行います。インストールプロセス中に、コマンドライン、スクリプトの実行、または適切な設定ファイルの編集により、ログの有効化と設定を行うことができます。MySQL オンラインリファレンスマニュアル(https://dev.mysql.com/doc/refman/5.7/en/server-logs.html)で、これらのオプションについて詳しく説明しています。 【訳注】MyQL5.6日本語リファレンスマニュアルは、https://dev.mysql.com/doc/refman/5.6/ja/ にあります。エラーログ
エラーログには、起動時やシャットダウン時だけでなく、サーバ操作中に生成されたエラーメッセージ、警告、注意事項が含まれており、起動時間やシャットダウン時間も記録されます。 基本的なエラーログのフォーマットは以下の通りです。timestamp thread ID [error type] [error code] [MySQL subsystem] Error message text Error types include System, Warning, Note, and ERROR. Typical log entries might look like this: 2020-05-24T11:55:27.611014Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.20) starting as process 36070 2020-05-24T12:14:51.002836Z 2 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 2 2020-05-24T12:41:45.059924Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed. 2020-05-24T12:41:45.086628Z 0 [ERROR] [MY-011825] [InnoDB] Failed to delete file ./#innodb_temp/temp_7.ibt
エラーログは常に有効で、利用可能なオプションでは、ログ出力先、冗長レベル、タイムゾーンを設定することができます。 可能なエラーログの出力先は、ファイルまたはコンソールです。Windows では出力先オプションが指定されていない場合、エラーログはデータディレクトリの host_name.err(host_name はホストシステム名)に書き込まれます。UNIX/Linux システムでは、オプションが指定されていない場合のデフォルトの保存先はコンソールです。 UNIX/Linux と Windows ベースの MySQL の両方のインストールでは、--log-error オプションを指定すると(ファイル名やパスを指定せずに)、エラーログを Data ディレクトリの host_name.err に送信します。 --log-error='G:¥TMP¥mysql_logs¥mysql_error.err' や、 --log-error=/var/log/mysql/error.log のようにファイル名とパスを指定すると、エラーログは指定されたファイルに書き込まれます。Windows のコンソールにエラーログを送信するには --console オプションを使用する必要があります。一般的なクエリログと低速クエリログ
一般的なクエリと低速クエリのログは、どちらも同様のフォーマットを使用してユーザーのクエリを記録します。Time、ID、Command、Argument(ArgumentにはSQLコマンドとクエリを構成するデータの両方が含まれます)です。 一般的なクエリログには、すべてのクライアントのSQL文と接続時間と切断時間が記録され、低速クエリログには、long query-timeシステム変数で指定された時間よりも長い時間がかかるクエリのみが記録されます。低速クエリログには、ログに記録された各クエリの実行時間、ロック時間、送信された行、検査された行を含むフィールドのセットも含まれています。 典型的な一般的なクエリログのエントリは以下のようになります。2020-05-26T08:01:39.429740Z 17 Query INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
同じイベントの低速クエリログのエントリは、次のようになります。# Time: 2020-05-26T08:01:50.095050Z # User@Host: root[root] @ localhost [::1] Id: 17 # Query_time: 10.699002 Lock_time: 0.037315 Rows_sent: 0 Rows_examined: 0 use sakila; SET timestamp=1590480099; INSERT INTO rental VALUES (1,'2005-05-24 22:53:30…
遅いクエリログでは、実行に異常に長い時間を必要とするクエリを特定することができます。一般的なクエリログでは、すべてのクライアントのSQL文を追跡することができ、エラーの追跡や潜在的なセキュリティ問題の特定に役立ちます。 クエリログはデータを急速、大量に蓄積することがあるため、ディスク容量を消費するだけでなく、システムのパフォーマンスにも影響を与える可能性があります。特に一般的なクエリログは非常に速く増える可能性があり、ほとんどのインストールパッケージではデフォルトでクエリログと低速クエリログの両方が無効になっています(ただし、Windows MySQL インストーラは例外で、上述の通りです)。 一般クエリログと低速クエリログは、--general-log と --slow-query-log オプションを使用して別々に有効化します。デフォルトの出力先はデータディレクトリで、ファイル名は[ホスト名].log と [ホスト名]-slow.log です。ログ名とパスを設定するには、--general-log-fileと--slow-log-fileオプションを使用します。 両方のログの形式は、単一のオプション --log-output で制御され、FILE、TABLE、またはNONEの値をとり、FILEがデフォルト値です。TABLE は両方のログをテーブルとして保存し、SQL クエリで読み込んで管理することができます。FILEとTABLEはカンマで区切って一緒に使用することができます。NONE は、両方のログの出力を無効にします。バイナリ、リレー、DDLログ
バイナリログとリレーログはサーバのレプリケーションに必要なもので、DDL ログは mysqld 操作中のメタデータを管理するためにシステムによって使用されます。これらのログは診断のための用途は限られていますが、データ復旧プロセスの一部として mysqlbinlog ユーティリティを使用してバイナリログやリレーログにアクセスする必要があるかもしれません。すべてをまとめる
実は、比較的少ないサーバログから、MySQLは多くのログデータを生成することができます。同時に、そのデータの要素は、エラー追跡、パフォーマンス、セキュリティの観点から重要なものである可能性があります。知りたいことを見つけるために、MySQL サーバログを整理して並べ替えるには、どのような方法があるでしょうか。 Sumo Logic App for MYSQL は、エラーや低速クエリログから重要なメトリクスやデータ項目を自動的に抽出し、読みやすいダッシュボードに表示します。Sumo Logic を使用すると、パフォーマンスの問題、異常な動作やアクティビティのパターン、重要なエラーを簡単に特定できます。システムの健全性、レプリケーションの状態、サーバのパフォーマンスをひと目で確認でき、低速クエリ(ホスト、IP、ユーザー名などの情報)、ログインの失敗(ユーザー、ホスト、ロケーション)、レプリケーションとサーバの問題に関する詳細なリアルタイム情報を掘り下げて確認することができます。 ログファイルを調べるのに何時間も費やす必要はありません。Sumo Logic に仕事を任せて、顧客サービスに専念できるようにしましょう。Michael Churchman
Michael Churchman氏は、ゲーム業界の初期の何でもありの時代に、脚本家、編集者、プロデューサーとしてスタートしました。’90年代の大半を大きなプレッシャーがかかるバンドルソフトウェア業界で過ごしましたが、そこはすでにウォーターフォールから高速リリースへの移行が進んでおり、継続的リリースと自動化されたデプロイメントがすでにデファクトスタンダードとなっていました。 この間、彼は15以上の言語でローカリゼーションを管理するための半自動システムを開発しました。過去10年間、彼はソフトウェア開発プロセスと関連するエンジニアリング管理の問題の分析に携わってきました。彼はFixate.ioの定期的なコントリビューターです。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">
0 Comments