ClickHouse Managed Postgres のデータ移行

ClickHouse Managed Postgres への移行には、4 つの方法があります。どの方法が適しているかは、 継続的なレプリケーションが必要かどうか、どこから移行するのか、そして切り替え時に アプリケーションがどの程度のダウンタイムを許容できるかによって異なります。

ClickPipes は、ほとんどの移行で推奨される方法です。すべて ClickHouse Cloud コンソール内で完結し、ソースへの接続、スキーマのエクスポートとインポート、さらに CDC の有無を選んで初期ロードを開始するまでを順を追って案内します。事前構築済みのソースコネクタは、Amazon RDS、Aurora、Supabase、Google Cloud SQL、Azure Flexible Server、Neon、Crunchy Bridge、TimescaleDB、および汎用的な Postgres インスタンスに対応しています。

PeerDB は、Docker 経由で実行するセルフホストの移行 ツールです。移行元やワークフローが ClickPipes ウィザードに適していない場合に使用します。たとえば、多数のデータベースにまたがって ピアの作成をスクリプト化する必要がある場合や、移行を完全に自社ネットワーク内で実行したい場合です。 PeerDB は、索引、制約、トリガーを自動的には移行しません。データの移行後に、 それらを移行先で再作成します。

pg_dump and pg_restore は移行元のスナップショットを取得し、それを移行先に適用します。継続的な レプリケーションは行われないため、ダンプと復元の実行中は移行元への書き込みを 停止する必要があります。これは、小規模または静的なデータセット、あるいは メンテナンスウィンドウを確保できる非本番環境に適した選択肢です。

論理レプリケーション では、Postgresネイティブのパブリケーションとサブスクリプションを使って、移行元から 移行先へ変更をストリーミングします。wal_level、レプリケーションスロット、 および REPLICATION 権限は自分で設定します。途中に サードパーティ製ツールが介在することはありません。レプリケーションの 仕組みを完全に制御したい場合や、環境上の制約で外部の移行ツールを使えない場合は、 この方法を選んでください。

データの移行が進み始めたら、アプリケーショントラフィックを切り替える前に、データ検証 を使用して、移行元と移行先で行数と内容が一致していることを確認してください。移行のよくある質問 では、よくあるエラーと復旧手順を確認できます。

Supabase から移行する場合は、Supabase から ClickHouse Managed Postgres への移行ガイド を参照してください。手順を追って移行する方法を確認できます。