Amazon Aurora MySQL の「スレーブ SQL スレッドが十分なリレーログ領域を解放するのを待機しています」エラーのトラブルシューティング方法を教えてください。

簡単な説明

Aurora MySQL がバイナリログレプリケーションのレプリカである場合、I/O スレッドと SQL スレッドは MySQL と同じ方法で実行されます。I/O スレッドは、プライマリからバイナリログを読み取り、リレーログとしてレプリカ DB インスタンスに保存します。SQL スレッドは、リレーログのイベントが処理されると、リレーログ内のイベントを処理してからリレーログを削除します。

SQL スレッドが、リレーログが生成される速度に追いつけるほど速くイベントを処理しない場合、リレーログの量が増加します。

グローバル変数 relay_log_space_limit が 0 より大きい値に設定され、すべてのリレーログの合計サイズが上限に達すると、新しいリレーログは保存されません。リレーログ領域が再び使用可能になるまで、SHOW SLAVE STATUS の出力には、「スレーブ SQL スレッドが十分なリレーログ領域を解放するのを待機しています」というメッセージが Slave_IO_State フィールドに表示されます。

Aurora MySQL では、relay_log_space_limit は 1000000000 (953.6 MiB) に設定され、変更できません。これにより、クラスターボリュームが不必要に大きいものになるのを防ぎます。すべてのリレーログの合計サイズが 1000000000 バイト (953.6 MiB) に達すると、I/O スレッドはリレーログの保存を停止します。SQL スレッドがイベントを処理し、既存のログを削除するまで待機します。次に、Slave_IO_State は「スレーブ SQL スレッドが十分なリレーログ領域を解放するのを待機しています」メッセージを表示します。SQL スレッドが停止していない場合、リレーログは最終的に削除され、I/O スレッドは新しいリレーログの保存を再開します。

これは、SQL が I/O スレッドによるリレーログの生成に追いつくのに十分な速度ではないため、レプリケーションラグが存在することも意味します。relay_log_space_limit を大きな値に変更しても、リレーログはさらに蓄積され、SQL スレッドが追いつくまで問題は解決されません。

SHOW SLAVE STATUS コマンドの出力で、現在のリレーログ領域、I/O スレッドのステータス、および SQL スレッドのステータスを確認できます。

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: mysql-bin-changelog.237029
Read_Master_Log_Pos: 55356151
Relay_Master_Log_File: mysql-bin-changelog.237023
Exec_Master_Log_Pos: 120
Relay_Log_Space: 1000002403

Master_Log_File と Read_Master_Log_Pos は、バイナリログファイル名と、I/O スレッドが読み取りと保存を完了した位置を示します。Relay_Master_Log_Fileと Exec_Master_Log_Pos は、バイナリログファイル名と、SQL スレッドが処理している位置を示します。SQL スレッドが実際に読み取るものはリレーログですが、プライマリ DB インスタンス内の対応するバイナリログファイル名とその位置が表示されます。

Master_Log_File が Relay_Master_Log_File と異なる場合、SQL スレッドは十分高速ではありません。Master_Log_File と Relay_Master_Log_File が同じ場合は、I/O スレッドが遅延の原因になっている可能性があります。

次の要因により、SQL スレッドのパフォーマンスが低下する可能性があります。

• プライマリ DB インスタンスでクエリが長時間実行されている
• DB インスタンスクラスのサイズまたはストレージが不足している
• 並列クエリがプライマリ DB インスタンスで実行されている
• バイナリログがレプリカ DB インスタンス上のディスクに同期されている
• レプリカ DB インスタンスの Binlog_format が ROW に設定されている

これらの問題の解決の詳細については、「Amazon RDS for MySQL を使用したレプリカの高遅延のトラブルシューティング方法」を参照してください。

さらに、次の要因は、SQL スレッドのパフォーマンスに影響を与える可能性があります。

• レプリカ DB インスタンスの Transaction History List Length (HLL) が非常に大きい
• レプリカ DB インスタンスでの I//O 操作が効率的ではない
• レプリカ DB インスタンスでテーブルに多数のセカンダリインデックスが含まれている

解決方法

レプリカで書き込みが行われている限り、リレーログ領域について心配する必要はありません。これは、拡張モニタリングの書き込みスループットメトリクスを使用して監視できます。

リレーログ領域ではなく、レプリカのパフォーマンスのトラブルシューティングに重点を置きます。詳細については、「Amazon RDS for MySQL を使用したレプリカの高遅延のトラブルシューティング方法」と「Amazon Aurora リードレプリカが遅れて再起動された理由は何ですか?」を参照してください。

---

関連情報

レプリカサーバーのオプションと変数に関する MySQL ドキュメント