Snowflake Connector for PostgreSQL 特性¶

バージョンサポート¶

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 パブリケーションを必要とします。

データベースエージェントは、データソースごとに1つのパブリケーションのみをサポートします。1つの PostgreSQL サーバーで複数のパブリケーションを使用する必要がある場合は、そのサーバーを別のデータソースとして複数回構成し、それぞれに独自のパブリケーションを設定できます。
パブリケーションには、 INSERT、 UPDATE、 DELETE、 TRUNCATE など、データに加えられたすべての変更が含まれている必要があります。
パブリケーションは、 ALL TABLES またはテーブルのサブセットに対して設定できますが、パフォーマンスを最適化するには、複製する必要があるテーブルのみを追加します。コネクタは、パブリケーションに含まれるテーブルからの変更のみを受け取ります。
すべての列、または列のサブセットを含むテーブルをパブリケーションに追加できます。列のサブセットで追加する場合は、 ADD_TABLE_WITH_COLUMNS プロシージャを使用します。

警告

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

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

複製スロット¶

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

スロットの名前は sf_db_conn_rs_kbmd_<data-source-name> のように構成されます。 <data-source-name> はデータベースエージェントの構成におけるデータソースの識別子です。

複数のデータソースを追加して、同じデータベースに複数回接続するようにデータベースエージェントを構成すると、コネクタは 複数の 複製スロットを作成します。
同じ PostgreSQL サーバーに接続するように複数のデータベースエージェントを構成する場合、各データベースエージェントに一意のデータソース名を指定する必要があります。

注意

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

WAL の増加と複製スロットの位置¶

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

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

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

データベースエージェントが接続され、コネクタがアクティブにデータを複製しているか？そうでない場合は、複製スロットが進められておらず、 WAL トリミングをブロックしています。
複製されたテーブルのデータ変更に複製が追いついているか？そうでない場合、つまりソースでデータが変更されてからSnowflakeの宛先テーブルに表示されるまでのタイムラグが大きくなり続けている場合は、複製スロットの進行が遅すぎることを意味します。一部のテーブルを複製から削除するか、ウェアハウスのサイズを大きくする必要があります。

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

Tip

重大な状況では、コネクタが使用する複製スロットを手動で削除できます。これにより、コネクタで実行されている複製はすべて破棄されますが、 PostgreSQL で WAL をトリミングし、ディスク領域を取り戻すことができます。

主キーとテーブル複製アイデンティティ¶

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

複製が有効なテーブルには必ず主キーが必要です。キーは単一列でも複合列でもかまいません。
テーブルは、 REPLICA IDENTITY を DEFAULT に設定する必要があります。これにより、主キーが WAL で表現され、コネクタがそれを読み取れるようになります。

エージェント認証¶

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

データベースエージェントのユーザーには、 REPLICATION 属性を持つロール（適用できない場合は SUPERUSER）が必要です。

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

データベースエージェントによるソースデータベースへのアクセスのセキュリティについては、 PostgreSQL ドキュメントをご参照ください。