MySQLコネクタの制限

備考

プレビュー

MySQL コネクタはパブリック プレビュー段階です。アクセスをリクエストするには、Databricks アカウント チームにお問い合わせください。

MySQL コネクタの制限と考慮事項について説明します。

一般的なデータベースコネクタの制限

このセクションの制限は、 Lakeflowコネクトのすべてのデータベースコネクタに適用されます。 コネクタ固有の制限事項については、引き続きお読みください。

• スケジュールされたパイプラインを実行しても、アラートはすぐにはトリガーされません。代わりに、次の更新が実行されたときにトリガーされます。

• ソーステーブルが削除されても、宛先テーブルは自動的に削除されません。宛先テーブルを手動で削除する必要があります。この動作は LakeFlow Pipelines の動作と一致しません。

• ソースメンテナンス期間中、Databricks はデータにアクセスできない可能性があります。

• ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。

• 複数の宛先パイプラインのサポートは API のみです。

• ソース システムは、カーソル列が単調に増加すると想定します。

• マネージド インジェスチョン パイプラインは、AWS GovCloud リージョン (FedRAMP High) のワークスペースではサポートされていません。

• マネージド インジェスト パイプラインは、 us-east-2またはus-west-1リージョンの FedRAMP Moderate ワークスペースではサポートされていません。

MySQLのバージョンとバリエーション

コネクタは、次の MySQL バージョンとプラットフォームをサポートしています。

• Amazon RDS for MySQL : バージョン 5.7.44 以降 (スタンドアロンおよび HA デプロイメントの両方)
• Amazon Aurora MySQL : バージョン 5.7.mysql_aurora.2.12.2 以降 (HA セットアップの場合はプライマリインスタンスのみ)
• Amazon Aurora MySQLサーバレス : サポートされています
• Azure Database for MySQL フレキシブル サーバー : バージョン 5.7.44 以降 (スタンドアロンと HA 展開の両方)
• Google クラウドSQL for MySQL : バージョン 5.7.44 以降、バージョン 8.0 以降
• EC2上のMySQL :バージョン5.7.44以降

コネクタは、MariaDB やその他の MySQL 互換データベースをサポートしていません。

認証

• コネクタは、次の認証プラグインを使用したユーザー名とパスワードの認証をサポートします。

  • MySQL 5.7.44:レプリケーション ユーザーは、 sha256_password認証プラグインを使用して作成する必要があります。
  • MySQL 8.0.x 以降: sha256_passwordプラグインとcaching_sha2_passwordプラグインの両方がサポートされています。

• 資格情報が正しい場合でも、 sha256_passwordまたはcaching_sha2_passwordを使用しているユーザーの場合、UI の [接続テスト] ボタンが失敗する可能性があります。これは既知の問題です。接続を作成し、パイプラインのセットアップを続行することは可能です。

バイナリログの要件

• バイナリ ログはbinlog_format=ROWおよびbinlog_row_image=FULLで有効にする必要があります。

• binlog_row_value_options=PARTIAL_JSONはサポートされていません。この設定では、MySQL は JSON 列への更新を完全なドキュメントではなく部分的な変更としてログに記録します。コネクタが部分的な変更を読み取ると、テーブルをスキップし、 INGESTION_GATEWAY_MYSQL_TABLE_SKIPPED_DUE_TO_PARTIAL_JSON エラーを報告します。これは、更新が JSON 値を変更しない場合でも、 JSON 列を持つテーブルへの UPDATE で発生します。

  リカバリするには、グローバルに、および取り込まれたテーブルに書き込むすべての MySQL セッションで binlog_row_value_options を空の値に設定します。次に、影響を受けるテーブルのフル更新を実行します。設定が有効になっている間にフル更新を実行すると、次の UPDATE で再びテーブルがスキップされます。

• ゲートウェイが変更を処理する前に binlog が消去された場合は、パイプライン内のすべてのテーブルを完全に更新する必要があります。

• Databricks では、7 日間の binlog 保持を推奨しています。より低い値を設定すると、取り込みゲートウェイがバイナリログを再生する前にバイナリログがクリーンアップされる可能性があります。

リードレプリカのサポート

• リードレプリカのサポートは、Amazon RDS for MySQL、Azure Database for MySQL、EC2 上の MySQL でのみ利用できます。
• コネクタは、Aurora MySQL リードレプリカからの取り込みをサポートしていません。Aurora プライマリ インスタンス (ライター エンドポイント) に接続する必要があります。
• 読み取りレプリカを使用する場合、レプリケーションの遅延がデータの鮮度に影響する可能性があります。

パイプライン

• 各データ取り込みパイプラインは、必ず1つのデータ取り込みゲートウェイに関連付けられなければなりません。ゲートウェイは複数のパイプライン間で共有できません。
• インジェスト パイプラインはサーバレス コンピュートで実行されますが、インジェスト ゲートウェイはクラシック コンピュートで実行する必要があります。
• 取り込みゲートウェイは継続的に実行され、バイナリログが切り捨てられたり消去される前に変更をキャプチャします。
• 取り込みパイプラインを異なるソースレプリカまたはノードに再接続しないでください。別のソースノードへの再接続を参照してください。

別のソースノードに再接続しています

コネクタは、その進行状況をbinlogファイル名と位置としてチェックポイントします。これらの座標は、それらを書き込んだサーバー上でのみ意味があるため、サーバー間で引き継がれるチェックポイントはありません。

取り込みゲートウェイは、チェックポイントを作成したMySQLサーバーのserver_uuidを記録します。後のアップデートで異なるserver_uuidが見つかった場合、ゲートウェイのアップデートはINGESTION_GATEWAY_MYSQL_SERVER_UUID_CHANGEDエラーで失敗します。これにより、ゲートウェイが誤ったサーバー上の座標から再開されるのを防ぎます。

復旧するには、以下のいずれかを実行します。

• パイプラインを元の MySQL サーバーに再接続します。インジェストは既存のチェックポイントから再開されます。
• パイプライン内のすべてのテーブルの完全更新をランします。これは、パイプラインを新しいサーバーにバインドします。

一部のテーブルのみを更新しても、パイプラインは回復しません。更新していないテーブルには元のサーバーからのチェックポイントが保持されているため、ゲートウェイの更新は失敗し続けます。

完全更新を実行するには、 「ターゲット テーブルを完全に更新する」を参照してください。

スキーマ進化と DDL 操作

コネクタは新しい列と削除された列を自動的に処理します。

• ソースに新しい非空間列が表示されると、Databricks はパイプラインの次回実行時にそれを自動的に取り込みます。
• 空間データ型の列はサポートされていないため、取り込むことができません。
• 列がソースから削除されても、Databricks はそれを自動的に削除しません。代わりに、コネクタはテーブル プロパティを使用して、削除された列を宛先のinactiveに設定します。後でinactive列と名前が競合する別の列が現れた場合、パイプラインは失敗します。この場合、テーブルを完全に更新するか、非アクティブな列を手動で削除することができます。

スキーマ全体を取り込む場合、これはスキーマ内の新しいテーブルと削除されたテーブルに当てはまります。

DDL操作の処理

コネクタは一部の DDL 操作を処理できますが、多くの場合、テーブルの完全な更新が必要です。

• TRUNCATE TABLE : テーブルを更新する必要があります。

• RENAME TABLE : 名前が変更されたテーブルは、インジェスト ゲートウェイでスキップされ、イベント ログにエラーが記録されます。このテーブルのフローは、取り込みパイプラインで失敗としてマークされています。

• DROP TABLE : テーブルはインジェスト ゲートウェイから削除され、イベント ログにエラーが記録されます。このテーブルのフローは、取り込みパイプラインで失敗としてマークされています。

• PRIMARY KEY または UNIQUE 制約を追加します 。テーブルを更新する必要があります。

• DROP PRIMARY KEY 制約 : テーブルを更新する必要があります。

• DROP UNIQUE 制約 : これがソース テーブル上の唯一の一意制約である場合は、テーブルを更新する必要があります。そうでない場合は、何もする必要はありません。

• 列の削除 / 列の変更 / 列の変更 : テーブルを更新する必要があります。

• 列を追加 :

  • 列が非空間型の場合: アクションは必要ありません。列は、次のパイプライン更新時に自動的に取り込まれます。
  • 列に空間型がある場合: 列を追加すると、そのテーブルのそれ以上の取り込みが停止します。 テーブルは取り込みゲートウェイでスキップされ、イベント ログにエラーが記録されます。このテーブルのフローは、取り込みパイプラインで失敗としてマークされています。

• ADD TABLE (スキーマ全体を取り込む場合):

  • テーブルに空間タイプがない場合: アクションは必要ありません。テーブルは、次のパイプライン更新時に自動的に取り込まれます。
  • テーブルに空間型がある場合: テーブルは取り込みゲートウェイでスキップされ、イベント ログにエラーが記録されます。このテーブルのフローは、取り込みパイプラインで失敗としてマークされています。

完全更新を実行するタイミング

次のシナリオでは、テーブルの完全更新を実行します。

• ソースに対するTRUNCATE TABLE操作の後。
• 列のデータ型が変更された後 ( MODIFY COLUMN )。
• 列名を変更した後 ( CHANGE COLUMN )。
• DROP COLUMN操作後 (非アクティブな列を削除するため)。
• 空間列が追加されたとき (選択から削除する前)。

完全更新を実行するには、 「ターゲット テーブルを完全に更新する」を参照してください。

ステージング

ステージング カタログをフォーリンカタログにすることはできません。

テーブルとデータ型

• Databricks では、パイプラインごとに 250 個以下のテーブルを取り込むことを推奨しています。ただし、これらのオブジェクト内でサポートされる行または列の数に制限はありません。
• MySQL は 2 レベルの名前空間です。source_schemaとsource_table名前では大文字と小文字が区別されます。
• 1 つのパイプラインで複数のソース スキーマから取り込むことはできますが、同じ名前の 2 つのテーブルを同じ宛先スキーマに取り込むことはできません。たとえば、 schema1.customersとschema2.customers両方を同じ宛先スキーマに取り込むことはできません。ただし、マルチデスティネーションパイプラインを使用して、異なるデスティネーションスキーマに取り込むことができます。
• 空間データ型 (GEOMETRY、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTION) はサポートされていません。選択したテーブルに空間列が存在する場合、テーブルは取り込みゲートウェイでスキップされ、イベント ログにエラーが記録されます。

文字セットと照合順序

コネクターは、各列のMySQL文字セットを使用して文字列型の列（CHAR、VARCHAR、TEXT型）をデコードし、値をUTF-8として宛先に書き込みます。

サポートされていない文字セット

コネクタは、次の文字セットを除き、すべての MySQL 文字セットをサポートしています：

armscii8、dec8、geostd8、hp8、keybcs2、およびswe7。

選択したテーブルにサポートされていない文字セットを使用する文字列列がある場合、取り込みゲートウェイはそのテーブルをスキップし、イベントLogsにINGESTION_GATEWAY_TABLE_SKIPPED_DUE_TO_UNSUPPORTED_CHARSETエラーを記録します。パイプライン内の他のテーブルでは、引き続きデータが取り込まれます。テーブルを取り込むには、影響を受けた列を、utf8mb4などのサポートされている文字セットに変換します。

既知の問題

• 資格情報が有効な場合でも、 sha256_passwordまたはcaching_sha2_password認証を使用する MySQL ユーザーの場合、 [テスト接続] ボタンは失敗します。これは既知の制限です。引き続き接続とパイプラインを作成できます。