監視とメトリクス
ClickHouse Managed Postgres インスタンスのメトリクスにアクセスするにはどうすればよいですか？
ClickHouse Managed Postgres インスタンスの 監視 タブから、CPU、メモリ、IOPS、ストレージ使用量を ClickHouse Cloud コンソール上で直接確認できます。 さらに、クエリインサイト タブでクエリを詳細に分析するために、Query Performance Insightsを確認できます。バックアップと復旧
どのようなバックアップ オプションを利用できますか？
ClickHouse Managed Postgres には、毎日の自動バックアップと継続的な WAL アーカイブが含まれており、7 日間の保持期間内であれば任意の時点へのポイントインタイム リカバリが可能です。バックアップはオブジェクトストレージに保存されます。 バックアップの頻度、保持期間、ポイントインタイム リカバリの実行方法の詳細については、バックアップと復元 のドキュメントを参照してください。インフラストラクチャと自動化
どのクラウドプロバイダーがサポートされていますか？
ClickHouse Managed Postgres は、AWS でパブリックベータとして利用できます。GCP はプライベートプレビュー中です。GCP プライベートプレビューの順番待ちリストにはこちらから登録できます。詳細は発表記事をご覧ください。詳しくはサポートされているクラウドプロバイダーを参照してください。ClickHouse Managed Postgres で Terraform は利用できますか？
はい。ClickHouse Terraform プロバイダーのclickhouse_postgres_service リソースを使用して、ClickHouse Managed Postgres サービスを作成および管理できます。詳細は Terraform リファレンス を参照してください。また、ClickHouse Cloud コンソール または OpenAPI を使用してインスタンスを作成および管理することもできます。
拡張機能と設定
サポートされている拡張機能を教えてください。
ClickHouse Managed Postgres には、PostGIS、pgvector、pg_cron をはじめとする一般的なものを含め、90 種類を超える PostgreSQL 拡張機能が用意されています。利用可能な拡張機能の一覧とインストール手順については、拡張機能 のドキュメントを参照してください。PostgreSQL の設定パラメータはカスタマイズできますか？
はい。コンソールの Settings タブで、PostgreSQL と PgBouncer の設定パラメータを変更できます。使用可能なパラメータと変更手順の詳細については、Settings のドキュメントを参照してください。接続プーリング
PgBouncer 経由で prepared statement does not exist エラーが発生するのはなぜですか？
ClickHouse Managed Postgres は PgBouncer を トランザクションプーリング モードで実行しています。このモードでは、バックエンドの Postgres 接続がクライアントに割り当てられるのは 1 つのトランザクションの間だけで、その後は pool に返却されます。そのため、同じクライアントからの次のトランザクションが別のバックエンドで処理される場合があります。
PgBouncer は プロトコルレベルのプリペアドステートメント を追跡します。ほとんどのドライバーは、これを拡張クエリプロトコル (Parse、Bind、Execute メッセージ) で送信します。ステートメントを未認識のバックエンドで実行する場合、PgBouncer はまずそのバックエンド上でステートメントを準備します。各バックエンド接続は最大 max_prepared_statements 個 (デフォルトは 200) のプリペアドステートメントを保持します。そのため、ほとんどのドライバーはデフォルト設定のまま PgBouncer 経由で利用できます。
PgBouncer 経由では動作しないもの:
- SQL レベルのプリペアドステートメント。 PgBouncer は SQL として送信された
PREPAREおよびEXECUTEを追跡しないため、PREPAREを実行していないバックエンドにEXECUTEが送られる可能性があります。 - SQL の
DEALLOCATEによるステートメントの解放。 PgBouncer はバックエンド上でステートメントをリネームするため、クライアント側のステートメント名を指定したDEALLOCATEは失敗します。トランザクション内でこれが起きるとトランザクションが中断され、以降のステートメントはcurrent transaction is abortedで失敗します。libpq 17 以降をベースにしたドライバーは、代わりにプロトコルレベルのCloseメッセージでステートメントを解放するため、PgBouncer で問題なく処理されます。 - 複数のラウンドトリップに分割された名前なしステートメント。 一部のドライバーのモードでは、名前なしステートメントの
Parseをあるラウンドトリップで送信し、そのBindを次のラウンドトリップで送信します。PgBouncer は 2 回目のラウンドトリップを別のバックエンドで実行する可能性があり、その場合はunnamed prepared statement does not existで失敗するか、気付かないうちに他のクライアントのステートメントが実行されてその結果が返されます。
prepared statement does not existエラーが集中的に発生する (特にバックフィル中や同時実行数の多い書き込み時)- 挿入処理が「サイレントに失敗」したように見える — ステートメントがエラーになってドライバーが再試行し、その結果、バッチが部分的にしか適用されなかったり、破棄されたりすることがある
- ステートメントが解放された後、トランザクションが
current transaction is abortedで失敗する - 別のクエリに属する行が返される
ワークロードが SQL レベルの
PREPARE に依存している場合は、PgBouncer プーラーを経由せず、PostgreSQL に直接(ポート 5432)接続してください。プール接続用エンドポイントと直接接続用エンドポイントの使い分けについて詳しくは、接続を参照してください。
移行後にクエリが cached plan must not change result type で失敗するのはなぜですか？
PgBouncer は、Postgres との各接続上でプリペアドステートメントを保持し、同じ SQL テキストに対して再利用します。クエリが返すカラムの型を変更するスキーマ変更 (例：integer から bigint) を行うと、そのクエリは PgBouncer 経由では cached plan must not change result type エラーで失敗し続けます。この状態は、PgBouncer が Postgres との接続を張り替えるまで、新しいクライアント接続から実行しても解消されません。ドライバーによっては、エラーにならずに古い結果型のままデコードし、誤った値を返す場合もあります。直接接続の場合は、各接続で失敗するのは最大 1 回だけで、その後は自動的に回復します。
回復するには、該当データベースに対する PgBouncer の Postgres 接続を閉じます。閉じると、PgBouncer が新しい接続を開きます。PgBouncer は Postgres にローカルで接続するため、その接続には client_addr がありません。以下のクエリを、直接接続 (ポート 5432) 経由で、アプリケーションが接続に使用しているのと同じユーザーで実行してください。このクエリが終了させるのはアプリケーションのユーザーによる PgBouncer の接続のみです。そのため、その時点で PgBouncer 経由で実行中のトランザクションは失敗しますが、直接接続には影響しません。
prepare: :unnamed を指定した Postgrex、cache_describe を使用する pgx など) は、この影響を受けません。
PgBouncer 経由で unsupported startup parameter エラーが発生するのはなぜですか？
PgBouncer は、プールされた Postgres 接続全体に一貫して適用できない接続時の設定を拒否するため、FATAL: unsupported startup parameter: ... または unsupported startup parameter in options: ... というエラーになります。主なケースは次のとおりです。
extra_float_digits：pgjdbc 42.7.4 以前 (Spring Boot 3 で使用する場合など) および sqlx は、接続のたびにこのパラメータを送信します。pgjdbc は 42.7.5 以降にアップグレードしてください。sqlx の場合は、PgConnectOptionsでextra_float_digits(None)を設定してください。- 接続文字列で指定した
search_pathなどの設定：JDBC URL のcurrentSchema、Npgsql 接続文字列のSearch Path、options=-c ...、Django のOPTIONS["options"]などが該当します。この場合は、ALTER ROLE ... SETまたはALTER DATABASE ... SETでデフォルト値を設定するか、トランザクション内でSET LOCALを使用するか、PgBouncer を介さずに直接接続してください。
application_name と TimeZone はサポートされています。
PgBouncer 経由では SET コマンドが保持されないのはなぜですか？
トランザクションプーリングモードでは、セッションレベルの SET はクライアントではなく、それを実行した Postgres 接続に適用されます。そのため、クライアントから後で実行されるトランザクションは、その設定が反映されていない別の接続上で実行される可能性があり、逆に、設定が反映された接続上で他のクライアントのトランザクションが実行される可能性もあります。これは SET ROLE にも当てはまるため、切り替えたロールが別のクライアントのクエリに適用されてしまうおそれがあります。トランザクション内で SET LOCAL を使用するか、ALTER ROLE ... SET または ALTER DATABASE ... SET でデフォルト値を設定してください。セッション状態に依存するワークロードでは、PgBouncer を介さずに直接接続してください。
PgBouncer 経由で移行がハングしたり、アドバイザリーロックの解放に失敗したりするのはなぜですか？
多くの移行ツールは、移行が同時に 1 つしか実行されないようにセッションレベルのアドバイザリーロックを取得し、別のステートメントでそのロックを解放します。PgBouncer を経由すると、解放処理が別の Postgres 接続上で実行されることがあり、その場合ロックはプール内の接続に残ったままになります。その結果、以降の移行は直接接続を使用した場合でも待機し続けるか、failed to release advisory lock のようなエラーで失敗します。セッションアドバイザリーロックを使用するツールには、golang-migrate、sqlx、Kysely の Migrator、Rails、transactional-lock=false を指定した Flyway、migration_lock: :pg_advisory_lock を指定した Ecto などがあります。
移行は直接接続 (ポート 5432) で実行してください。リークしたロックはアイドル状態のセッションが保持しているのに対し、実行中の移行はアクティブなセッションからロックを保持しています。リークしたロックを解消するには、こちらも直接接続を使用し、データベース内でアドバイザリーロックを保持しているアイドル状態のセッションのみを終了してください。
PgBouncer の max_client_conn 設定は何を意味し、Postgres の max_connections とどう関係しますか？
これらが制御する対象は異なります。
- Postgres
max_connectionsは、PostgreSQL 自体への バックエンド 接続数の上限です。こちらはコストの高い数値で、各バックエンドがメモリとプロセススロットを消費します。 - PgBouncer
max_client_connは、同時にプーラー内で開ける クライアント 接続数の上限です。PgBouncer は、多数のクライアント接続を、はるかに少ない数のバックエンド接続に多重化します。
max_connections が 500 に設定されたインスタンスでは、プーラーで 2500 のクライアント接続を受け付けます。プーラーで接続エラーが発生している場合、表面的なクライアント接続上限に達しているというよりも、poolごとのバックエンド上限 (default_pool_size、またはデータベースごとの max_db_connections) に達している可能性のほうがはるかに高いです。
ご利用のインスタンスの値を確認するには、PgBouncer (ポート 6432) 経由で特別な pgbouncer データベースに接続し、SHOW CONFIG を実行します。
データベースの機能
複数のデータベースとスキーマを作成できますか？
はい。ClickHouse Managed Postgres は PostgreSQL の完全なネイティブ機能を備えており、1つのインスタンス内で複数のデータベースとスキーマをサポートしています。標準的な PostgreSQL コマンドを使用して、データベースとスキーマを作成・管理できます。ロールベースのアクセス制御 (RBAC) はサポートされていますか？
ClickHouse Managed Postgres インスタンスでは superuser 権限をフルに利用できるため、標準の PostgreSQL コマンドを使用してロールを作成し、権限を管理できます。コンソール との統合を含む強化された RBAC 機能は、今年中に提供される予定です。
アップグレード
PostgreSQL のバージョンアップグレードはどのように行われますか？
マイナーアップグレードとメジャーバージョンアップグレードはいずれもフェイルオーバーによって実施され、通常、ダウンタイムは数秒程度です。アップグレードを適用する曜日と UTC での 2 時間の時間枠を制御するために、スケジュールされたアップグレード を設定できます。詳細については、Upgrades のドキュメントを参照してください。移行
ClickHouse Managed Postgres への移行にはどのようなツールを利用できますか？
ClickHouse Managed Postgres では、いくつかの移行方法をサポートしています。- pg_dump と pg_restore: 小規模なデータベースや一回限りの移行に適しています。pg_dump と pg_restore ガイドを参照してください。
- 論理レプリケーション: ダウンタイムを最小限に抑える必要がある大規模なデータベースに適しています。Logical replication ガイドを参照してください。
- PeerDB: 他の Postgres ソースからの CDC (変更データキャプチャ) ベースのレプリケーションに適しています。PeerDB migration ガイドを参照してください。
完全マネージド型の移行機能は近日提供予定です。