

# Aurora MySQL データベースのログ記録
<a name="aurora-mysql-troubleshooting-logging"></a>

Aurora MySQL ログは、データベースのアクティビティとエラーに関する重要な情報を提供します。これらのログを有効にすることで、問題の特定とトラブルシューティング、データベースパフォーマンスの把握、データベースアクティビティの監査が可能になります。データベースのパフォーマンスと可用性を最適化するために、すべての Aurora MySQL DB インスタンスでこれらのログを有効にすることをお勧めします。次のタイプのログを有効にできます。各ログには、データベース処理への影響を明らかにするのに役立つ特定の情報が含まれています。
+ エラー - Aurora MySQL ではスタートアップ時、シャットダウン時、およびエラー検出時にのみ、エラーログへの書き込みが行われます。DB インスタンスでは、新しいエントリがエラーログに書き込まれないまま、数時間または数日が経過することがあります。最近のエントリがない場合、それは、サーバーにログエントリになり得るエラーが発生しなかったためです。エラーロギングはデフォルトで有効になっています。詳細については、「[Aurora MySQL エラーログ](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Errorlog)」を参照してください。
+ 一般 — 一般ログには、データベースエンジンによって実行されたすべての SQL ステートメントを含む、データベースアクティビティに関する詳細情報が含まれます。一般的なロギングの有効化とロギングパラメータの設定の詳細については、「[Aurora MySQL のスロークエリと一般ログ](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog)」、および MySQL ドキュメントの「[一般クエリログ](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)」を参照してください。
**注記**  
一般ログは非常に大きくなり、ストレージを消費する可能性があります。詳細については、「[Aurora MySQL のログのローテーションと保持](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.AMS.LogFileSize.retention)」を参照してください。
+ スロークエリ — スロークエリログは、実行に [long\_query\_time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_long_query_time)​ 秒を超える時間がかかり、検証に [min\_examined\_row\_limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_min_examined_row_limit) 行以上を要した SQL ステートメントで構成されています。スロークエリログを使用すると、実行に時間がかかるため最適化の対象となるクエリを見つけることができます。

  `long_query_time` のデフォルト値は 10 (秒) です。高い値から始めて最も遅いクエリを特定し、その後微調整することをおすすめします。

  `log_slow_admin_statements` や `log_queries_not_using_indexes` などの関連パラメータを使用することもできます。`rows_examined` と `rows_returned` を比較します。`rows_examined` が `rows_returned` よりはるかに大きい場合は、それらのクエリがブロックする可能性があります。

  Aurora MySQL バージョン 3 では、`log_slow_extra` を有効にしてより詳細な情報を取得することができます。詳細については、MySQL ドキュメントの「[スロークエリログの内容](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html#slow-query-log-contents)」を参照してください。クエリ実行をインタラクティブにデバッグするようにセッションレベルで `long_query_time` を変更することもできます。これは `log_slow_extra` がグローバルに有効になっている場合に特に便利です。

  スロークエリロギングの有効化とロギングパラメータの設定の詳細については、「[Aurora MySQL のスロークエリと一般ログ](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog)」、および MySQL ドキュメントの「[スロークエリログ](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)」を参照してください。
+ 監査 — 監査ログはデータベースのアクティビティをモニタリングして記録します。Aurora MySQL の監査ログは、高度な監査と呼ばれます。高度な監査を有効にするには、特定の DB クラスターパラメータを設定します。詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。
+ バイナリ — バイナリログ (binlog) には、テーブル作成操作やテーブルデータへの変更など、データベースの変更を説明するイベントが含まれます。また、行ベースのロギングが使用されていない限り、変更を加えた可能性のあるステートメント (行と一致しない [DELETE](https://dev.mysql.com/doc/refman/8.0/en/delete.html) など) のイベントも含まれます。バイナリログには、各ステートメントがデータの更新にかかった時間に関する情報も含まれています。

  バイナリロギングを有効にしてサーバーを実行させると、パフォーマンスがわずかに低下します。ただし、一般に、レプリケーションや復元操作を設定できるバイナリログの利点は、このわずかなパフォーマンスの低下よりも上回ります。
**注記**  
Aurora MySQL では、復元操作にバイナリロギングは必要ありません。

  バイナリロギングの有効化とバイナリログ形式の設定の詳細については、「[シングル AZ データベースの Aurora MySQL バイナリログの設定](USER_LogAccess.MySQL.BinaryFormat.md)」、MySQL ドキュメントの「[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)」を参照してください。

エラーログ、一般ログ、スローログ、クエリログ、監査ログを Amazon CloudWatch Logs にパブリッシュできます。詳細については、「[Amazon CloudWatch Logs へのデータベースログの発行](USER_LogAccess.Procedural.UploadtoCloudWatch.md)」を参照してください。

スローログ、一般ログ、バイナリログファイルを要約するもう 1 つの便利なツールは [pt-query-digest](https://docs.percona.com/percona-toolkit/pt-query-digest.html) です。