Managed Postgres のデータ移行

ClickHouse Managed Postgres への 4 つの移行方法を比較し、ソースデータベースとダウンタイム要件に適した方法を選択します。

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

方法	継続的なレプリケーション (CDC)	実行場所	最適な用途
ClickPipes	はい	ClickHouse Cloud コンソール	ほとんどの移行 — 初期ロードと CDC を標準で備えたガイド付きウィザード
PeerDB	はい	セルフホスト (Docker)	ClickPipes UI では対応していない移行元やワークフロー
pg_dump と pg_restore	いいえ	お使いのローカルマシン	ダウンタイムを許容できる、小規模または静的なデータセットの一回限りの移行
論理レプリケーション	はい	移行元と移行先の Postgres	ネイティブな Postgres レプリケーションを直接制御したい場合。サードパーティ製ツールは不要

​

ClickPipes

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

​

PeerDB

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

​

pg_dump と pg_restore

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

​

論理レプリケーション

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

​

移行後

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