# Aurora MySQL データベースのログファイル
<a name="USER_LogAccess.Concepts.MySQL"></a>

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

ファイルベースのデータベースログの表示、ダウンロード、モニタリングの詳細については、「[Amazon Aurora ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。

**Topics**
+ [Aurora MySQL データベースログの概要](USER_LogAccess.MySQL.LogFileSize.md)
+ [テーブルへの Aurora MySQL ログ出力の送信](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [シングル AZ データベースの Aurora MySQL バイナリログの設定](USER_LogAccess.MySQL.BinaryFormat.md)
+ [MySQL バイナリログにアクセスする](USER_LogAccess.MySQL.Binarylog.md)

# Aurora MySQL データベースログの概要
<a name="USER_LogAccess.MySQL.LogFileSize"></a>

次の種類の Aurora MySQL ログファイルをモニタリングできます。
+ エラーログ
+ スロークエリログ
+ 全般ログ
+ 監査ログ
+ インスタンスログ
+ IAM データベース認証エラーログ

Aurora MySQL のエラーログはデフォルトで生成されます。DB パラメータグループにパラメータを設定することで、低速クエリと一般ログを生成できます。

**Topics**
+ [Aurora MySQL エラーログ](#USER_LogAccess.MySQL.Errorlog)
+ [Aurora MySQL のスロークエリと一般ログ](#USER_LogAccess.MySQL.Generallog)
+ [Aurora MySQL の監査ログ](#ams-audit-log)
+ [Aurora MySQL インスタンスログ](#ams-instance-log)
+ [Aurora MySQL のログのローテーションと保持](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Amazon CloudWatch Logs への Aurora MySQL ログの発行](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)

## Aurora MySQL エラーログ
<a name="USER_LogAccess.MySQL.Errorlog"></a>

Aurora MySQL は `mysql-error.log` ファイルにエラーを書き込みます。各ログファイルには、それぞれ生成された時間 (UTC) がファイル名に付加されます。ログファイルには、タイムスタンプも付加され、ログエントリがいつ書き込まれたかを調べるために役立ちます。

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

設計上、エラーログはフィルタリングされ、エラーなどの予期しないイベントのみが表示されます。ただし、エラーログには、クエリの進行状況など、表示されない追加のデータベース情報も含まれています。したがって、実際のエラーがなくても、継続的なデータベースアクティビティのためにエラーログのサイズが増加する可能性があります。また、AWS マネジメントコンソール のエラーログには特定のサイズがバイト単位またはキロバイト単位で表示されている場合がありますが、ダウンロードすると 0 バイトになる場合があります。

Aurora MySQL は 5 分ごとに `mysql-error.log` をディスクに書き込みます。ログの内容が `mysql-error-running.log` に追加されます。

Aurora MySQL は `mysql-error-running.log` ファイルを 1 時間ごとにローテーションします。

**注記**  
ログの保持期間は、Amazon RDS と Aurora で異なります。

## Aurora MySQL のスロークエリと一般ログ
<a name="USER_LogAccess.MySQL.Generallog"></a>

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

以下のリストに示すパラメータを使用して Aurora MySQL のログ記録を制御できます。
+ `slow_query_log`: スロークエリログを作成するには、1 に設定します。デフォルトは 0 です。
+ `general_log`: 一般ログを作成するには、1 に設定します。デフォルトは 0 です。
+ `long_query_time`: ファストクエリがスロークエリログに記録されないようにするために、ログに記録されるクエリの最短実行時間の値を秒単位で指定します。デフォルトは 10 秒で、最小値は 0 です。log\$1output = FILE の場合は、マイクロ秒の精度になるように、浮動小数点値を指定できます。log\$1output = TABLE の場合は、秒の精度になるように、整数値を指定する必要があります。実行時間が `long_query_time` の値を超えたクエリのみがログに記録されます。例えば、`long_query_time` を 0.1 に設定すると、実行時間が 100 ミリ秒未満のすべてのクエリはログに記録されなくなります。
+ `log_queries_not_using_indexes`: インデックスを使用しないすべてのクエリをスロークエリログに記録するには、1 に設定します。インデックスを使用しないクエリは、その実行時間が `long_query_time` パラメータの値未満であってもログに記録されます。デフォルトは 0 です。
+ `log_output option`: `log_output` パラメータに指定できるオプションは、次のとおりです。
  + **TABLE** - 一般クエリを `mysql.general_log` テーブルに、スロークエリを `mysql.slow_log` テーブルに書き込みます。
  + **FILE** - 一般クエリログとスロークエリログの両方をファイルシステムに書き込みます。
  + **NONE** - ログ記録を無効にします。

  Aurora MySQL バージョン 2 および 3 の場合、`log_output` のデフォルトは `FILE` です。

スロークエリデータを Amazon CloudWatch Logs に表示するには、次の条件を満たす必要があります。
+ スロークエリログを含むように CloudWatch Logs を設定する必要があります。
+ `slow_query_log` を有効にする必要があります。
+ `log_output`/ を に設定する必要があります。`FILE`
+ クエリに要する時間が、`long_query_time` に設定された時間よりも長い必要があります。

スロークエリと一般ログの詳細については、MySQL ドキュメントの以下のトピックを参照してください。
+ [スロークエリログ](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [一般クエリログ](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)

## Aurora MySQL の監査ログ
<a name="ams-audit-log"></a>

Aurora MySQL の監査ログは、高度な監査と呼ばれます。高度な監査を有効にするには、特定の DB クラスターパラメータを設定します。詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。

## Aurora MySQL インスタンスログ
<a name="ams-instance-log"></a>

Aurora は、自動一時停止が有効になっている DB インスタンスに対して別のログファイルを作成します。この instance.log ファイルは、これらの DB インスタンスが想定どおりに一時停止できなかった理由を記録します。インスタンスログファイルの動作と Aurora の自動一時停止機能の詳細については、「[Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log)」を参照してください。

## Aurora MySQL のログのローテーションと保持
<a name="USER_LogAccess.AMS.LogFileSize.retention"></a>

ログ記録が有効になっている場合、Amazon Aurora は、ログファイルの削除を定期的に実行します。これは、ログファイルが大きくなることでデータベースが使用できなくなったりパフォーマンスに影響する可能性を低く抑えるための予防措置です。Aurora MySQL は、次のようにローテーションと削除を処理します。
+ Aurora MySQL エラーログファイルのサイズは、DB インスタンスのローカルストレージの 15 パーセント以下に制約されます。このしきい値を維持するために、ログは 1 時間ごとに自動的にローテーションされます。Aurora MySQL は 30 日後、またはディスク領域の 15 % が使用されると、ログを削除します。古いログファイルを削除した後、ログファイルの合計サイズがしきい値を超えている場合、ログファイルのサイズがしきい値以下になるまで、最も古いログファイルから順に削除されます。
+ Aurora MySQL は、24 時間後、またはストレージの 15% が消費されると、監査、一般、および低速クエリログを削除します。
+ `FILE` ログ記録が有効になっている場合、一般ログとスロークエリログファイルの検査が 1 時間ごとに実行され、作成後 24 時間を超えた古いログファイルは削除されます。場合によっては、削除後の残りのログファイルの合計サイズが、DB インスタンスのローカル領域のしきい値である 15 % を超えることがあります。この場合、ログファイルのサイズがしきい値以下になるまで、最も古いログファイルから順に削除されます。
+ `TABLE` ログ記録が有効化されている場合、ログテーブルはローテーションまたは削除されません。結合されたすべてのログのサイズが大きすぎると、ログテーブルは切り捨てられます。`low storage` イベントカテゴリにサブスクライブして、ログテーブルが手動でローテーションされたり削除されたりして領域が解放されたときに通知を受け取ることができます。詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。

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

  ログテーブルをローテーションすると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルが既に存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。バックアップのログテーブルは、必要に応じて照会することができます。`mysql.general_log` テーブルに対するバックアップのログテーブルは、`mysql.general_log_backup` という名前になります。`mysql.slow_log` テーブルに対するバックアップのログテーブルは、`mysql.slow_log_backup` という名前になります。
+ Aurora MySQL 監査ログは、ファイルサイズが 100 MB に達するとローテーションされ、24 時間後に削除されます。
+ Amazon RDS は、10 MB を超える IAM データベース認証エラーログファイルをローテーションします。Amazon RDS は、5 日以上経過しているか、100 MB を超える IAM データベース認証エラーログファイルを削除します。

Amazon RDS コンソール、Amazon RDS API、Amazon RDS CLI、または AWS SDK からログを使用するには、`log_output` パラメータを FILE に設定します。Aurora MySQL エラーログと同様、これらのログファイルは 1 時間ごとにローテーションされます。直前 24 時間以内に生成されたログファイルが保持されます。Amazon RDS と Aurora で保持期間が異なる点に注意してください。​

## Amazon CloudWatch Logs への Aurora MySQL ログの発行
<a name="USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs"></a>

Aurora MySQL DB クラスターを設定して、ログデータを Amazon CloudWatch Logs のロググループに発行することができます。CloudWatch Logs を使用すると、ログデータのリアルタイム分析や、CloudWatch を使用したアラームの作成、メトリクスの表示を行うことができます。CloudWatch Logs を使用して、耐久性の高いストレージにログレコードを格納できます。詳しくは、「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)」を参照してください。

# テーブルへの Aurora MySQL ログ出力の送信
<a name="Appendix.MySQL.CommonDBATasks.Logs"></a>

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

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

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

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

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

# シングル AZ データベースの Aurora MySQL バイナリログの設定
<a name="USER_LogAccess.MySQL.BinaryFormat"></a>

*バイナリログ*は、Aurora MySQL サーバーインスタンスで行われたデータ変更に関する情報を含む、一連のログファイルです。バイナリログには、以下のような情報が含まれています。
+ テーブルの作成や行の変更など、データベースの変更が記述されたイベント
+ データを更新した各ステートメントの実行時間に関する情報
+ データを更新する可能性があったものの、それが実行されていないステートメントのイベント

バイナリログには、レプリケーション中に送信されるステートメントが記録されます。また、一部のリカバリオペレーションにもバイナリログが必要です。詳細については、MySQL ドキュメントの「[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)」を参照してください。

バイナリログは、プライマリ DB インスタンスからのみアクセスでき、レプリカからはアクセスできません。

 Amazon Aurora の MySQL では、*行ベース*、*ステートメントベース*、および*混合*のバイナリログ形式がサポートされています。特定バイナリログ形式が必要でない場合は、混合形式を使用することをお勧めします。Aurora MySQL の各種バイナリログ形式の詳細については、MySQL ドキュメントの「[Binary logging formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html)」を参照してください。

レプリケーションを使用する予定の場合は、バイナリログ記録形式が重要です。ソースに記録されてレプリケーションターゲットに送信されるデータ変更記録が決定されるからです。レプリケーション用のさまざまなバイナリログ記録形式の利点と欠点についての詳細は、MySQL ドキュメントの「[Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)」を参照してください。

**重要**  
MySQL 8.0.34 では、`binlog_format` パラメータが廃止されました。以降の MySQL バージョンでは、このパラメータを削除し、行ベースのレプリケーションのみをサポートする予定です。そのため、新しい MySQL レプリケーション設定には行ベースのログ記録を使用することをお勧めします。詳細については、MySQL ドキュメントの「[binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format)」を参照してください。  
MySQL バージョン 8.0 および 8.4 は、パラメータ `binlog_format` を受け入れます。このパラメータを使用すると、MySQL は非推奨警告を発行します。今後のメジャーリリースで、MySQL はパラメータ `binlog_format` を削除します。  
ステートメントベースのレプリケーションは、ソース DB クラスターとリードレプリカの間の不整合の原因になります。詳細については、MySQL ドキュメントの「[バイナリログ作成における安全なステートメントと安全でないステートメントの判断](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)」を参照してください。  
バイナリログを有効にすると、DB クラスターへの書き込みディスク I/O 操作の回数が増えます。```VolumeWriteIOPs` CloudWatch メトリクスを使用して、IOPS の使用状況をモニタリングできます。

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

1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、**[Parameter groups]** (パラメータグループ) を選択します。

1. 変更する DB クラスターに関連付ける DB クラスターのパラメータグループを選択します。

   デフォルトのパラメータグループを変更することはできません。DB クラスターがデフォルトのパラメータグループを使用している場合、新しいパラメータグループを作成し DB クラスターと関連付けます。

   パラメータグループの詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。

1. **[アクション]** から **[編集]** を選択します。

1. `binlog_format` パラメータを、選択したバイナリログ形式 (`ROW`、`STATEMENT`、または `MIXED`) に設定します。また、`OFF` の値を使用して、バイナリログ記録をオフにすることもできます。
**注記**  
DB クラスターパラメータグループで `binlog_format` を `OFF` に設定すると、`log_bin` セッション変数が無効になります。これにより、Aurora MySQL DB クラスターのバイナリログ記録が無効になり、`binlog_format` セッション変数がデータベースのデフォルト値の `ROW` にリセットされます。

1. [**変更の保存**] を選択して、更新を DB クラスターパラメータグループに保存します。

これらのステップを実行した後、変更を適用するには、DB クラスターのライターインスタンスを再起動する必要があります。Aurora MySQL バージョン 2.09 以前では、ライターインスタンスを再起動すると、DB クラスター内のすべてのリーダーインスタンスも再起動されます。Aurora MySQL バージョン 2.10 以降では、すべてのリーダーインスタンスを手動で再起動する必要があります。詳細については、「[Amazon Aurora DB クラスターまたは Amazon Aurora DB インスタンスの再起動](USER_RebootCluster.md)」を参照してください。

**重要**  
DB クラスターパラメータグループを変更すると、そのパラメータグループを使用するすべての DB クラスターに影響を与えます。AWS リージョン内の異なる Aurora MySQL DB クラスターに異なるバイナリログ形式を指定する場合、DB クラスターは異なる DB クラスターパラメータグループを使用する必要があります。これらのパラメータグループは、さまざまなログ形式を識別します。各 DB クラスターに適切な DB クラスターパラメータグループを割り当てます。Aurora MySQL パラメータの詳細については、「[Aurora MySQL 設定パラメータ](AuroraMySQL.Reference.ParameterGroups.md)」を参照してください。

# MySQL バイナリログにアクセスする
<a name="USER_LogAccess.MySQL.Binarylog"></a>

mysqlbinlog ユーティリティを使用して、RDS for MySQL DB インスタンスからバイナリログをダウンロードまたはストリーミングできます。バイナリログはローカルコンピュータにダウンロードされ、mysql ユーティリティを使用してログの再生などの操作を実行できます。mysqlbinlog ユーティリティの使用の詳細については、MySQL ドキュメントの「[バイナリログファイルのバックアップのための mysqlbinlog の使用](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html)」を参照してください。

Amazon RDS インスタンスに対して mysqlbinlog ユーティリティを実行するには、以下のオプションを使用します。
+ `--read-from-remote-server` – 必須。
+ `--host` - インスタンスのエンドポイントからの DNS 名。
+ `--port` - インスタンスによって使用されるポート。
+ `--user` – `REPLICATION SLAVE` アクセス許可を付与された MySQL ユーザー。
+ `--password` - MySQL ユーザーのパスワード。パスワード値を省略省略した場合、ユーティリティによってパスワードの入力を求められます。
+ `--raw` — バイナリ形式のファイルをダウンロードします。
+ `--result-file` - raw 出力を受け取るローカルファイル。
+ `--stop-never` — バイナリログファイルをストリーミングします。
+ `--verbose` — `ROW` binlog 形式を使用するとき、このオプションを含めると、行イベントが疑似 SQL ステートメントとして表示されます。`--verbose` オプションの詳細については、MySQL ドキュメントの「[mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html)」(mysqlbinlog の行イベントの表示) を参照してください。
+ 1 つ以上のバイナリログファイルの名前を指定します。使用可能なログのリストを取得するには、SQL コマンド `SHOW BINARY LOGS` を使用します。

mysqlbinlog のオプションの詳細については、MySQL ドキュメントの「[mysqlbinlog - バイナリログファイルを処理するためのユーティリティ](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html)」を参照してください。

以下の例では、mysqlbinlog ユーティリティの使用方法を示します。

Linux、macOS、Unix の場合:

```
mysqlbinlog \
    --read-from-remote-server \
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
    --port=3306  \
    --user ReplUser \
    --password \
    --raw \
    --verbose \
    --result-file=/tmp/ \
    binlog.00098
```

Windows の場合:

```
mysqlbinlog ^
    --read-from-remote-server ^
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^
    --port=3306  ^
    --user ReplUser ^
    --password ^
    --raw ^
    --verbose ^
    --result-file=/tmp/ ^
    binlog.00098
```

mysqlbinlog ユーティリティがバイナリログにアクセスするには、バイナリログが DB インスタンスで利用可能な状態である必要があります。可用性を確保するには、[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) ストアドプロシージャを使用して、ログをダウンロードできる十分な期間を指定します。この設定を行わないと、Amazon RDS はバイナリログをできるだけ早く消去するため、mysqlbinlog ユーティリティが取得するバイナリログにギャップが生じます。

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

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

現在の設定を表示するには、[mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration) ストアドプロシージャを使用します。

```
call mysql.rds_show_configuration;
```