Postgres 向け ClickPipes がフェイルオーバーレプリケーションスロットに対応

はじめに #

すべての Postgres ClickPipes ユーザーに最大限の信頼性と柔軟性を提供し続けるため、フェイルオーバーを有効化したロジカルレプリケーションスロットを作成できるトグルを追加しました。これにより、ClickPipes は高可用性 (HA) 構成とシームレスに連携し、フェイルオーバー後もレプリケーションスロットを維持できるようになります。

背景 #

Postgres にはホットスタンバイと呼ばれる機能があり、クエリ用に Postgres インスタンスの「リードレプリカ」を立ち上げることができます。最近のホットスタンバイではロジカルデコーディングを実行できるようになり (2023年リリースの Postgres 16 で導入)、CDC ワークロードをプライマリインスタンスから分離できるようになりました。しかし、作成されたスロットはそのクラスター専用であり、どのような形でもレプリケーションされなかったため、これだけでは CDC の高可用性を実現するには不十分でした。Postgres 17 (2024年リリース) ではロジカルレプリケーションフェイルオーバーを有効化することでこの課題に対応しました。これは実質的に、プライマリインスタンス上のスロットを選択して 1 つ以上のスタンバイに定期的に同期させ、スタンバイの昇格後にロジカルデコーディングを問題なく再開できるようにする仕組みです。

なぜこの機能が必要なのか？ #

Postgres は典型的なトランランザクション処理向けの「コア」データベースであり、シングルライター設計であるため、スタンバイを通じた高可用性がしばしば求められてきました。一方で、クエリワークロードが多様化するにつれて、それぞれの強みを活かすために CDC 経由で Postgres から他のデータソースへデータをレプリケーションすることが一般的になりつつあります。ごく最近まで、Postgres 自体は HA であったものの、それらのパイプラインは HA ではありませんでした。ロジカルレプリケーションフェイルオーバーによって、これがついに現実のものとなります。

手順 #

ClickPipe 自体にはフェイルオーバーを有効にするトグルがあるだけですが、フェイルオーバー対応スロットを使用できるように準備するプロセス全体はより複雑であり、いくつかの前提条件があります。オンプレミスの Postgres を使用している場合は、以下の手順で構成できます。マネージドプロバイダー (AWS RDS や Google CloudSQL など) を通じて Postgres を実行している場合は、プロバイダーと連携して Postgres の構成設定を適切にチューニングする必要があります。PlanetScale for Postgres などの一部のプロバイダーは、定期メンテナンスの一環としてフェイルオーバーを実行するため、すでにこの機能をサポートしています。

1. プライマリサーバーとホットスタンバイサーバーの両方で Postgres 17 以降を実行している必要があります。ホットスタンバイは、プライマリから変更を受信するために (WAL のアーカイブとリストアではなく) 物理レプリケーションスロットを使用する必要があります。ほとんどのマネージドサービスは、すでにこの方法でリードレプリカをセットアップしています。

2. プライマリのクラッシュに対応できるようにスタンバイを構成するには、synchronous_standby_names と synchronous_commit の両方を設定する必要があります。これにより、プライマリはコミットを確認応答する前にスタンバイによる WAL 受信を確認する必要が生じるため、プライマリとスタンバイの両方がダウンしない限り、変更が確実に永続化されます。こちらも大半のマネージドサービスではすでにセットアップされていますが、必要とされる具体的な保証要件に応じて調整できます。

3. スタンバイ側で hot_standby_feedback と sync_replication_slots の設定を有効にする必要があります。sync_replication_slots は、プライマリからスロットを同期する slotsync ワーカーを開始するようスタンバイに指示します。そして、これを安定して実行するために hot_standby_feedback が必要となります。

4. ホットスタンバイで使用している物理レプリケーションスロットを、プライマリの synchronized_standby_slots に追加する必要があります。これにより、ClickPipe が使用するロジカルレプリケーションスロットに変更が送信される前に、スタンバイ側が変更を含む WAL の受信を確認するようになります。この設定がないと、スタンバイが ClickPipe より「遅れる」可能性があり、フェイルオーバー後に正常に再開できなくなる恐れがあります。

5. ClickPipe を作成する際、フェイルオーバーを有効にしたレプリケーションスロットを作成するオプションを必ず選択してください。

6. ClickPipe が作成され Running 状態になったら、スタンバイ側で pg_replication_slots をクエリし、mirror_ で始まるスロット(スロットの UUID は ClickPipe の UUID と同じです)を確認します。このスロットはプライマリから同期されており、synced と failover が true に設定されています。これで、スタンバイが昇格した際にこのスロットを使用できるようになりました。

まとめ #

ClickPipes チームは、既存コネクタの改善と、ClickHouse へのより多くのデータレプリケーション方法の提供に注力しています。ロジカルレプリケーションのフェイルオーバーがサポートされたことで、ユーザーは重要なデータのレプリケーションにおいて Postgres 向け ClickPipes を安心して利用できるようになり、リアルタイム分析のユースケースで ClickHouse の優れたクエリパフォーマンスを最大限に活用できます。また、ホットスタンバイからの直接レプリケーションも引き続きサポートしており、プライマリの負荷を軽減して他のワークロードに充てるのにも役立ちます。

Postgres 内のデータを使って ClickHouse Cloud 上でクエリを実行したい場合は、インフラ管理を必要とせず、信頼性の高いリアルタイムレプリケーションを提供する ClickPipes for Postgres の利用をおすすめします。セルフホストの ClickHouse ユーザーは、すべての Postgres 向け ClickPipes を支える、実戦で鍛え抜かれた CDC ツールである PeerDB の導入をご検討ください。