# Amazon DevOps Guru のプロアクティブインサイトによる Aurora MySQL のチューニング
DevOps Guru のプロアクティブインサイトは、Aurora MySQL DB クラスターで既知の問題が発生する前に検出します。DevOps Guru では、次のことができます。
+ データベース構成を一般的な推奨設定と照合することで、データベースに関する多くの一般的な問題を防ぎます。
+ 未チェックのままにしておくと、後で大きな問題につながる可能性があるフリート内の重大な問題について警告します。
+ 新しく発見された問題について警告します。
すべてのプロアクティブインサイトには、問題の原因の分析と是正措置の推奨事項が含まれています。
**Topics**
+ [InnoDB 履歴リストの長さが大幅に増加しました](proactive-insights.history-list.md)
+ [データベースはディスク上にテンポラリテーブルを作成している](proactive-insights.temp-tables.md)
# InnoDB 履歴リストの長さが大幅に増加しました
*date* を過ぎると、行変更の履歴リストが大幅に増加し、*db-instance* では最大 *length* になりました。この増加は、クエリとデータベースのシャットダウンパフォーマンスに影響します。
**Topics**
+ [サポート対象エンジンバージョン](#proactive-insights.history-list.context.supported)
+ [Context](#proactive-insights.history-list.context)
+ [この問題の考えられる原因](#proactive-insights.history-list.causes)
+ [アクション](#proactive-insights.history-list.actions)
+ [関連するメトリクス](#proactive-insights.history-list.metrics)
## サポート対象エンジンバージョン
このインサイト情報は、Aurora MySQL のすべてのバージョンでサポートされています。
## Context
InnoDB トランザクションシステムは、マルチバージョン同時実行制御 (MVCC) を維持します。行が変更されると、変更中のデータの修正前のバージョンが、undo レコードとして undo ログに保存されます。すべての undo レコードには、以前の redo レコードへの参照があり、リンクリストを形成します。
InnoDB 履歴リストは、コミットされたトランザクションの undo ログのグローバルリストです。MySQL は、トランザクションで履歴が不要になったときに、履歴リストを使用してレコードとログページを削除します。履歴リストの長さは、履歴リスト内の変更を含む undo ログの総数です。各ログには、1 つ以上の変更が含まれます。InnoDB 履歴リストの長さが大きくなりすぎると、古い行バージョンが多数存在することになり、クエリやデータベースのシャットダウンが遅くなります。
## この問題の考えられる原因
履歴リストが長くなる一般的な原因には次のものがあります。
+ 実行時間の長いトランザクション (読み取りまたは書き込み)
+ 書き込み負荷が高い
## アクション
インサイトの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [InnoDB 履歴リストが減るまで、データベースのシャットダウンを伴う操作を開始しない](#proactive-insights.history-list.actions.no-shutdown)
+ [長時間実行されるトランザクションを特定して終了する](#proactive-insights.history-list.actions.long-txn)
+ [Performance Insights を使用して、上位ホストと上位ユーザーを特定します。](#proactive-insights.history-list.actions.top-PI)
### InnoDB 履歴リストが減るまで、データベースのシャットダウンを伴う操作を開始しない
InnoDB 履歴リストが長くなるとデータベースのシャットダウンが遅くなるため、データベースシャットダウンを伴う操作を開始する前にリストサイズを小さくしてください。これらの操作には、データベースのメジャーバージョンのアップグレードが含まれます。
### 長時間実行されるトランザクションを特定して終了する
`information_schema.innodb_trx` クエリを実行すると、実行時間の長いトランザクションを見つけることができます。
**注記**
リードレプリカで長時間実行されるトランザクションも必ず探してください。
**長時間実行されるトランザクションを特定して終了するには**
1. SQL クライアントで次のクエリを実行します。
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. ストアドプロシージャ [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) を使用して、長時間実行している各トランザクションを終了します。
### Performance Insights を使用して、上位ホストと上位ユーザーを特定します。
トランザクションを最適化して、変更された多数の行がすぐにコミットされるようにします。
## 関連するメトリクス
このインサイトに関連するメトリクスは次のとおりです。
+ `trx_rseg_history_len` – このカウンターメトリクスは、Performance Insights および `INFORMATION_SCHEMA.INNODB_METRICS` テーブルで表示できます。詳細については、MySQL ドキュメントの「[InnoDB INFORMATION\$1SCHEMA metrics table](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html)」を参照してください。
+ `RollbackSegmentHistoryListLength` - この Amazon CloudWatch メトリクスは、コミットされたトランザクションが削除とマークされたレコードを記録する UNDO ログを測定します。これらのレコードは、InnoDB のパージオペレーションによって処理されるようにスケジュールされています。メトリクス `trx_rseg_history_len` の値は `RollbackSegmentHistoryListLength` と同じです。
+ `PurgeBoundary` – InnoDB パージ可能領域の最後のトランザクション番号。この CloudWatch メトリクスが長く進まない場合は、InnoDB パージが長時間実行中のトランザクションによってブロックされていることを示す良い目安となります。調査するには、Aurora MySQL DB クラスターのアクティブなトランザクション数を確認します。このメトリクスは、Aurora MySQL バージョン 2.11 以降およびバージョン 3.08 以降で利用できます。
+ `PurgeFinishedPoint` – InnoDB パージが実行される領域の最後のトランザクション番号。この CloudWatch メトリクスは、InnoDB パージの進行速度を調べるのに役立ちます。このメトリクスは、Aurora MySQL バージョン 2.11 以降およびバージョン 3.08 以降で利用できます。
+ `TransactionAgeMaximum` – 最も古いアクティブな実行中トランザクションの経過時間。この CloudWatch メトリクスは、Aurora MySQL バージョン 3.08 以降でのみ使用できます。
+ `TruncateFinishedPoint` – 切り捨てを元に戻す操作が実行される最後のトランザクション番号。この CloudWatch メトリクスは、Aurora MySQL バージョン 2.11 以降、およびバージョン 3.08 以降でのみ使用できます。
CloudWatch のメトリクスの詳細については、「[Amazon Aurora のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)」を参照してください。
# データベースはディスク上にテンポラリテーブルを作成している
最近のディスク上のテンポラリテーブルの使用率が大幅に増加し、最大 *percentage* に達しています。データベースは、1 秒あたり約 *number* 個のテンポラリテーブルを作成しています。これにより、パフォーマンスに影響が及び、*db-instance* に対するディスク操作が増える可能性があります。
**Topics**
+ [サポート対象エンジンバージョン](#proactive-insights.temp-tables.context.supported)
+ [Context](#proactive-insights.temp-tables.context)
+ [この問題の考えられる原因](#proactive-insights.temp-tables.causes)
+ [アクション](#proactive-insights.temp-tables.actions)
+ [関連するメトリクス](#proactive-insights.temp-tables.metrics)
## サポート対象エンジンバージョン
このインサイト情報は、Aurora MySQL のすべてのバージョンでサポートされています。
## Context
MySQL サーバーがクエリの処理中に内部一時テーブルを作成する必要がある場合があります。Aurora MySQL は、内部一時テーブルをメモリに保持できます。このテーブルは、TempTable または MEMORY ストレージエンジンで処理するか、InnoDB によってディスクに保存したりできます。詳細については、*MySQL リファレンスマニュアル*の「[Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html)」(MySQL での内部一時テーブルの使用) を参照してください。
## この問題の考えられる原因
ディスク上の一時テーブルの増加は、複雑なクエリの使用を示しています。設定されたメモリが一時テーブルをメモリに格納するには不十分な場合、Aurora MySQL はテーブルをディスク上に作成します。これにより、パフォーマンスに影響が及び、ディスク操作が増える可能性があります。
## アクション
インサイトの原因に応じて、異なるアクションをお勧めします。
+ Aurora MySQL バージョン 3 の場合、TempTable ストレージエンジンを使用することをお勧めします。
+ 必要な列のみを選択して、クエリを最適化して、返されるデータを減らします。
すべての `statement` 計測が有効で時間制限のある状態でパフォーマンススキーマを有効にすると、`SYS.statements_with_temp_tables` クエリを実行して、一時テーブルを使用するクエリのリストを取得できます。詳細については、MySQL ドキュメントの「[Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html)」(sys スキーマを使用するための前提条件) を参照してください。
+ ソートやグループ化の操作に関係する列にインデックスを付けることを検討してください。
+ `BLOB` および `TEXT` 列を避けるように、クエリを書き直します。これらの列は常にディスクを使用します。
+ `tmp_table_size` および `max_heap_table_size` データベースパラメータをチューニングします。
これらのパラメータのデフォルト値は 16 MiB です。メモリ内一時テーブルに MEMORY ストレージエンジンを使用する場合、最大サイズは、`tmp_table_size` または `max_heap_table_size` 値のいずれか小さい方によって定義されます。この最大サイズに達すると、MySQL はインメモリ内部一時テーブルを InnoDB オンディスク内部一時テーブルに自動的に変換します。詳細については、「[Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)」(Amazon RDS for MySQL および Amazon Aurora MySQL で TempTable ストレージ エンジンを使用する) を参照してください。
**注記**
CREATE TABLE を使用して MEMORY テーブルを明示的に作成する場合、テーブルをどれだけ大きくできるかを決めるのは `max_heap_table_size` 変数だけです。また、オンディスク形式への変換もありません。
## 関連するメトリクス
以下の Performance Insights メトリクスがこのインサイトに関連しています。
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
詳細については、MySQL ドキュメントの「[Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables)」を参照してください。