ClickHouse Managed Postgres よくある質問

ClickHouse Managed Postgres に関するよくある質問

​

監視とメトリクス

​

Managed Postgres インスタンスのメトリクスにアクセスするにはどうすればよいですか？

Managed Postgres インスタンスの 監視 タブから、CPU、メモリ、IOPS、ストレージ使用量を ClickHouse Cloud console 上で直接確認できます。

詳細なクエリ分析を行うための Query Performance Insights は近日提供予定です。

​

バックアップと復旧

​

どのようなバックアップ オプションを利用できますか？

Managed Postgres には、毎日の自動バックアップと継続的な WAL アーカイブが含まれており、7 日間の保持期間内であれば任意の時点へのポイントインタイム リカバリが可能です。バックアップは S3 に保存されます。

バックアップの頻度、保持期間、ポイントインタイム リカバリの実行方法の詳細については、バックアップと復元 のドキュメントを参照してください。

​

インフラストラクチャと自動化

​

Managed Postgres で Terraform は利用できますか？

現在、Managed Postgres では Terraform はサポートされていません。インスタンスの作成と管理には、ClickHouse Cloud console の使用をお勧めします。

​

拡張機能と設定

​

サポートされている拡張機能を教えてください。

Managed Postgres には、PostGIS、pgvector、pg_cron をはじめとする一般的なものを含め、100 種類以上の PostgreSQL 拡張機能が用意されています。利用可能な拡張機能の一覧とインストール手順については、拡張機能 のドキュメントを参照してください。

​

PostgreSQL の設定パラメータはカスタマイズできますか？

はい。コンソールの Settings タブで、PostgreSQL と PgBouncer の設定パラメータを変更できます。使用可能なパラメータと変更手順の詳細については、Settings のドキュメントを参照してください。

現在利用できないパラメータが必要な場合は、support に問い合わせてリクエストしてください。

​

接続プーリング

​

なぜ PgBouncer 経由で prepared statement does not exist エラーが表示されるのですか？

Managed Postgres は、PgBouncer を transaction pooling モードで実行します。このモードでは、バックエンドの Postgres 接続は 1 つのトランザクションの間だけクライアントに割り当てられ、その後プールに戻されます。つまり、同じクライアントからの次のトランザクションは別のバックエンドに割り当てられる可能性があります。

そのため、PREPARE (または拡張クエリの Parse) を実行した特定のバックエンドにひも付いている サーバー側のプリペアドステートメント は機能しません。対応する Execute が別のバックエンドに送られると、次のようなエラーが発生します。

ERROR:  prepared statement "..." does not exist
ERROR:  unnamed prepared statement does not exist

同じ根本原因に起因することが多い症状:

• 特にバックフィル時や高並行な書き込み時に、prepared statement does not exist エラーが断続的に発生する
• insert が「何も起きずに失敗した」ように見える — ステートメントでエラーが発生し、ドライバーが再試行した結果、Batch が部分的にしか適用されなかったり、破棄されたりすることがある
• 戻り値の型が誤っている (たとえば、BIGINT カラムが float64 のビットパターンとしてデコードされる) — これは、クライアント側でキャッシュされたプランが、対応する Parse が一度も送信されていないバックエンドに対して、古い型/フォーマットコードを再利用したときに発生する

対処法: ドライバーでサーバー側のプリペアドステートメントを無効にしてください。 設定項目は、使用しているクライアントライブラリによって異なります。

ドライバー	設定
pgx (Go)	statement_cache_capacity=0 and default_query_exec_mode=exec (or simple_protocol)
psycopg3 (Python)	prepare_threshold=None
asyncpg (Python)	statement_cache_size=0
JDBC (Java)	prepareThreshold=0
node-postgres / pg (Node.js)	query() に name を渡さない (名前付きクエリはサーバー側でプリペアド化される)

ワークロードがプリペアドステートメントに依存している場合は、PgBouncer pooler を経由せず、PostgreSQL に直接 (ポート 5432) 接続してください。直接接続では、プリペアドステートメントを通常どおり利用できます。プールされたエンドポイントと直接エンドポイントのどちらを選ぶべきかについて詳しくは、Connection を参照してください。

​

PgBouncer の “max_client_conn” 設定は何を意味し、Postgres の max_connections とどう関係しますか？

これらが制御する対象は異なります。

• Postgres max_connections は、PostgreSQL 自体への バックエンド 接続数の上限です。こちらはコストの高い数値で、各バックエンドがメモリとプロセススロットを消費します。
• PgBouncer max_client_conn は、同時にプーラーへ開ける クライアント 接続数の上限です。PgBouncer は、多数のクライアント接続を、はるかに少ない数のバックエンド接続に多重化します。

一般的な Managed Postgres インスタンスでは、PgBouncer が Postgres バックエンド数のおよそ 10 倍のクライアント接続 を受け付けるように設定されています (例: クライアント 5000 / バックエンド 500) 。プーラーで接続エラーが発生している場合、表面的なクライアント接続上限に達しているというよりも、プールごとのバックエンド上限 (default_pool_size) に達している可能性のほうがはるかに高いです。

​

データベースの機能

​

複数のデータベースとスキーマを作成できますか？

はい。Managed Postgres は PostgreSQL の完全なネイティブ機能を備えており、1つのインスタンス内で複数のデータベースとスキーマをサポートしています。標準的な PostgreSQL コマンドを使用して、データベースとスキーマを作成・管理できます。

​

ロールベースのアクセス制御 (RBAC) はサポートされていますか？

Managed Postgres インスタンスでは superuser 権限をフルに利用できるため、標準の PostgreSQL コマンドを使用してロールを作成し、権限を管理できます。

Console との統合を含む強化された RBAC 機能は、今年中に提供される予定です。

​

アップグレード

​

PostgreSQL のバージョンアップグレードはどのように行われますか？

マイナーアップグレードとメジャーバージョンアップグレードはいずれもフェイルオーバーによって実施され、通常、ダウンタイムは数秒程度です。アップグレードを適用するタイミングを制御するために、メンテナンスウィンドウを設定できます。詳細については、Upgrades のドキュメントを参照してください。

​

移行

​

Managed Postgres への移行にはどのようなツールを利用できますか？

Managed Postgres では、いくつかの移行方法をサポートしています。

• pg_dump と pg_restore: 小規模なデータベースや一回限りの移行に適しています。pg_dump と pg_restore ガイドを参照してください。
• 論理レプリケーション: ダウンタイムを最小限に抑える必要がある大規模なデータベースに適しています。Logical replication ガイドを参照してください。
• PeerDB: 他の Postgres ソースからの CDC (変更データキャプチャ) ベースのレプリケーションに適しています。PeerDB migration ガイドを参照してください。

完全マネージド型の移行機能は近日提供予定です。