ソース MySQL データベース

このセクションには、次に関する情報が含まれています。

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

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

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

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

バージョン

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

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

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

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

既知の制限事項

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

  • ストリームは 10,000 テーブルに制限されています。
  • 主キーが INVISIBLE として定義されているテーブルはバックフィルできません。
  • 次の条件が満たされない限り、5 億行を超えるテーブルはバックフィルできません。
    1. テーブルには一意のインデックスがある。
    2. インデックスのどの列も null 値を許容できません。
    3. インデックスが降順ではありません。
    4. インデックスのすべての列がストリームに含まれる。
  • 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 はレプリカへのフェイルオーバーをサポートしていません。そのため、Cloud SQL for MySQL Enterprise Plus ソースからのレプリケーションに Datastream を使用することはおすすめしません。Cloud SQL Enterprise Plus エディションのインスタンスはダウンタイムがほぼゼロのメンテナンスに適用され、メンテナンス中にレプリカにフェイルオーバーします。これにより、binlog の連続性が破られ、影響を受けるストリームが永続的に失敗します。

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

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

次のステップ