メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

MariaDB データベースログファイル

MariaDB エラーログ、スロークエリログ、一般ログをモニタリングできます。MariaDB エラーログはデフォルトで生成されます。DB パラメータグループのパラメーターを設定することで、スロークエリと一般ログを生成できます。Amazon RDS では、すべての MariaDB ログファイルはローテーションされます。次に、ログファイルのタイプごとのローテーション間隔を示します。

MariaDB ログは、Amazon RDS コンソール、Amazon RDS API、Amazon RDS CLI、または AWS SDK を通じて直接モニタリングできます。また、ログをメインデータベースのデータベーステーブルに書き込み、そのテーブルに対してクエリを実行することで、MariaDB ログにアクセスできます。mysqlbinlog ユーティリティを使用して、バイナリログをダウンロードできます。

ファイルベースのデータベースログの表示、ダウンロード、監視の詳細については、「Amazon RDS データベースログファイル」を参照してください。

MariaDB エラーログにアクセスする

MariaDB エラーログは <host-name>.err ファイルに書き込まれます。このファイルを表示するには、Amazon RDS コンソールを使用するか Amazon RDS、API、Amazon RDS CLI、または AWS SDK を使用してログを取得します。<host-name>.err ファイルは 5 分ごとにフラッシュされ、その内容は mysql-error-running.log に追加されます。 その後、mysql-error-running.log ファイルは 1 時間ごとにローテーションされ、直前 24 時間内に 1 時間ごとに生成されたファイルが保持されます。各ログファイルには、それぞれ生成された時間 (UTC) がファイル名に付加されます。ログファイルには、タイムスタンプも付加され、ログエントリがいつ書き込まれたかを調べるために役立ちます。

MariaDB では、スタートアップ時、シャットダウン時、エラー検出時にのみエラーログへの書き込みが行われます。DB インスタンスでは、新しいエントリがエラーログに書き込まれないまま、数時間または数日が経過することがあります。最近のエントリがない場合、それは、サーバーにログエントリになるエラーが発生しなかったためです。

MariaDB のスロークエリと一般ログにアクセスする

MariaDB のスロークエリログと一般ログは、DB パラメータグループのパラメーターを設定することで、ファイルまたはデータベーステーブルに書き込むことができます。DB パラメータグループの作成と変更の詳細については、「DB パラメータグループを使用する」を参照してください。スロークエリログまたは一般ログを表示する前に、以下のパラメーターを設定する必要があります。そのためには、Amazon RDS コンソールを使用するか、Amazon RDS API、Amazon RDS CLI、または AWS SDK を使用します。

以下のリストに示すパラメーターを使用して MariaDB のログ記録を制御できます。

  • slow_query_log: スロークエリログを作成するには、1 に設定します。デフォルトは 0 です。

  • general_log: 一般ログを作成するには、1 に設定します。デフォルトは 0 です。

  • long_query_time: ファストクエリがスロークエリログに記録されないようにするために、ログに記録されるクエリの最短実行時間の値を秒単位で指定します。デフォルトは 10 秒で、最小値は 0 です。 log_output = FILE の場合は、マイクロ秒の精度になるように、浮動小数点値を指定できます。log_output = TABLE の場合は、秒の精度になるように、整数値を指定する必要があります。実行時間が long_query_time の値を超えたクエリのみがログに記録されます。たとえば、long_query_time を 0.1 に設定すると、実行時間が 100 ミリ秒未満のすべてのクエリはログに記録されなくなります。

  • log_queries_not_using_indexes: インデックスを使用しないすべてのクエリをスロークエリログに記録するには、このパラメーターを 1 に設定します。 デフォルトは 0 です。インデックスを使用しないクエリは、その実行時間が long_query_time パラメーターの値未満であってもログに記録されます。

  • log_output option: log_output パラメーターに指定できるオプションは、次のとおりです。

    • TABLE (デフォルト) – 一般クエリを mysql.general_log テーブルに、スロークエリを mysql.slow_log テーブルに書き込みます。

    • FILE – 一般クエリログとスロークエリログの両方をファイルシステムに書き込みます。ログファイルは 1 時間ごとにローテーションされます。

    • NONE – ログ記録を無効にします。

ログ記録が有効になっている場合、Amazon RDS は、テーブルログのローテーションまたはログファイルの削除を定期的に実行します。これは、ログファイルが大きくなることでデータベースが使用できなくなったりパフォーマンスに影響する可能性を低く抑えるための予防措置です。ログ記録の FILE オプションと TABLE オプションでは、ローテーションと削除が次のように行われます。

  • FILE ログ記録が有効になっている場合、ログファイルの検査が 1 時間ごとに実行され、作成後 24 時間を超えた古いログファイルは削除されます。削除後、残りのログファイルの合計サイズが、DB インスタンスに割り当てられた領域の 2 パーセントというしきい値を超えている場合、ログファイルのサイズがしきい値以下になるまで、最も大きいログファイルから順に削除されます。

  • TABLE ログ記録が有効になっている場合は、テーブルログに使用されている領域が、割り当てられたストレージ領域の 20% を超えるか、すべてのログの合計サイズが 10 GB を超えると、24 時間ごとにログテーブルのローテーションが実行されます。DB インスタンスに使用されている領域が、DB インスタンスに割り当てられたストレージ領域の 90% を超えている場合は、ログのローテーションを実行するためのしきい値が小さくなります。テーブルログに使用されている領域が、割り当てられたストレージ領域の 10% を超えるか、すべてのログの合計サイズが 5 GB を超えると、ログテーブルのローテーションが実行されます。

    ログテーブルのローテーションが実行されると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルがすでに存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。バックアップのログテーブルは、必要に応じて照会することができます。mysql.general_log テーブルに対するバックアップのログテーブルは、mysql.general_log_backup という名前になります。mysql.slow_log テーブルに対するバックアップのログテーブルは、mysql.slow_log_backup という名前になります。

    mysql.general_log テーブルのローテーションは、mysql.rds_rotate_general_log プロシージャを呼び出すことで実行できます。mysql.slow_log テーブルのローテーションは、mysql.rds_rotate_slow_log プロシージャを呼び出すことで実行できます。

    データベースバージョンのアップグレード時にも、テーブルログのローテーションが実行されます。

Amazon RDS では、TABLE ログおよび FILE ログのローテーションが Amazon RDS イベントで記録され、ユーザーに通知が送信されます。

Amazon RDS コンソール、Amazon RDS API、Amazon RDS CLI、または AWS SDK からログを使用するには、log_output パラメーターを FILE に設定します。MariaDB エラーログと同様、これらのログファイルは 1 時間ごとにローテーションされます。直前 24 時間以内に生成されたログファイルが保持されます。

スロークエリと一般ログの詳細については、MariaDB のドキュメントの以下のトピックを参照してください。

ログファイルのサイズ

MariaDB のスロークエリログ、エラーログ、一般ログファイルのサイズは、DB インスタンスに割り当てられたストレージ領域の 2 パーセント以下に制約されます。 このしきい値を維持するために、ログは 1 時間ごとに自動的にローテーションされ、24 時間以上前の古いログファイルは削除されます。古いログファイルを削除した後、ログファイルの合計サイズがしきい値を超えている場合、ログファイルのサイズがしきい値以下になるまで、最も大きいログファイルから順に削除されます。

テーブルベースの MariaDB ログを管理する

DB パラメータグループを作成し、log_output サーバーパラメーターを TABLE に設定することで、DB インスタンス上のテーブルに一般ログとスロークエリログを書き込むことができます。その後、一般クエリは mysql.general_log テーブルに記録され、スロークエリは mysql.slow_log テーブルに記録されます。それらのテーブルに対してクエリを実行することでログの情報にアクセスできます。このログ記録を有効にすると、データベースに書き込まれるデータの量が増え、パフォーマンスが低下することがあります。

一般ログもスロークエリログもデフォルトで無効になっています。テーブルへのログ記録を有効にするには、general_logslow_query_log のサーバーパラメーターを 1 に設定する必要があります。

ログテーブルは、それぞれのログ記録アクティビティのパラメーターを 0 にリセットしてログ記録をオフにするまで、拡大し続けます。 大量のデータが長期にわたって蓄積されることがよくあり、割り当てストレージ領域の大部分を使い果たすことがあります。Amazon RDS では、ログテーブルを切り捨てることはできませんが、その内容を移動することはできます。テーブルのローテーションにより、その内容がバックアップテーブルに保存され、新しい空のログテーブルが作成されます。以下のコマンドラインプロシージャを使用して、ログテーブルを手動でローテーションされることができます。ここで表示されている PROMPT> はコマンドプロンプトです。

Copy
PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log;

以前のデータを完全に削除し、ディスク領域を再利用するには、該当するプロシージャを 2 回連続で呼び出します。

バイナリログ形式

Amazon RDS の MariaDB は行ベースおよび混合バイナリログ形式をサポートしています。ステートメントベースのバイナリログ形式はサポートしていません。デフォルトのバイナリログ形式は混合です。さまざまな MariaDB のバイナリログ形式の詳細については、MariaDB ドキュメントの「バイナリログ形式」を参照してください。

重要

バイナリログ形式を行ベースに設定すると、バイナリログファイルが巨大になることがあります。巨大なバイナリログファイルにより、DB インスタンスの使用可能なストレージの量が減ります。また、DB インスタンスの復元オペレーションの実行にかかる時間が長くなることがあります。

MariaDB バイナリログ形式を設定するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. DB パラメータグループを作成するの指示に従って新しいパラメータグループを作成します。

  3. 新しいパラメータグループを選択し、続いて [詳細ページに移動] アイコン行を選択します。

  4. [Edit Parameters] を選択して、DB パラメータグループのパラメーターを変更します。

  5. binlog_format パラメーターを、選択したバイナリログ形式 [MIXED] または [ROW] に設定します。

  6. [Save Changes] を選択して、更新を DB パラメータグループに保存します。

DB パラメータグループの詳細については、「DB パラメータグループを使用する」を参照してください。

MariaDB バイナリログにアクセスする

mysqlbinlog ユーティリティを使用して、バイナリログをテキスト形式で MariaDB DB インスタンスからダウンロードできます。バイナリログは、お使いのコンピュータにダウンロードされます。mysqlbinlog ユーティリティの使用の詳細については、MariaDB ドキュメントの「mysqlbinlog を使用する」を参照してください。

Amazon RDS インスタンスに対して mysqlbinlog ユーティリティを実行するには、以下のオプションを使用します。

  • --read-from-remote-server オプションを指定します。

  • --host: インスタンスのエンドポイントからの DNS 名を指定します。

  • --port: インスタンスによって使用されるポートを指定します。

  • --user: レプリケーションスレーブアクセス許可を付与された MariaDB ユーザーを指定します。

  • --password: ユーザーのパスワードを指定するか、パスワード値を省略します。省略した場合、ユーティリティによってパスワードの入力を求められます。

  • --result-file:出力を受け取るローカルファイルを指定します。

  • 1 つ以上のバイナリログファイルの名前を指定します。使用可能なログのリストを取得するには、SQL コマンド SHOW BINARY LOGS を使用します。

mysqlbinlog オプションの詳細については、MariaDB ドキュメントの「mysqlbinlog オプション」を参照してください。

次に例を示します。

Linux、OS X、Unix の場合:

Copy
mysqlbinlog \ --read-from-remote-server \ --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password <password> \ --result-file=/tmp/binlog.txt

Windows の場合:

Copy
mysqlbinlog ^ --read-from-remote-server ^ --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password <password> ^ --result-file=/tmp/binlog.txt

Amazon RDS では、通常、バイナリログはできる限り早く消去されますが、mysqlbinlog によってアクセスされるバイナリログはインスタンスで保持される必要があります。RDS でバイナリログを保持する時間数を指定するには、mysql.rds_set_configuration ストアドプロシージャを使用して、ログのダウンロードするのに十分な期間を指定します。保持期間を設定したら、DB インスタンスのストレージ使用状況をモニタリングして、保持されたバイナリログに必要以上の容量が使用されないようにします。

以下の例では、保持期間を 1 日に設定しています。

Copy
call mysql.rds_set_configuration('binlog retention hours', 24);

現在の設定を表示するには、mysql.rds_show_configuration ストアドプロシージャを使用します。

Copy
call mysql.rds_show_configuration;

バイナリログの注釈

MariaDB DB インスタンスでは、Annotate_rows イベントを使用して列イベントを引き起こした SQL クエリのコピーで行イベントに注釈を追加できます。 この方法では、MySQL バージョン 5.6 移行で DB インスタンスの binlog_rows_query_log_events パラメーターを有効にするのと同様の機能を提供します。

カスタムパラメータグループを作成し binlog_annotate_row_events パラメーターを 1 に設定することで、バイナリログの注釈をグローバルに有効にすることができます。SET SESSION binlog_annotate_row_events = 1 を呼び出すことで、セッションレベルで注釈を有効化することもできます。バイナリログがスレーブインスタンスで有効になっている場合は、replicate_annotate_row_events を使用してバイナリログの注釈をスレーブインスタンスにレプリケートします。これらの設定に特別な権限を使用する必要はありません。

次に MariaDB での行ベースの処理の例を示します。行ベースログの使用は、トランザクションの分離レベルをコミット済み読み取りに設定することで起動されます。

Copy
CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN INSERT INTO square(x, y) VALUES(5, 5 * 5); COMMIT;

注釈なしのトランザクションのバイナリログエントリは次のようになります。

Copy
BEGIN /*!*/; # at 1163 # at 1209 #150922 7:55:57 server id 1855786460 end_log_pos 1209 Table_map: `test`.`square` mapped to number 76 #150922 7:55:57 server id 1855786460 end_log_pos 1247 Write_rows: table id 76 flags: STMT_END_F ### INSERT INTO `test`.`square` ### SET ### @1=5 ### @2=25 # at 1247 #150922 7:56:01 server id 1855786460 end_log_pos 1274 Xid = 62 COMMIT/*!*/;

次のステートメントでは、同じのトランザクションのセッションレベルの注釈を有効にし、トランザクションをコミットした後に無効にしています。

Copy
CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SET SESSION binlog_annotate_row_events = 1; BEGIN; INSERT INTO square(x, y) VALUES(5, 5 * 5); COMMIT; SET SESSION binlog_annotate_row_events = 0;

注釈ありのトランザクションのバイナリログエントリは次のようになります。

Copy
BEGIN /*!*/; # at 423 # at 483 # at 529 #150922 8:04:24 server id 1855786460 end_log_pos 483 Annotate_rows: #Q> INSERT INTO square(x, y) VALUES(5, 5 * 5) #150922 8:04:24 server id 1855786460 end_log_pos 529 Table_map: `test`.`square` mapped to number 76 #150922 8:04:24 server id 1855786460 end_log_pos 567 Write_rows: table id 76 flags: STMT_END_F ### INSERT INTO `test`.`square` ### SET ### @1=5 ### @2=25 # at 567 #150922 8:04:26 server id 1855786460 end_log_pos 594 Xid = 88 COMMIT/*!*/;