Amazon Relational Database Service (Amazon RDS) for MySQL または Amazon Aurora MySQL-Compatible DB インスタンスでメジャーバージョンのアップグレードが行われました。その結果、クエリのパフォーマンスが低下し、CPU 使用率が増加しています。
解決策
前提条件:
診断ミスを避けるために、トラブルシューティングのワークフローを適切に構成し、AWS ツールとサービスを使用すること。詳細については、次の記事を参照してください。
アップグレード特有の問題を確認する
インスタンスのアップグレード時に、そのアップグレードが原因でインスタンスから特定の機能が削除される可能性があります (例: Aurora MySQL 互換 5.7 から Aurora MySQL 互換 8.0)。
インスタンスが非推奨機能を使用している場合、インスタンスのパフォーマンスに問題が発生する可能性があります。現在のインスタンスバージョンが、ワークロードに影響する非推奨機能を使用しているかどうかを確認するには、Amazon Aurora MySQL 互換のリリースノートを参照してください。または、MySQL のウェブサイトで MySQL 8.0 リリースノートを参照してください。
次のシナリオ例では、Aurora MySQL 互換 5.7 クラスターをAurora MySQL 互換 8.0 にアップグレードしています。アップグレード後のクエリ、実行計画、ワークロードパターンは同じですが、ライターインスタンスの CPU 消費は倍増します。
この問題をトラブルシューティングするために、Amazon RDS for MySQL または Aurora MySQL 互換クラスターに関連するメトリクスをレビューします。発生した問題に応じて、クラスターの関連するメトリクスを従来のバージョンとアップグレード後のバージョンで比較します。
Aurora MySQL 互換 5.7 のメトリクス例:
SHOW GLOBAL STATUS LIKE 'Qcache%';
Aurora MySQL 互換 8.0 のメトリクス例:
`mysql> SHOW STATUS LIKE 'Qcache%';`
`+-------------------------+--------+`
`| Variable_name | Value |`
`+-------------------------+--------+`
`| Qcache_free_blocks | 36 |`
`| Qcache_free_memory | 138488 |`
`| Qcache_hits | 79570 |`
`| Qcache_inserts | 27087 |`
`| Qcache_lowmem_prunes | 3114 |`
`| Qcache_not_cached | 22989 |`
`| Qcache_queries_in_cache | 415 |`
`| Qcache_total_blocks | 912 |`
`+-------------------------+--------+`
この例では、Aurora MySQL 互換 8.0 は、完全な実行を回避するために、キャッシュからクエリを処理する機能を削除したことを示しています。この機能が欠けているため、Aurora MySQL はすべてのクエリを実行し、ワークロードが 2 倍になります。
インスタンスの CPU 消費が急増している場合は、次のメトリクスをレビューします。
- Queries
- Com_select
- Innodb_rows_read
これらのメトリクスに関連する問題を解決するには、次の手順を実行します。
追加のトラブルシューティング手順
以前のバージョンの実行計画をアップグレード後のバージョンの実行計画と比較すると、問題を効果的にトラブルシューティングできます。パラメータグループの設定を比較するには、EXPLAIN FORMAT=JSON クエリを実行します。innodb_buffer_pool_size などの重要な構成は、両方のバージョンで共通している必要があります。詳細については、MySQL のウェブサイトで「InnoDB バッファプールサイズの構成」と「EXPLAIN ステートメント」を参照してください。
Aurora のクローン機能により、ステージング環境でアップグレードをテストすることをおすすめします。ステージング環境でのシミュレーションには、Sysbench などのツールを使用できます。次に、AWS Database Insights、拡張モニタリングなどの AWS ツールを使用して主要なメトリクスを監視します。