MySQL データベースからデータをストリーミングする

Datastream を使用すると、ソース MySQL データベースから過去のデータと継続的な変更を宛先に複製して、リアルタイム分析とデータベース同期を行うことができます。

MySQL ソースを構成する前に、Datastream のレプリケーション動作、サポートされているバージョンとデータベース タイプ、ベスト プラクティス、既知の制限事項を確認してください。

動作

このセクションでは、Datastream を使用してデータを複製する場合の MySQL ソースの動作について説明します。MySQL データベースからデータを取り込む場合は、binlog ベースのレプリケーションまたはグローバル トランザクション識別子（GTID）ベースのレプリケーションを使用できます。CDC メソッドは、ストリームを作成するときに選択します。

バイナリログ ベースのレプリケーション

Datastream は、バイナリログ ファイルを使用して、MySQL データベースのデータ変更の記録を保持できます。これらのログファイルに含まれる情報は、移行先に複製され、移行元で行われた変更が再現されます。

Datastream の binlog ベースのレプリケーションの主な特徴は次のとおりです。

• 特定の MySQL 移行元からのすべてのデータベースまたは特定のデータベース、およびデータベースや特定のテーブルのすべてのテーブルを選択できます。
• 過去のデータはすべて複製されます。
• 指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
• commit された変更のみが複製されます。

グローバル トランザクション識別子（GTID）ベースのレプリケーション

高可用性設定でシームレスなフェイルオーバーをサポートするには、GTID ベースのレプリケーションを使用します。

Datastream は、グローバル識別子（GTID）ベースのレプリケーションもサポートしています。

グローバル トランザクション識別子（GTID）は、MySQL ソースで commit された各トランザクションに作成され、関連付けられる固有識別子です。この識別子は、生成元のソースだけでなく、特定のレプリケーション トポロジ内のすべてのサーバーでも一意です。これに対して、バイナリログベースのレプリケーションでは、データベース クラスタ内の各ノードが独自の番号付けで独自の binlog ファイルを維持します。バイナリログ ファイルと番号を個別に管理すると、バイナリログの継続性が失われ、バイナリログベースのレプリケーションが失敗するため、障害や計画的なダウンタイムが発生した場合に問題になる可能性があります。

GTID ベースのレプリケーションは、フェイルオーバー、セルフマネージド データベース クラスタをサポートし、データベース クラスタの変更に関係なく動作を継続します。

Datastream での GTID ベースのレプリケーションの主な特徴は次のとおりです。

• 特定の MySQL 移行元からのすべてのデータベースまたは特定のデータベース、およびデータベースや特定のテーブルのすべてのテーブルを選択できます。
• 過去のデータはすべて複製されます。
• 指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
• commit された変更のみが複製されます。
• フェイルオーバーのシームレスなサポート。

binlog ベースのレプリケーションから GTID ベースのレプリケーションに切り替える

バックフィルを行わずに、ストリームを更新して binlog ベースのレプリケーションから GTID ベースのレプリケーションに切り替える場合は、次の手順を行います。

注: これらの手順では、データベースのダウンタイムが必要です。MySQL ソースのメジャー バージョンをアップグレードする場合も、同様の手順が役立つことがあります。

1. GTID ベースのレプリケーションの要件をすべて満たしていることを確認します。詳細については、ソース MySQL データベースを構成するをご覧ください。
2. 必要に応じて、テスト GTID ベースのストリームを作成して実行します。詳細については、ストリームを作成するをご覧ください。
3. GTID ベースのストリームを作成します。まだ開始しないでください。
4. 移行元データベースへのアプリケーション トラフィックを停止します。
5. 既存の binlog ベースのストリームを一時停止します。詳細については、ストリームを一時停止するをご覧ください。
6. Datastream がデータベースに追いつくまで数分待ちます。これを確認するには、ストリームの [ストリームの詳細] ページの [モニタリング] タブにある指標を使用します。[データの更新速度] と [スループット] の値は 0 にする必要があります。
7. GTID ベースのストリームを開始します。詳細については、ストリームを開始するをご覧ください。
8. ソース データベースへのトラフィックを再開します。

バックフィルの実行に問題がない場合は、BigQuery でテーブルを切り捨て、古いストリームを削除して、バックフィルで新しいストリームを開始できます。バックフィルの管理の詳細については、ストリームのオブジェクトのバックフィルを管理するをご覧ください。

バージョン

Datastream は、次のバージョンの MySQL データベースをサポートしています。

• MySQL 5.6
• MySQL 5.7
• MySQL 8.0

• MySQL 8.4（GTID ベースのレプリケーションでのみサポート）

  グローバル トランザクション識別子（GTID）ベースのレプリケーションは、バージョン 5.7 以降でのみサポートされています。

Datastream は、次のタイプの MySQL データベースをサポートしています。

• セルフホスト型 MySQL
• Cloud SQL for MySQL
  Cloud SQL for MySQL Enterprise Plus ソースは、GTID ベースのレプリケーションを使用する場合にサポートされます。
• Amazon RDS for MySQL
• Amazon Aurora MySQL
• MariaDB
• Alibaba Cloud PolarDB
• Percona Server for MySQL

ベスト プラクティス

このセクションでは、Datastream で使用する MySQL ソースを構成するための推奨ベスト プラクティスについて説明します。

高可用性設定に GTID を使用する

本番環境の MySQL ソースでレプリカまたはその他の高可用性構成を使用している場合は、GTID ベースのレプリケーションを使用します。

プライマリが失敗すると、新しいプライマリの binlog 履歴が異なるため、データベースのフェイルオーバー中に binlog ファイルと位置ベースのレプリケーションが中断される可能性があります。このような場合、Datastream は位置を失い、再開できません。

GTID は、レプリケーション トポロジ全体（プライマリとレプリカ）のすべてのトランザクションに一意の ID を割り当てます。フェイルオーバー後、Datastream は、binlog ファイルや位置を把握することなく、新しいプライマリに記録された最後の GTID から再開できます。

推奨事項: レプリカまたは高可用性構成を使用する本番環境の MySQL ソースでは、復元力と信頼性に優れたデータ レプリケーションを実現するために、GTID CDC メソッドを使用する必要があります。

リードレプリカのサイズを適切に設定する

リードレプリカから複製するように Datastream を構成すると、二重ラグが発生する可能性があります。これは、MySQL レプリケーション ラグ（プライマリからレプリカ）と Datastream レプリケーション ラグ（レプリカから宛先）の組み合わせです。リードレプリカは、費用を節約するために、プライマリよりも少ないリソース（CPU、RAM、IOPS）でプロビジョニングされることがよくあります。これにより、書き込みが多い期間にプライマリよりも遅延が発生する可能性があります。

推奨事項: リードレプリカを Datastream のソースとして使用する場合は、レプリカがプライマリの書き込みスループットに追いつくように、プライマリと同等のリソースをプロビジョニングします。

binlog CDC メソッドのスループットを向上させる

binlog ベースのレプリケーションを使用しているときに、ソースの書き込み量が多く、単一のタスクで処理できるよりも速く binlog ファイルが生成されるためにレイテンシが高くなる場合は、maxConcurrentCdcTasks パラメータを調整してスループットを向上させます。このパラメータは、ストリームが並列で実行する CDC タスクの数を制御します。このパラメータの値を増やすと、Datastream はより多くの binlog ファイルを同時に処理できます。

推奨事項: データの更新速度に適切な値を決定するには、ピーク時間帯に MySQL サーバーのバイナリログ生成率をモニタリングします。これを行うには、MySQL データ ディレクトリで新しいバイナリログ ファイルが作成およびローテーションされるレートをモニタリングするか、MySQL モニタリング ツールを使用してバイナリログの増加を追跡します。たとえば、ピーク時にソースが 1 分あたり 10 個のバイナリログ ファイルを生成する場合、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 がバイナリログから読み取る必要がある大きな行やトランザクションをサーバーが処理できるようになります。

既知の制限事項

MySQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。

• ストリームは 10,000 テーブルに制限されています。
• レプリケートされたテーブルでは、InnoDB ストレージ エンジンを使用する必要があります。MyISAM ストレージ エンジンを使用するテーブルはサポートされておらず、ストリーム検証に失敗します。
• 主キーが INVISIBLE として定義されているテーブルはバックフィルできません。
• 次の条件が満たされない限り、5 億行を超えるテーブルはバックフィルできません。
  1. テーブルには一意のインデックスがある。
  2. インデックスのどの列も null 値を許容できません。
  3. インデックスが降順ではありません。
  4. インデックスのすべての列がストリームに含まれる。
• Datastream は、イベントの処理中に移行元から最新のスキーマを定期的に取得します。スキーマが変更されると、Datastream はスキーマの変更を検出し、スキーマの取得をトリガーします。ただし、スキーマの取得の間に一部のイベントが誤って処理されたり、ドロップされたりして、データの不一致が生じる可能性があります。
• 移行元のスキーマに対するすべての変更を自動的に検出できない場合があります。その場合、データが破損する可能性があります。次のスキーマの変更により、データが破損したり、イベントのダウンストリームが処理されなかったりする可能性があります。
  • 列をドロップする
  • テーブルの中央に列を追加する
  • 列のデータ型を変更する
  • 列の並べ替え
  • テーブルをドロップする（新しいデータを追加して同じテーブルを再作成する場合に関連）
  • テーブルを切り捨てる
• Datastream はビューの複製をサポートしていません。
• Datastream は、空間データ型の列（GEOMETRY、POINT、LINESTRING、POLYGON など）をサポートしていません。これらの列の値は 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 は、4 GiB を超えるバイナリログ ファイルをサポートしていません。MySQL は各トランザクションを 1 つのバイナリログ ファイルに書き込むため、バイナリログ ファイルがこの上限を超えないように、個々のトランザクションを 4 GiB 未満に抑えてください。
• Datastream は、ソース MySQL 接続プロファイルの SSL 証明書チェーンをサポートしていません。x509 PEM でエンコードされた単一の証明書のみがサポートされています。
• Datastream は、カスケード オペレーション（ON UPDATE CASCADE と ON DELETE CASCADE）をサポートしていません。このようなイベントはバイナリログに書き込まれないため、その結果、宛先に伝播されません。回避策として、カスケード オペレーションをデータベース トリガーに置き換えることができます。
• 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 データベースを構成するをご覧ください。
• MariaDB の制限事項:
  • MariaDB では、GTID ベースのレプリケーションはサポートされていません。binlog ベースのレプリケーションを使用するように MariaDB ストリームを構成する必要があります。
  • MariaDB バージョン 11.4 ～ 12.2 の場合、Datastream との互換性を確保するために、ソース データベースで binlog_legacy_event_pos システム変数を有効にする必要があります。
  • Datastream は、UUID データ型（MariaDB 10.7 で導入）をサポートしていません。UUID データ型の列をストリーム構成から除外する必要があります。

GTID ベースのレプリケーションに関する追加の制限事項

• GTID ベースのレプリケーションを使用するストリームの復元は、Datastream API を使用する場合にのみ使用できます。
• CREATE TABLE ... SELECT ステートメントを使用して他のテーブルからテーブルを作成することはできません。
• Datastream はタグ付き GTID をサポートしていません。
• GTID ベースのレプリケーションに適用される MySQL の制限については、MySQL のドキュメントをご覧ください。

次のステップ

• Datastream で使用する MySQL ソースの構成方法を学習する。