翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# MySQL エンドポイントのトラブルシューティング
<a name="CHAP_Troubleshooting_Latency_Source_MySQL"></a>

このセクションでは、MySQL に固有のレプリケーションシナリオについて説明します。 は MySQL バイナリログを定期的に AWS DMS スキャンして、変更をレプリケートします。このプロセスにより、次のシナリオでレイテンシーが増大する可能性があります。

**Topics**
+ [ソースでのトランザクション実行時間が長い](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [ソースでの高ワークロード](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [バイナリログの競合](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)

## ソースでのトランザクション実行時間が長い
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning"></a>

MySQL はコミットされたトランザクションのみをバイナリログに書き込むため、トランザクションが長時間実行されると、クエリの実行時間に比例してレイテンシーのスパイクが発生します。

実行時間の長いトランザクションを特定するには、次のクエリを使用するか、スロークエリログを使用します。

```
SHOW FULL PROCESSLIST;
```

スロークエリログの使用については、「[MySQL ドキュメント](https://dev.mysql.com/doc/)」の「[The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)」を参照してください。

長時間実行されるトランザクションによるレイテンシーのスパイクを回避するには、ソーストランザクションを再構築してクエリの実行時間を短縮するか、コミット頻度を増やします。

## ソースでの高ワークロード
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload"></a>

DMS CDC はシングルスレッドであるため、トランザクション数が多いとソースのレイテンシーが増大する可能性があります。ワークロードが重いことがソースのレイテンシーの原因であるかを特定するには、レイテンシー中に生成されたバイナリログの数とサイズをレイテンシー以前に生成されたログと比較します。バイナリログと DMS CDC スレッドのステータスを確認するには、次のクエリを使用します。

```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```

CDC バイナリログのダンプスレッドの状態の詳細については、「[Replication Source Thread States](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html)」を参照してください。

ソースで生成された最新のバイナリログの位置と DMS が現在処理しているイベントを比較すると、レイテンシーを判断できます。ソースの最新のバイナリログを特定するには、次を実行します。
+ SOURCE\_CAPTURE コンポーネントのデバッグログを有効にします。
+ DMS の処理のバイナリログと位置の詳細をタスクデバッグログから取得します。
+ 次のクエリを使用して、ソースの最新のバイナリログを特定します。

  ```
  SHOW MASTER STATUS;
  ```

パフォーマンスをさらに最適化するには、`EventsPollInterval` を調整します。デフォルトでは、DMS は 5 秒ごとにバイナリログをポーリングします。この値を減らすとパフォーマンスが向上する可能性があります。`EventsPollInterval` の設定の詳細については、[のソースとして MySQL を使用する場合のエンドポイント設定 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib)を参照してください。

## バイナリログの競合
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog"></a>

大量のデータを含む複数のテーブルを移行する場合、MySQL 5.7.2 以降ではテーブルを個別のタスクに分割することをお勧めします。MySQL バージョン 5.7.2 以降では、マスターダンプスレッドによるロック競合が低減し、スループットが向上しています。その結果、ダンプスレッドはイベントを読み取る都度バイナリログをロックすることがなくなりました。つまり、複数のダンプスレッドがバイナリログファイルを同時に読み取ることができるようになりました。これは、クライアントがバイナリログに書き込みを行っている間も、ダンプスレッドがバイナリログを読み取ることができることも意味します。ダンプスレッドの詳細については、「[Replication Threads](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html)」と「[MySQL 5.7.2 リリースノート](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html)」を参照してください。

5.7.2 以前のバージョンの MySQL ソースのレプリケーションのパフォーマンスを向上するには、CDC コンポーネントを使用してタスクを統合することを検討します。