次の方法で共有

PostgreSQL コネクタの制限事項

Important

Lakeflow Connect 用 PostgreSQL コネクタはパブリック プレビュー段階です。 パブリック プレビューに登録する場合は、Databricks アカウント チームにお問い合わせください。

このページでは、Databricks Lakeflow Connect を使用した PostgreSQL インジェストの制限事項と考慮事項を示します。

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

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

  • スケジュールされたパイプラインを実行すると、アラートはすぐにトリガーされません。 代わりに、次回の更新の実行時にトリガーされます。
  • 取り込み元テーブルが削除されても、取り込み先テーブルが自動的に削除されることはありません。 取り込み先テーブルは手動で削除する必要があります。 この動作は、Lakeflow Spark 宣言パイプラインの動作と一致しません。
  • ソースのメンテナンス期間中は、Databricks がデータにアクセスできない場合があります。
  • ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。
  • 複数宛先パイプラインのサポートは API 専用です。
  • 必要に応じて、取り込むテーブルの名前を変更できます。 パイプライン内のテーブルの名前を変更すると、そのテーブルは API 専用パイプラインになり、UI でパイプラインを編集できなくなります。
  • パイプラインが既に開始された後で列を選択した場合、コネクタは新しい列のデータを自動的にバックフィルしません。 履歴データを取り込むには、テーブルに対して完全な更新を手動で実行します。
  • Databricks は、異なるソース スキーマから取得された場合でも、同じパイプライン内で同じ名前の 2 つ以上のテーブルを取り込むことはありません。
  • ソース システムでは、カーソル列が単調に増加していることを前提としています。
  • マネージド インジェスト パイプラインは、Azure GovCloud リージョンのワークスペースではサポートされていません。
  • SCD タイプ 1 を有効にすると、削除によって変更データ フィードに明示的な delete イベントが生成されることはありません。 監査可能な削除の場合は、コネクタでサポートされている場合は SCD タイプ 2 を使用します。 詳細については、 例: CDF ソース・データを使用した SCD タイプ 1 および SCD タイプ 2 の処理を参照してください。
  • コネクタは、変換なしで生データを取り込みます。 変換には、ダウンストリームの Lakeflow Spark 宣言型パイプラインを使用します。
  • コネクタは、プライマリ PostgreSQL インスタンスからのレプリケーションのみをサポートします。

Authentication

  • コネクタでは、ユーザー名とパスワードの認証のみがサポートされます。

データベースのバリエーション

  • コネクタは PostgreSQL 13 以降をサポートしています。
  • このコネクタは、AWS RDS PostgreSQL、Aurora PostgreSQL、Amazon EC2、Azure Database for PostgreSQL、Azure 仮想マシン、GCP Cloud SQL for PostgreSQL をサポートしています。 このコネクタでは、Azure ExpressRoute、AWS Direct Connect、VPN ネットワークを使用するオンプレミス PostgreSQL もサポートされています。

Pipelines

  • 各インジェスト パイプラインは、1 つのインジェスト ゲートウェイに関連付ける必要があります。
  • インジェスト パイプラインはサーバーレス コンピューティングで実行されますが、インジェスト ゲートウェイはクラシック コンピューティングで実行する必要があります。
  • インジェスト ゲートウェイは、Write-Ahead ログ (WAL) の肥大化とレプリケーション スロットの蓄積を防ぐために、継続的モードで実行する必要があります。

レプリケーション

  • 論理レプリケーションでは、 wal_level パラメーターが logical に設定された PostgreSQL 13 以降が必要です。
  • レプリケートする各テーブルのレプリカ ID は、 FULL または DEFAULTに設定されている必要があります。 Databricks では、主キーのないテーブルまたは TOASTable 列に対して、 FULL レプリカ ID を使用することをお勧めします。
  • パイプラインを削除しても、レプリケーション スロットは自動的に削除されません。 WAL の蓄積を防ぐために、レプリケーション スロットを手動でクリーンアップする必要があります。 レプリケーション スロットのクリーンアップを参照してください。

スキーマの展開

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

  • ソースに新しい列が表示されると、Databricks は次のパイプラインの実行時に自動的に取り込みます。
  • 列がソースから削除されると、Databricks によって自動的に削除されることはありません。 代わりに、コネクタはテーブル プロパティを使用して、削除された列を変換先で inactive するように設定します。 後で、 inactive 列と競合する名前を持つ別の列が表示された場合、パイプラインは失敗します。 この場合は、テーブルの完全な更新を実行するか、非アクティブな列を手動で削除します。

コネクタは、以下に示す DFL (列の名前の変更など) を処理できますが、ターゲット テーブルの完全な更新が必要です。

DDL の完全な更新が必要

  • 列のデータ型の変更
  • 列の名前を変更する
  • テーブルの主キーの変更
  • ログ記録されていないテーブルからログに記録されたテーブルへの変換、またはその逆の変換
  • パーティションの追加または削除 (パーティション テーブルの場合)

Staging

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

Tables

  • Databricks では、取り込むテーブルの数をパイプラインごとに 250 個以下にすることが推奨されています。 ただし、これらのテーブル内でサポートされている行または列の数に制限はありません。
  • Databricks では、1 つのパイプラインを使用して、大文字・小文字の違う 2 つのテーブル (たとえば、mytable と MyTable) を取り込むことはできません。 このようなケースをサポートするには、異なるターゲット スキーマに発行する 2 つのゲートウェイ インジェスト パイプライン ペアを作成します。
  • source_catalog、source_schema、およびsource_table名はデータベース名では大文字と小文字が区別されますが、スキーマ名とテーブル名では大文字と小文字は区別されません (PostgreSQL の既定の動作に従います)。 たとえば、ソース データベースの名前が MyDatabase の場合は、MyDatabaseでingestion_definitionとして指定する必要があります。
  • 1 つのパイプラインで複数のソース データベースまたはスキーマから取り込むことができますが、同じ名前の 2 つのテーブルを取り込むことはできません。 たとえば、同じパイプラインに schema1.orders と schema2.orders の両方を取り込むことはできません。
  • objectsのingestion_definitionフィールドには、複数のテーブルまたはスキーマの仕様を含めることができます。 ただし、異なるソース スキーマのソース テーブル名は重複できません。 名前が重複すると、インジェスト パイプラインエラーが発生します。

データ型

  • ユーザー定義型とサード パーティの拡張機能の種類は、文字列として取り込まれます。
  • TIMEとTIMETZのデータ型は文字列として取り込まれます。
  • 自動データ変換テーブルにリストされていない PostgreSQL 組み込みデータ型は、文字列として取り込まれます。
  • 数値データ型の場合: NaN は null に変換されます。
  • 日付とタイムスタンプの場合: BC 日付または 9999AD より後の日付はサポートされていません。
  • 無限大は、日付、タイムスタンプ、または間隔ではサポートされていません。

パーティション テーブル

  • PostgreSQL パーティション テーブルがサポートされています。
  • 各パーティションは、レプリケーションのために個別のテーブルとして扱われます。
  • パーティションを追加または削除するには、テーブルの完全な更新が必要です。

特定の PostgreSQL バリエーションの制限事項

Amazon RDS と Aurora

  • rds.logical_replication パラメーターは、1に設定する必要があります。

Azure Database for PostgreSQL

  • サーバー パラメーターで論理レプリケーションを有効にする必要があります。
  • 単一サーバー展開の場合、論理レプリケーションは General Purpose レベルと Memory Optimized レベルでのみ使用できます。
  • フレキシブル サーバーの展開では、論理レプリケーションはすべての層でサポートされます。
  • max_wal_slot_keep_size parameter は読み取り専用で、-1 (無限) で固定され、構成できません。

Google Cloud SQL for PostgreSQL

  • cloudsql.logical_decoding フラグを有効にする必要があります。
  • Cloud SQL では、max_wal_slot_keep_sizeの構成は許可されません。既定では、-1 (無限) に固定されています。
  • Last updated on