このセクションには、次に関する情報が含まれています。
- Datastream が移行元 MySQL データベースから pull されているデータを処理する方法の動作
- Datastream でサポートされている MySQL データベースのバージョン
- MySQL データベースを移行元として使用する場合の既知の制限事項
- データが移行先にストリーミングできるように移行元 MySQL データベースを設定する方法の概要
動作
このセクションでは、Datastream を使用してデータを複製する場合の MySQL ソースの動作について説明します。MySQL データベースからデータを取り込む場合は、binlog ベースのレプリケーションまたはグローバル トランザクション識別子（GTID）ベースのレプリケーションを使用できます。CDC メソッドは、ストリームを作成するときに選択します。
バイナリログ ベースのレプリケーション
Datastream は、バイナリログ ファイルを使用して、MySQL データベースのデータ変更の記録を保持できます。これらのログファイルに含まれる情報は、移行先に複製され、移行元で行われた変更が再現されます。
Datastream の binlog ベースのレプリケーションの主な特徴は次のとおりです。
- 特定の MySQL 移行元からのすべてのデータベースまたは特定のデータベース、およびデータベースまたは特定のテーブルのすべてのテーブルを選択できます。
- 履歴データはすべて複製されます。
- 指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
- commit された変更のみが複製されます。
グローバル トランザクション識別子（GTID）ベースのレプリケーション
Datastream は、グローバル識別子（GTID）ベースのレプリケーションもサポートしています。
グローバル トランザクション識別子（GTID）は、MySQL ソースでコミットされた各トランザクションに関連付けられて作成される一意の識別子です。この識別子は、その発生元のソースだけでなく、特定のレプリケーション トポロジ内のすべてのサーバーで一意です。これは、データベース クラスタ内の各ノードが独自の番号付けで独自の binlog ファイルを保持するバイナリログベースのレプリケーションとは異なります。バイナリログ ファイルを個別に維持して番号を付けると、障害や計画的なダウンタイムが発生した場合に問題が生じる可能性があります。バイナリログの継続性が損なわれ、バイナリログ ベースのレプリケーションが失敗するためです。
GTID ベースのレプリケーションはフェイルオーバーとセルフマネージド データベース クラスタをサポートし、データベース クラスタの変更に関係なく動作し続けます。
Datastream の GTID ベースのレプリケーションの主な特徴は次のとおりです。
- 特定の MySQL 移行元からのすべてのデータベースまたは特定のデータベース、およびデータベースまたは特定のテーブルのすべてのテーブルを選択できます。
- 履歴データはすべて複製されます。
- 指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
- commit された変更のみが複製されます。
- フェイルオーバーのシームレスなサポート。
バイナリログ ベースのレプリケーションから GTID ベースのレプリケーションに切り替える
ストリームを更新し、バックフィルを行うことなく binlog ベースのレプリケーションから GTID ベースのレプリケーションに切り替える場合は、次の操作を行います。
- GTID ベースのレプリケーションの要件がすべて満たされていることを確認します。詳細については、ソース MySQL データベースを構成するをご覧ください。
- 必要に応じて、テスト GTID ベースのストリームを作成して実行します。詳細については、ストリームを作成するをご覧ください。
- GTID ベースのストリームを作成します。まだ開始しないでください。
- 移行元データベースへのアプリケーション トラフィックを停止します。
- 既存の binlog ベースのストリームを一時停止します。詳細については、ストリームを一時停止するをご覧ください。
- Datastream がデータベースに追いつくまで数分待ちます。これは、ストリームの [ストリームの詳細] ページの [モニタリング] タブの指標を使用して確認できます。[データ鮮度] と [スループット] の値は
0である必要があります。 - GTID ベースのストリームを開始します。詳細については、ストリームを開始するをご覧ください。
- ソース データベースへのトラフィックを再開します。
バックフィルを実行しても問題がない場合は、BigQuery でテーブルを切り捨て、古いストリームを削除して、バックフィルで新しいストリームを開始できます。バックフィルの管理の詳細については、ストリームのオブジェクトのバックフィルを管理するをご覧ください。
バージョン
Datastream は、次のバージョンの MySQL データベースをサポートしています。
- MySQL 5.6
- MySQL 5.7
- MySQL 8.0
MySQL 8.4（GTID ベースのレプリケーションでのみサポート）
Datastream は、次の種類の MySQL データベースをサポートしています。
- セルフホスト型 MySQL
- Cloud SQL for MySQL
- Amazon RDS for MySQL
- Amazon Aurora MySQL
- MariaDB
- Alibaba Cloud PolarDB
- Percona Server for MySQL
ベスト プラクティス
このセクションでは、Datastream で使用する MySQL ソースを構成する際の推奨されるベスト プラクティスについて説明します。
高可用性設定に GTID を使用する
本番環境の MySQL ソースでレプリカやその他の高可用性構成を使用している場合は、GTID ベースのレプリケーションを使用します。
プライマリが失敗すると、新しいプライマリのバイナリログ履歴が異なるため、データベースのフェイルオーバー中にバイナリログ ファイルと位置ベースのレプリケーションが中断される可能性があります。このような場合、Datastream は位置を失い、再開できません。
GTID は、レプリケーション トポロジ全体（プライマリとレプリカ）のすべてのトランザクションに一意の ID を割り当てます。フェイルオーバー後、Datastream はバイナリログ ファイルや位置を知らなくても、新しいプライマリに記録された最後の GTID から再開できます。
推奨事項: レプリカまたは高可用性構成の MySQL 本番環境では、復元力と信頼性の高いデータ レプリケーションを実現するために、GTID CDC メソッドを使用する必要があります。
リードレプリカのサイズを適切に設定する
読み取りレプリカから複製するように Datastream を構成すると、二重遅延が発生する可能性があります。これは、MySQL レプリケーションの遅延（プライマリからレプリカ）と Datastream レプリケーションの遅延（レプリカから宛先）の組み合わせです。リードレプリカは、コストを削減するためにプライマリよりも少ないリソース（CPU、RAM、IOPS）でプロビジョニングされることが多く、書き込みが多い期間にプライマリに遅れが生じることがあります。
推奨事項: Datastream のソースとしてリードレプリカを使用する場合は、レプリカがプライマリの書き込みスループットに対応できるように、プライマリと同等のリソースをプロビジョニングします。
binlog CDC メソッドのスループットを向上させる
binlog ベースのレプリケーションを使用しているときに、ソースの書き込み量が多く、単一のタスクで処理できるよりも速く binlog ファイルが生成されるためにレイテンシが高くなる場合は、maxConcurrentCdcTasks パラメータを調整してスループットを増やします。このパラメータは、ストリームが並行して実行する CDC タスクの数を制御します。このパラメータの値を大きくすると、Datastream でより多くの binlog ファイルを同時に処理できます。
推奨事項: データの更新頻度の適切な値を判断するには、ピーク時の MySQL サーバーの binlog 生成率をモニタリングします。これを行うには、MySQL データ ディレクトリで新しい binlog ファイルが作成およびローテーションされるレートをモニタリングするか、MySQL モニタリング ツールを使用してバイナリログの増加を追跡します。たとえば、ピーク時にソースが 1 分あたり 10 個の binlog ファイルを生成する場合、maxConcurrentCdcTasks を 10-15 などの値に設定すると、Datastream はこれらのファイルを並行して処理し、バックログを防ぐことができます。
ソース データベースの負荷が制御可能な範囲内であれば、maxConcurrentCdcTasks を最大サポート値の 50 まで増やすことができます。詳細については、ストリームの同時実行制御をご覧ください。
max_allowed_packet パラメータのサイズを正しく設定する
MySQL のデフォルトの max_allowed_packet 設定（16 MB ～ 64 MB など）が小さすぎる可能性があります。大きな BLOB、JSON、TEXT 型のフィールドを含む単一行、または大きな単一トランザクションがこのサイズを超えると、MySQL は Datastream 接続を終了し、ストリームが Packet for query is too large や Got a packet bigger than
'max_allowed_packet' bytes などのエラーで失敗します。
推奨事項: MySQL サーバーの max_allowed_packet パラメータを、許容される最大値の 1G に設定します。これにより、サーバーは Datastream が binlog から読み取る必要のある大きな行やトランザクションを処理できます。
既知の制限事項
MySQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。
- ストリームは 10,000 テーブルに制限されています。
- 主キーが
INVISIBLEとして定義されているテーブルはバックフィルできません。 - 次の条件が満たされない限り、5 億行を超えるテーブルはバックフィルできません。
- テーブルには一意のインデックスがある。
- インデックスのどの列も null 値を許容できません。
- インデックスが降順ではありません。
- インデックスのすべての列がストリームに含まれる。
- Datastream は、イベントの処理中に移行元から最新のスキーマを定期的に取得します。スキーマが変更されると、Datastream はスキーマの変更を検出し、スキーマの取得をトリガーします。ただし、スキーマの取得の間に一部のイベントが誤って処理されたり、ドロップされたりする可能性があり、データの不一致が生じる可能性があります。
- 移行元のスキーマに対するすべての変更を自動的に検出できない場合があります。その場合、データが破損する可能性があります。次のスキーマの変更により、データが破損したり、イベントのダウンストリームが処理されなかったりする可能性があります。
- 列をドロップする
- テーブルの中央に列を追加する
- 列のデータ型を変更する
- 列の並べ替え
- テーブルをドロップする（新しいデータを追加して同じテーブルを再作成する場合に関連）
- テーブルを切り捨てる
- Datastream はビューの複製をサポートしていません。
- Datastream は、 データ型の列をサポートしていません。これらの列の値は
NULL値に置き換えられます。 - Datastream は、データ型
DATETIME、DATE、TIMESTAMPの列でゼロ値（0000-00-00 00:00:00）をサポートしていません。ゼロ値はNULLの値に置き換えられます。 - Datastream は、
JSON列にDECIMAL、NEWDECIMAL、TIME、TIME2、DATETIME、DATETIME2、DATE、TIMESTAMP、TIMESTAMP2の値を含む行の複製をサポートしていません。このような値を含むイベントは破棄されます。 - Datastream は、バイナリログ トランザクション圧縮をサポートしていません。
- Datastream は、移行元 MySQL 接続プロファイルの SSL 証明書チェーンをサポートしていません。単一の x509 PEM でエンコードされた証明書のみがサポートされています。
- Datastream はカスケード削除をサポートしていません。このようなイベントはバイナリログに書き込まれないため、その結果、宛先に伝播されません。
- Datastream は
DROP PARTITIONオペレーションをサポートしていません。このようなオペレーションはメタデータのみのオペレーションであり、複製されません。他のイベントには影響せず、ストリームは正常に実行されます。 FEDERATEDテーブルを複製すると、接続の問題が発生することがあります。この場合は、ソース データベースの構成からすべてのFEDERATEDテーブルを削除し、connect_timeout、net_read_timeout、max_allowed_packetパラメータの値を増やして、バックフィル中のタイムアウトの問題を軽減します。- Cloud SQL Enterprise Plus インスタンスは、ダウンタイムがほぼゼロのメンテナンスの対象となるため、GTID ベースのレプリケーションを使用する必要があります。バイナリログベースのレプリケーションはフェイルオーバーで中断するため、高可用性のユースケースでは GTID ベースのレプリケーションを使用することをおすすめします。
- MySQL バージョン 8.0 以降では、
binlog_row_value_options変数を空の値に設定する必要があります。ほとんどのバージョンではこれがデフォルトですが、Oracle Cloud Infrastructure（OCI）上の MySQL ソースなど、明示的に設定する必要があるものもあります。詳細については、セルフマネージド MySQL データベースを構成するをご覧ください。
GTID ベースのレプリケーションの追加の制限事項
- GTID ベースのレプリケーションを使用するストリームの復元は、Datastream API を使用する場合にのみ可能です。
CREATE TABLE ... SELECTステートメントを使用して他のテーブルからテーブルを作成することはサポートされていません。- Datastream はタグ付き GTID をサポートしていません。
- GTID ベースのレプリケーションに適用される MySQL の制限については、MySQL のドキュメントをご覧ください。
次のステップ
- Datastream で使用する MySQL ソースの構成方法を学習する。