トランザクションのロールバックは ClickHouse にレプリケートされますか？
ClickHouse では、ソースの Postgres より長くデータを保持できますか？
Postgres から ClickHouse に流れるデータを、どのようにエンリッチできますか？
複数のPostgresインスタンスから、1つまたは複数のClickHouseサービスへレプリケートできますか？
アイドル状態は Postgres CDC (変更データキャプチャ) ClickPipe にどのような影響がありますか？
ClickPipes for Postgres では、TOAST カラムはどのように処理されますか？
ClickPipes for Postgres では生成カラムはどのように処理されますか？
Postgres CDCの対象にするには、テーブルに主キーが必要ですか？
- 主キー: 最もわかりやすい方法は、テーブルに主キーを定義することです。これにより各行に一意の識別子が与えられ、更新や削除を追跡するうえで重要になります。この場合、REPLICA IDENTITY は
DEFAULT (既定の動作) に設定できます。
- Replica Identity: テーブルに主キーがない場合は、レプリカアイデンティティ を設定できます。レプリカアイデンティティ は
FULL に設定でき、この場合は行全体を使って変更を識別します。あるいは、テーブルに一意な索引がある場合はその索引を使用するように設定し、REPLICA IDENTITY を USING INDEX index_name に設定することもできます。
レプリカアイデンティティ を FULL に設定するには、次の SQL コマンドを使用します。
ALTER TABLE your_table_name REPLICA IDENTITY FULL;
REPLICA IDENTITY FULL を使用すると、変更されていない TOAST カラムもレプリケーションの対象になります。詳しくはこちらをご覧ください。
REPLICA IDENTITY FULL の使用は、パフォーマンスに影響する可能性があるほか、WAL の増加が速くなる場合がある点に注意してください。特に、主キーがなく、更新や削除が頻繁に発生するテーブルでは、変更ごとにより多くのデータをログに記録する必要があるため、その影響が大きくなります。テーブルの主キーやレプリカアイデンティティの設定について不明な点がある場合、または設定の支援が必要な場合は、サポートチームまでお問い合わせください。
また、主キーとレプリカアイデンティティのいずれも定義されていない場合、ClickPipes はそのテーブルの変更をレプリケートできず、レプリケーション処理中にエラーが発生する可能性があります。そのため、ClickPipe を設定する前にテーブルのスキーマを確認し、これらの要件を満たしていることを確認することをお勧めします。
Postgres CDC (変更データキャプチャ) でパーティション化テーブルはサポートされていますか？
パブリック IP を持たない、またはプライベートネットワーク内にある Postgres データベースに接続できますか？
-
SSH トンネリング
- ほとんどのユースケースに適しています
- セットアップ手順はこちらをご覧ください
- すべてのリージョンで利用できます
-
AWS PrivateLink
- 次の 3 つの AWS リージョンで利用できます。
- us-east-1
- us-east-2
- eu-central-1
- 詳しいセットアップ手順については、PrivateLink ドキュメントをご覧ください
- PrivateLink を利用できないリージョンでは、SSH トンネリングを使用してください
UPDATE と DELETE はどのように処理されますか？
_peerdb_ バージョンカラムを使用) を持つ新しい行として取り込みます。ReplacingMergeTree テーブルエンジンは、順序キー (ORDER BY カラム) に基づいてバックグラウンドで定期的に重複排除を行い、最新の _peerdb_ バージョンを持つ行だけを保持します。
Postgres の DELETE は、削除済みとしてマークされた新しい行 (_peerdb_is_deleted カラムを使用) として伝播されます。重複排除プロセスは非同期のため、一時的に重複が見える場合があります。これに対処するには、クエリレイヤーで重複排除を行う必要があります。
また、デフォルトでは、Postgres は DELETE 操作時に、主キーまたは レプリカアイデンティティ に含まれないカラムの値を送信しない点にも注意してください。DELETE 時に行全体のデータを取得したい場合は、REPLICA IDENTITY を FULL に設定できます。
詳細については、以下を参照してください。
PostgreSQL で主キーカラムを更新できますか？
PostgreSQL での主キー更新は、デフォルトでは ClickHouse に正しく反映できません。これは、ReplacingMergeTree の重複排除が ORDER BY カラム (通常は主キーに対応) に基づいて動作するためです。PostgreSQL で主キーを更新すると、ClickHouse では既存の行の更新ではなく、異なるキーを持つ新しい行として扱われます。その結果、ClickHouse テーブル内に古い主キー値と新しい主キー値の両方が存在する可能性があります。
ClickPipes for Postgres CDC (変更データキャプチャ) のコストはいくらですか？
レプリケーションスロットのサイズが増え続ける、または減らないのはなぜですか？
-
データベースアクティビティの急増
- 大規模なバッチ更新、大量挿入、または大きなスキーマ変更により、短時間で大量の WAL データが生成されることがあります。
- レプリケーションスロットは、これらの WAL レコードが消費されるまで保持するため、一時的にサイズが急増します。
-
長時間実行されるトランザクション
- トランザクションが開いたままになっていると、Postgres はそのトランザクションの開始以降に生成されたすべての WAL セグメントを保持する必要があり、スロットサイズが大幅に増えることがあります。
- トランザクションが無期限に開いたままにならないよう、
statement_timeout と idle_in_transaction_session_timeout を妥当な値に設定してください。
SELECT
pid,
state,
age(now(), xact_start) AS transaction_duration,
query AS current_query
FROM
pg_stat_activity
WHERE
xact_start IS NOT NULL
ORDER BY
age(now(), xact_start) DESC;
-
メンテナンスまたはユーティリティ処理 (例:
pg_repack)
pg_repack のようなツールはテーブル全体を書き換えることがあり、短時間で大量の WAL データを生成します。- これらの処理はトラフィックの少ない時間帯に実行するか、実行中は WAL 使用量を注意深く監視してください。
-
VACUUM と VACUUM ANALYZE
- これらの処理はデータベースの健全性維持に必要ですが、特に大きなテーブルをスキャンする場合は、追加の WAL トラフィックを発生させることがあります。
- autovacuum の調整パラメータを利用するか、手動の VACUUM 処理をピーク外の時間帯に実行することを検討してください。
-
レプリケーション consumer がスロットを継続的に読み取っていない
- CDC パイプライン (例: ClickPipes) または別のレプリケーション consumer が停止、一時停止、またはクラッシュすると、WAL データがスロット内に蓄積されます。
- パイプラインが継続的に稼働していることを確認し、接続や認証の error がないか logs を確認してください。
このトピックを詳しく掘り下げたい場合は、次のブログ記事をご覧ください: Overcoming Pitfalls of Postgres Logical Decoding。
Postgresのデータ型はClickHouseにどのようにマッピングされますか？
Postgres から ClickHouse へデータをレプリケーションする際に、独自の型マッピングを定義できますか？
Postgres の JSON および JSONB カラムはどのようにレプリケートされますか？
ミラーが一時停止されると、insert はどうなりますか？
- sync では、途中でキャンセルされた場合、Postgres の confirmed_flush_lsn は更新されないため、次回の sync は中断されたものと同じ位置から開始され、データの整合性が保たれます。
- normalize では、ReplacingMergeTree における insert 順序によって重複排除が行われます。
要するに、一時停止中に sync と normalize のプロセスはいったん終了しますが、データ損失や不整合を起こすことなく再開できるため、安全に実行できます。
ClickPipe の作成は自動化できますか？また、API や CLI から実行できますか？
snapshot number of tables in parallel を増やすか、大きなテーブルに対して独自の索引付きパーティション化カラムを指定してください。
レプリケーションの設定時、パブリケーションのスコープはどのように設定すべきですか？
REPLICA IDENTITY FULL のいずれかが設定されていることを確認してください。主キーのないテーブルがある状態で、すべてのテーブルを対象とするパブリケーションを作成すると、それらのテーブルでは DELETE や UPDATE が失敗します。
データベース内で主キーのないテーブルを特定するには、次のクエリを使用できます。
SELECT table_schema, table_name
FROM information_schema.tables
WHERE
(table_catalog, table_schema, table_name) NOT IN (
SELECT table_catalog, table_schema, table_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY') AND
table_schema NOT IN ('information_schema', 'pg_catalog', 'pgq', 'londiste');
-
主キーのないテーブルを ClickPipes から除外する:
主キーのあるテーブルだけを含むようにパブリケーションを作成します。
CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
-
主キーのないテーブルを ClickPipes に含める:
主キーのないテーブルを含める場合は、それらのレプリカアイデンティティを
FULL に変更する必要があります。これにより、UPDATE および DELETE 操作が正しく機能します。
ALTER TABLE table_without_primary_key1 REPLICA IDENTITY FULL;
ALTER TABLE table_without_primary_key2 REPLICA IDENTITY FULL;
CREATE PUBLICATION clickpipes_publication FOR TABLE <...>, <...>;
ClickPipes に管理させずにパブリケーションを手動で作成する場合は、FOR ALL TABLES のパブリケーションを作成することは推奨しません。これにより、Postgres から ClickPipes へのトラフィックが増加し (パイプに含まれない他のテーブルの変更も送信されるため) 、全体的な効率が低下します。パブリケーションを手動で作成する場合は、パイプに追加する前に、追加したいテーブルをパブリケーションに含めてください。
Postgres の read replica / hot standby からレプリケーションする場合は、プライマリインスタンス上で独自のパブリケーションを作成する必要があります。作成したパブリケーションは自動的に standby に伝播されます。standby ではパブリケーションを作成できないため、この場合 ClickPipe でパブリケーションを管理することはできません。
推奨される max_slot_wal_keep_size の設定
- 最低限:
max_slot_wal_keep_size は、少なくとも 2 日分 の WAL データを保持できるように設定します。
- 大規模なデータベース向け (トランザクション量が多い場合) : 1 日あたりの WAL 生成量のピーク時の 2～3 倍 を少なくとも保持します。
- ストレージ容量に制約がある環境向け: レプリケーションの安定性を確保しつつ、ディスク容量の枯渇を避ける ため、控えめに調整します。
適切な設定値を決めるには、WAL の生成率を測定します。
PostgreSQL 10以降
SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), '0/0') / 1024 / 1024 AS wal_generated_mb;
PostgreSQL 9.6 以下の場合:
SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), '0/0') / 1024 / 1024 AS wal_generated_mb;
- 上記のクエリを、1日のさまざまな時間帯、特にトランザクション量が多い時間帯に実行します。
- 24時間あたりに生成されるWALの量を計算します。
- 十分な保持期間を確保するため、その値に2倍または3倍を掛けます。
max_slot_wal_keep_size を、算出した値 (MB または GB) に設定します。
例
データベースが1日あたり100 GBのWALを生成する場合は、次のように設定します。
max_slot_wal_keep_size = 200GB
ログに ReceiveMessage EOF エラーが表示されています。これは何を意味しますか？
ReceiveMessage は、Postgres のロジカルデコードプロトコルで、レプリケーションストリームからメッセージを読み取る関数です。EOF (End of File) エラーは、レプリケーションストリームの読み取り中に、Postgres サーバーへの connection が予期せず閉じられたことを示します。
これは回復可能で、まったく致命的ではないエラーです。ClickPipes は自動的に再接続を試み、レプリケーションを再開します。
これは、いくつかの理由で発生する可能性があります。
- ネットワークの問題: 一時的なネットワーク障害によって、connection が切断されることがあります。
- Postgres サーバーの再起動: Postgres サーバーが再起動された、またはクラッシュした場合、connection は失われます。
レプリケーションスロットが無効化されました。どうすればよいですか？
max_slot_wal_keep_size の設定値が小さいことです (たとえば数 GB) 。この値を増やすことを推奨します。max_slot_wal_keep_size の調整については、こちらのセクションを参照してください。レプリケーションスロットの無効化を防ぐには、理想的には少なくとも 200GB に設定してください。
まれに、max_slot_wal_keep_size が設定されていない場合でもこの問題が発生することがあります。これは PostgreSQL の複雑でまれな不具合が原因である可能性がありますが、原因は依然として明らかになっていません。
ClickPipe がデータを取り込んでいる際に、ClickHouse でメモリ不足 (OOM) が発生しています。対処方法はありますか？
-
JOIN の一般的な最適化手法の 1 つは、右側のテーブルが非常に大きい LEFT JOIN がある場合です。この場合は、クエリを RIGHT JOIN を使う形に書き換え、大きいテーブルを左側に移してください。これにより、クエリプランナーはよりメモリ効率よく処理できるようになります。
-
JOIN の別の最適化方法としては、subqueries や CTEs を使ってテーブルを明示的に絞り込み、その後それらのサブクエリ同士で JOIN を実行する方法があります。これにより、プランナーは、行を効率よく絞り込み、JOIN を実行するためのヒントを得られます。
初期ロード中に invalid snapshot identifier が表示されます。どうすればよいですか？
invalid snapshot identifier エラーは、ClickPipes と Postgres データベース間の接続が切断されたときに発生します。これは、ゲートウェイのタイムアウト、データベースの再起動、またはその他の一時的な問題が原因で起こることがあります。
初期ロードの実行中は、Postgres データベースに対してアップグレードや再起動などの影響の大きい操作は行わず、データベースへのネットワーク接続が安定していることを確認することを推奨します。
この問題を解決するには、ClickPipes UI から再同期をトリガーできます。これにより、初期ロードは最初からやり直されます。
Postgres でパブリケーションを削除するとどうなりますか？
- Postgres で、同じ名前と必要なテーブルを含む新しいパブリケーションを作成します
- ClickPipe の Settings タブで ‘Resync tables’ ボタンをクリックします
この再同期が必要なのは、再作成したパブリケーションには、名前が同じでも Postgres 内で異なる Object Identifier (OID) が割り当てられるためです。再同期プロセスにより宛先テーブルが更新され、接続が復元されます。
必要に応じて、まったく新しいパイプを作成することもできます。
なお、パーティション化されたテーブルを扱っている場合は、適切な設定でパブリケーションを作成してください:
CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);
Unexpected Datatype エラーや Cannot parse type XX ... が表示される場合はどうすればよいですか？
レプリケーション/slot の作成中に invalid memory alloc request size <XXX> のような error が発生する
ソースのPostgresデータベースからデータが削除されても、ClickHouse に完全な履歴レコードを保持しておく必要があります。ClickPipes で Postgres の DELETE 操作と TRUNCATE 操作を完全に無視できますか？
CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');
ドットを含むテーブルをレプリケートできないのはなぜですか？
初期ロードは完了したのに、ClickHouse にデータがない、または一部欠けています。考えられる原因は何ですか？
- ユーザーにソーステーブルを読み取るための十分な権限があるか。
- ClickHouse 側に、行を除外してしまう可能性のある行ポリシーがないか。
フェイルオーバーを有効にしたレプリケーションスロットを ClickPipe に作成させることはできますか？
Advanced Settings セクションで以下のスイッチを有効にすることで、ClickPipes にフェイルオーバー対応のレプリケーションスロットを作成させることができます。なお、この機能を使用するには Postgres 17 以降が必要です。
ソース側が適切に設定されていれば、Postgres のリードレプリカへのフェイルオーバー後もスロットは保持され、データレプリケーションを継続できます。詳細はこちらをご覧ください。
Internal error encountered during logical decoding of aborted sub-transaction のようなエラーが表示される
ReorderBufferPreserveLastSpilledSnapshot ルーチンから発生していることから、ロジカルデコードがディスクにスピルされたスナップショットを読み取れていない可能性があります。logical_decoding_work_mem をより大きな値に増やしてみることをお勧めします。
CDC (変更データキャプチャ) レプリケーション中に error converting new tuple to map や error parsing logical message のようなエラーが表示される
最初にレプリケーション対象から除外したカラムを含めることはできますか？
ClickPipe が Snapshot に入ったのにデータが流れてこない場合、何が原因として考えられますか？
並列スナップショットでパーティションの取得に時間がかかる
レプリケーションスロットの作成がトランザクションによってロックされている
CREATE_REPLICATION_SLOT クエリが Lock 状態のまま停止していることがあります。これは、Postgres がレプリケーションスロットの作成時に使用するオブジェクトに対して、別のトランザクションがロックを保持していることが原因である可能性があります。
どのクエリがブロックしているかを確認するには、Postgres ソースで以下のクエリを実行してください。
SELECT
blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query,
blocking.state AS blocking_state
FROM pg_locks blocked_lock
JOIN pg_stat_activity blocked
ON blocked_lock.pid = blocked.pid
JOIN pg_locks blocking_lock
ON blocking_lock.locktype = blocked_lock.locktype
AND blocking_lock.database IS NOT DISTINCT FROM blocked_lock.database
AND blocking_lock.relation IS NOT DISTINCT FROM blocked_lock.relation
AND blocking_lock.page IS NOT DISTINCT FROM blocked_lock.page
AND blocking_lock.tuple IS NOT DISTINCT FROM blocked_lock.tuple
AND blocking_lock.virtualxid IS NOT DISTINCT FROM blocked_lock.virtualxid
AND blocking_lock.transactionid IS NOT DISTINCT FROM blocked_lock.transactionid
AND blocking_lock.classid IS NOT DISTINCT FROM blocked_lock.classid
AND blocking_lock.objid IS NOT DISTINCT FROM blocked_lock.objid
AND blocking_lock.objsubid IS NOT DISTINCT FROM blocked_lock.objsubid
AND blocking_lock.pid != blocked_lock.pid
JOIN pg_stat_activity blocking
ON blocking_lock.pid = blocking.pid
WHERE NOT blocked_lock.granted;
