メインコンテンツまでスキップ
に最終更新

MySQLコネクタの制限

備考

プレビュー

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

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

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

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

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

  • ソース テーブルを削除しても、宛先テーブルは自動的に削除されません。宛先テーブルを手動で削除する必要があります。この動作は、 Lakeflow Spark宣言型パイプラインの動作と一致しません。

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

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

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

  • オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのパイプラインは API 専用となり、UI でパイプラインを編集できなくなります。

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

  • SCDタイプ 1 が有効になっている場合、削除によって変更データフィードに明示的なdeleteイベントが生成されません。 監査可能な削除の場合、コネクタがサポートしている場合は SCD タイプ 2 を使用します。詳細については、 「例: CDF ソース データを使用した SCD タイプ 1 および SCD タイプ 2 の処理」を参照してください。

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 が消去された場合は、パイプライン内のすべてのテーブルを完全に更新する必要があります。
  • Databricks では、7 日間の binlog 保持を推奨しています。より低い値を設定すると、取り込みゲートウェイがバイナリログを再生する前にバイナリログがクリーンアップされる可能性があります。

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

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

パイプライン​

  • 各取り込みパイプラインは、正確に 1 つの取り込みゲートウェイに関連付ける必要があります。
  • インジェスト パイプラインはサーバレス コンピュートで実行されますが、インジェスト ゲートウェイはクラシック コンピュートで実行する必要があります。
  • 取り込みゲートウェイは継続的に実行され、バイナリログが切り捨てられたり消去される前に変更をキャプチャします。

スキーマ進化と 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) はサポートされていません。選択したテーブルに空間列が存在する場合、テーブルは取り込みゲートウェイでスキップされ、イベント ログにエラーが記録されます。

文字セットと照合順序​

コネクタは現在、UTF-8 互換のバイト シーケンスのみを複製します。これは、MySQL に格納されているバイト表現が UTF-8 エンコーディングと一致する場合、レプリケーションが正しく機能することを意味します。

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

次の MySQL 文字セットが完全にまたは部分的にサポートされています。

  • 完全にサポートされています (バイトは常に UTF-8 と一致します):

    • utf8
    • utf8mb4
    • ascii

  • 部分的にサポートされています (ASCII 範囲のみ):

    • latin1 - latin1として保存される実際のデータのほとんどは ASCII と互換性があり、正しく動作します。MySQL 5.7.44 ではデフォルトの文字セットとしてlatin1が使用されます。

  • バージョン別のデフォルトの文字セット :

    • MySQL 5.7.44: latin1 (デフォルト)
    • MySQL 8.0 以降: utf8mb4 (デフォルト)

文字セットの制限​

  • コネクタは文字セット間の変換を行いません。生のバイトを転送し、有効な UTF-8 を表すものと想定します。
  • サポートされていない文字セット内の UTF-8 非互換の文字は、送信先で文字化けしたり、不正確に表示される場合があります。
  • 上記以外の文字セットの非 ASCII データの場合は、取り込む前にテーブルをutf8mb4に変換することを検討してください。

既知の問題​

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