Snowflake Connector for PostgreSQL の特徴

重要

PostgreSQL 用Snowflakeコネクタにご興味をお持ちいただきありがとうございます。現在、大幅に改善されたエクスペリエンスを提供する次世代ソリューションに焦点を当てています。したがって、このコネクタを一般提供ステータスに移行することは、現在の製品ロードマップにはありません。このコネクタはプレビュー機能として引き続き使用できますが、将来のバグ修正および改善のサポートは保証されないことに注意してください。新しいソリューションは :doc:` PostgreSQL 用Openflowコネクタ</user-guide/data-integration/openflow/connectors/postgres/about>` として利用可能で、より優れたパフォーマンス、カスタマイズ性、強化された展開オプションが含まれます。

バージョンサポート

Snowflake Connector for PostgreSQL は公式にサポートされているすべての PostgreSQL バージョンをサポートします。Snowflakeは、お客様が新しいバージョンに移行すると、古いバージョンのサポートを終了します。Snowflakeは、新しいバージョンがリリースされたときに、そのサポートを発表します。

コネクタはさまざまな PostgreSQL クラウドバージョンをサポートしていますが、追加設定が必要な場合があります。詳細については、 Snowflake Connector for PostgreSQL データソースの前提条件 をご参照ください。

サポートされている PostgresSQL のバージョンは以下のとおりです。

サポートされている PostgreSQL バージョン

11

12

13

14

15

16

17

標準

有り

有り

有り

有り

有り

有り

有り

AWS RDS

有り

有り

有り

有り

有り

有り

有り

Amazon Aurora

有り

有り

有り

有り

有り

有り

GCP Cloud SQL

有り

有り

有り

有り

有り

有り

Azure Database

有り

有り

有り

有り

有り

有り

サーバー設定

必要に応じて、 PostgreSQL サーバーの次の設定を確認して調整します。

wal_level

logical に設定。

コネクタは、主キーに依存して、変更を宛先テーブルにマージします。次の設定により、先行書き込みログ(WAL)記録には主キー情報が含まれるようになります。

max_replication_slots

データベースエージェントでこのデータベースのデータソース構成エントリごとに1を追加します。

max_connections

データベースエージェントでこのデータベースのデータソース構成エントリごとに1を追加します。

max_wal_senders

データベースエージェントでこのデータベースのデータソース構成エントリごとに1を追加します。

パブリケーション

コネクタには、複製のテーブルにアクセスするための `PostgreSQLパブリケーション<https://www.postgresql.org/docs/current/logical-replication-publication.html>`_ が必要です。

  • データベースエージェントは、データソースごとに1つのパブリケーションだけをサポートします。単一のPostgreSQL サーバー で複数のパブリケーションを使用する必要がある場合、そのサーバーをそれぞれに独自のパブリケーションを持つ個別のデータソースとして複数回構成できます。

  • パブリケーションには、INSERTUPDATEDELETE および TRUNCATE を含む、データへのすべての変更が含まれている必要があります。

  • パブリケーションは ALL TABLES またはテーブルのサブセットに対して設定できますが、最適なパフォーマンスのために、複製する必要があるテーブルのみを追加します。コネクタは、パブリケーションに含まれるテーブルからの変更のみを受信します。

  • テーブルは、すべての列または列のサブセットとともにパブリケーションに追加できます。列のサブセットを使用して追加する場合は、 ADD_TABLE_WITH_COLUMNSプロシージャ を使用します。

警告

テーブルが列のサブセットを持つパブリケーションに追加され、その後、 :ref:`ADD_TABLES<label-postgres_connector_add_source_table>`プロシージャを使用して複製が有効になっている場合、パブリケーションから欠落している列は宛先テーブルで削除済みとしてマークされます。後でパブリケーションに追加の列を追加すると、テーブルは永久に失敗したものとしてマークされます。

パブリケーション構成の詳細については、 パブリケーションの構成 をご参照ください。

複製スロット

データとスキーマの変更を複製するために、コネクタは 複製スロット を作成します。スロットは、特定のデータソースの最初のテーブルが複製に追加されたときに作成され、そのデータソースからのすべてのテーブルに使用されます。

スロットの名前は sf_db_conn_rs_kbmd_<data-source-name> という構造になっており、 <data-source-name> は、データベースエージェント構成におけるデータソースの識別子です。

  • 同じデータベースに複数回接続するようにデータベースエージェントを構成する場合、複数のデータソースを追加すると、コネクタは*複数*の複製スロットを作成します。

  • 同じ PostgreSQL サーバーに接続するように複数のデータベースエージェントを構成する場合、各データベースエージェントに一意のデータソース名を指定する必要があります。

注意

データベースエージェントは、未使用の複製スロットを 削除しません。データベースエージェントを PostgreSQL インスタンスから切断するか、そのすべてのテーブルを複製から削除する場合、 WAL トリミングが中断されないように、複製スロットも手動で削除*する必要*があります。

WAL 成長と複製スロットの位置

複製スロットが作成されると、コネクタがその位置を確認して進めるまでは、 PostgreSQL が複製スロットによって保持されている位置から WAL データを保持します。コネクタは、宛先テーブルにまだマージされていない場合でも、記録がジャーナルテーブルに保存された後の位置を定期的に確認します。

  • **連続モード**では、コネクタは1分ごとに位置を確認します。

  • **スケジュールモード**では、コネクタは構成されたスケジュールに基づいて位置を確認します。スケジュールが長くなると、 WAL が大きくなる*ことに注意してください。

WAL 用 PostgreSQL サーバーに十分なディスク容量があることを確認する必要があります。WAL が継続的に増加していることを検出した場合、以下を確認してください。

  • データベースエージェントが接続され、コネクタはアクティブにデータを複製していますか?そうでない場合は、複製スロットは提出されておらず、 WAL トリミングはブロックされます。

  • 複製は複製されたテーブルのデータ変更に対応していますか?そうでない場合は、ソースのデータ変更とSnowflake宛先テーブルの表示の間のラグが大きくなり続けるため、複製スロットの進捗が遅すぎます。一部のテーブルを複製から削除するか、コンピューティングウェアハウスのサイズを増やす必要があります。

複製スロットが進まないことが原因で WAL が増加する場合、PostgreSQL の max_wal_size 設は影響しません。

Tip

重要な状況では、コネクタで使用される複製スロットを手動で削除できます。これにより、コネクタ内で実行されている複製は中断されますが、 WAL をトリミングする PostgreSQL が有効になりディスク容量を解放します。

主キーとテーブルのレプリカID

コネクタは、主キーに依存して、変更を宛先テーブルにマージします。その結果、

エージェント認証

現在サポートされている認証方法は、ユーザー名とパスワードのみです。データベースエージェントの構成のすべてのデータソースエントリには、独自の認証情報のセットが含まれ、これらはデータソースによって異なる場合があります。

データベースエージェントのユーザーには、 REPLICATION 属性、またはこれが適用できない場合は SUPERUSER のロールが必要です。

データベースエージェントのユーザーを作成する方法については、 必要なユーザーを作成する をご参照ください。

ソースデータベースへのデータベースエージェントのアクセスを保護する方法の詳細については、 `PostgreSQLドキュメント<https://www.postgresql.org/docs/current/logical-replication-security.html>`_ をご参照ください。