接続プーリング ============== CloudNativePGは、 ``Pooler`` CRDを介して、PostgreSQLで最も人気のあるオープンソース接続プーラーの1つである `PgBouncer `_ との接続プーリングのネイティブサポートを提供します。 一言で言えば、CloudNativePGの\ ``Pooler`` は、アプリケーションとPostgreSQLサービスたとえば\ ``rw`` サービスの間にあるPgBouncerポッドの展開であり、別個のスケーラブル、構成可能、高可用性 **データベースアクセスレイヤー** を作成します。 アーキテクチャ -------------- 次の図は、スイスアーミーナイフの追加の刃のように、PgBouncerに基づくデータベースアクセスレイヤーの導入がCloudNativePGのアーキテクチャをどのように変更するかを強調しています。 PostgreSQLプライマリサービスに直接接続する代わりに、アプリケーションはPgBouncerの同等のサービスに接続できるようになり、既存の接続を再利用してPostgreSQL側でのパフォーマンスの向上とリソース管理の向上が可能になります。 .. figure:: /images/pgbouncer-architecture-rw.png :width: 70% :alt: Applications writing to the single primary via PgBouncer Applications writing to the single primary via PgBouncer クイックスタート ---------------- CloudNativePGがPgBouncerプーラーを実装する方法を説明する最も簡単な方法は、例を使用して説明します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Pooler metadata: name: pooler-example-rw spec: cluster: name: cluster-example instances: 3 type: rw pgbouncer: poolMode: session parameters: max_client_conn: "1000" default_pool_size: "10" .. Important:: プーラー名は、同じ名前空間内のクラスター名と決して一致しないはずです。 これにより、 ``pooler-example-rw`` と呼ばれる新しい\ ``Pooler`` リソースが作成されます。名前は任意です。これは、 ``cluster-example`` と呼ばれるPostgres ``Cluster`` リソースに厳密に関連付けられ、読み取り/書き込みサービス ``rw`` 、したがって ``cluster-example-rw`` によって識別されるプライマリをポイントします。 ``Pooler`` は、Postgresクラスターの同じ名前空間に存在する必要があります。これは、 `session `_ で構成された `latest stable image of PgBouncer `_ を実行する3つのポッドのKubernetesデプロイメントで構成されています そして、それぞれ最大1000の接続を受け入れます-PostgreSQLに対する10のユーザー/データベースペアのデフォルトのプールサイズを使用します。 .. Important:: `Pooler` は、PgBouncerで`*` フォールバックデータベースを設定するだけです。つまり、クライアントから渡された接続文字列のすべてのパラメーターがPostgreSQLサーバーに中継されることを意味します ["Section [databases]" in PgBouncer's documentation](https://www.pgbouncer.org/config.html#section-databases)を参照してください。 さらに、CloudNativePGは、PgBouncerで使用される構成ファイルを含むプーラーと同じ名前のシークレットを自動的に作成します。 .. Seealso:: 詳細はこちら :ref:`PgBouncerSpec {postgresql-cnpg-io-v1-PgBouncerSpec} ` APIリファレンスで。 リソースのライフサイクルのプール化 ---------------------------------- ``Pooler`` リソースは\ ``Cluster`` 管理リソースではありません。プーラーは、必要に応じて手動で作成する必要があります。さらに、PostgreSQLクラスターごとに複数のプーラーを展開できます。 ``Cluster`` および\ ``Pooler`` リソースのライフサイクルは現在独立していることに注意することが重要です。\ ``Cluster`` の削除は\ ``Pooler`` の自動削除を意味せず、その逆も可能です。 .. Important:: `Pooler` がどのように動作するかがわかったので、考えられるアーキテクチャの点で完全な自由があります。プーラーのないクラスター、単一のプーラーを持つクラスター、または複数のプーラーつまりアプリケーションごとに1つを持つクラスターを持つことができます。 セキュリティ ------------ PgBouncerプーラーは、プールのクライアントアプリケーション側とサーバーPostgreSQL側の両方で、 **TLS接続** を介した転送中の暗号化のサポートとCloudNativePGサポートと透過的に統合されています。 具体的には、PgBouncerは、PostgreSQLサーバーの証明書を自動的に再利用します。さらに、TLSクライアント証明書認証を使用してPostgreSQLサーバーに接続し、クライアントのパスワード認証のために\ ``auth_query`` を実行します以下の :ref:`認証を使用する <認証を使用する>` を参照してください。 コンテナは\ ``pgbouncer`` システムユーザーとして実行され、 ``pgbouncer`` データベースへのアクセスは、\ ``peer`` 認証を介したローカル接続を介してのみ許可されます。 証明書 ^^^^^^ デフォルトでは、PgBouncerプーラーは、クラスター自分自身が使用するのと同じ証明書を使用しますが、ユーザーがこれらの証明書を提供すると、プーラーは次の形式でシークレットを受け入れます。 1.ベーシック認証 2.TLS 3.不透明 不透明の場合、使用する必要がある特定のキーを検索します。これらのキーは次のとおりです。 - tls.crt - tls.key したがって、このシークレットをTLSシークレットとして扱い、そこから開始できます。 認証 ---- **パスワードベースの認証** は、CloudNativePGのPgBouncerのクライアントでサポートされている唯一の方法です。 内部的に、実装はPgBouncerの\ ``auth_user`` および\ ``auth_query`` オプションに依存しています。具体的には、演算子 - PostgreSQLサーバーに\ ``cnpg_pooler_pgbouncer`` と呼ばれる標準ユーザーを作成します - ``postgres`` データベースにルックアップファンクションを作成し、 ``cnpg_pooler_pgbouncer`` ユーザーに実行特権を付与しますPoLA - このユーザーのTLS証明書を発行します - ``cnpg_pooler_pgbouncer`` を\ ``auth_user`` として設定します - TLS証明書を使用してPostgreSQLサーバーに対して\ ``cnpg_pooler_pgbouncer`` を認証するようにPgBouncerを構成します - クラスターに関連付けられたプーラーがないことを検出した場合、上記のすべてを削除します .. Important:: 独自のシークレットを指定した場合、オペレーターはプーラーを自動的に統合しません。 独自のシークレットを指定した場合、プーラーを手動で統合するには、クラスター内から次のクエリを実行する必要があります。 最初に、ロールを作成する必要があります。 .. code:: sql CREATE ROLE cnpg_pooler_pgbouncer WITH LOGIN; 次に、アプリケーションデータベースごとに、\ ``cnpg_pooler_pgbouncer`` に接続する権限を付与します。 .. code:: sql GRANT CONNECT ON DATABASE { database name here } TO cnpg_pooler_pgbouncer; 最後に、各アプリケーションデータベースで接続し、各アプリケーションデータベース内に認証ファンクションを作成します。 .. code:: sql CREATE OR REPLACE FUNCTION user_search(uname TEXT) RETURNS TABLE (usename name, passwd text) LANGUAGE sql SECURITY DEFINER AS SELECT usename, passwd FROM pg_shadow WHERE usename=$1;; REVOKE ALL ON FUNCTION user_search(text) FROM public; GRANT EXECUTE ON FUNCTION user_search(text) TO cnpg_pooler_pgbouncer; PodTemplates ------------ ``Pooler`` リソースの\ ``template`` セクションのポッドテンプレート仕様を利用できます。詳細については、APIリファレンスの\ ```PoolerSpec`` section `__\ を参照してください。 テンプレートを介して、ポッドとノードのアフィニティおよびアンチアフィニティルールの微制御を含む、好きなようにポッドを構成できます。デフォルトでは、コンテナは\ ``ghcr.io/cloudnative-pg/pgbouncer`` のイメージを使用します。 次に、PodAntiAffinityを指定するプーラーの例を示します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Pooler metadata: name: pooler-example-rw spec: cluster: name: cluster-example instances: 3 type: rw template: metadata: labels: app: pooler spec: containers: [] affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - pooler topologyKey: "kubernetes.io/hostname" .. Note:: `.spec.template.spec.containers` は、`PodSpec` の必須フィールドであるため、変更しない場合は明示的に`[]` に設定する必要があります。 `.spec.template.spec.containers` が設定されていない場合、マニフェストを適用しようとすると、kubernetes APIサーバーは次のエラーを結果ます。`error validating "pooler.yaml": error validating data: ValidationError(Pooler.spec.template.spec): missing required field "containers"` ここでは、リソースを設定し、使用されるイメージを変更する例を示します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Pooler metadata: name: pooler-example-rw spec: cluster: name: cluster-example instances: 3 type: rw template: metadata: labels: app: pooler spec: containers: - name: pgbouncer image: my-pgbouncer:latest resources: requests: cpu: "0.1" memory: 100Mi limits: cpu: "0.5" memory: 500Mi 高可用性HA ---------- Kubernetesの展開のおかげで、単一のインスタンスまたは複数のポッドで実行するようにプーラーを構成できます。公開されたサービスは、クライアントがPgBouncerを実行している利用可能なポッドにランダムに分散されるようにします。これにより、基になるサーバー\ ``rw`` サービスを使用する場合またはサーバー複数のレプリカで\ ``ro`` サービスを使用する場合への接続が自動的に管理および再利用されます。 。 .. Warning:: インフラストラクチャが複数のアベイラビリティーゾーンにまたがり、それらの間のレイテンシーが高い場合、ネットワークホップに注意してください。例、ゾーン2で実行され、ゾーン3で実行されているPgBouncerに接続し、ゾーン1のPostgreSQLプライマリをポイントしている場合を考えます。 PgBouncer構成オプション ----------------------- オペレーターは `configuration options for PgBouncer `_ の大部分を管理し、それらのサブセットのみを変更できます。 .. Warning:: オペレーターは検証しないため、各オプションの値を正しく設定する責任があります。 以下に、カスタマイズが可能なPgBouncerオプションのリストを示します。各ファイルには、その特定のパラメーターのPgBouncerドキュメントへのリンクが含まれています。ここで別途記載しない限り、デフォルト値はPgBouncerによって直接設定された値です。 - `application_name_add_host `_ - `autodb_idle_timeout `_ - `client_idle_timeout `_ - `client_login_timeout `_ - `default_pool_size `_ - `disable_pqexec `_ - `idle_transaction_timeout `_ - `ignore_startup_parameters `_ ``extra_float_digits,options`` に追加します - CNPが必要 - `log_connections `_ - `log_disconnections `_ - `log_pooler_errors `_ - `log_stats `_ デフォルトで無効になっています\ ``0`` 、以下の :ref:`MonitoringConfiguration {postgresql-cnpg-io-v1-MonitoringConfiguration} ` セクションで説明するように、Prometheusエクスポートによって統計が既に収集されている場合 - `max_client_conn `_ - `max_db_connections `_ - `max_user_connections `_ - `min_pool_size `_ - `query_timeout `_ - `query_wait_timeout `_ - `reserve_pool_size `_ - `reserve_pool_timeout `_ - `server_check_delay `_ - `server_check_query `_ - `server_connect_timeout `_ - `server_fast_close `_ - `server_idle_timeout `_ - `server_lifetime `_ - `server_login_retry `_ - `server_reset_query `_ - `server_reset_query_always `_ - `server_round_robin `_ - `stats_period `_ - `tcp_keepalive `_ - `tcp_keepcnt `_ - `tcp_keepidle `_ - `tcp_keepintvl `_ - `tcp_user_timeout `_ - `verbose `_ PgBouncer構成のカスタマイズは、\ ``.spec.pgbouncer.parameters`` マップに宣言的に書き込まれます。 オペレーターはプーラー仕様の変更に反応し、すべてのPgBouncerインスタンスは、サービスを中断せずに更新された構成をリロードします。 .. Warning:: すべてのPgBouncerポッドは同じ構成で、仕様のパラメーターに合わせて調整されます。これらのパラメーターを間違えると、**プーラー全体**の操作性が混乱する可能性があります。演算子は**オプションの値を検証しません**。 モニタリング ------------ ``Pooler`` のPgBouncer実装には、次を実行することにより、\ ``cnpg_pgbouncer_`` プレフィックスを持ついくつかのメトリックを自動的に利用できるデフォルトのPrometheusエクスポータが付属しています。 - ``SHOW LISTS`` 接頭辞 ``cnpg_pgbouncer_lists`` - ``SHOW POOLS`` 接頭辞 ``cnpg_pgbouncer_pools`` - ``SHOW STATS`` 接頭辞 ``cnpg_pgbouncer_stats`` CloudNativePGインスタンスと同様に、エクスポーターはPgBouncerを実行している各ポッドのポート\ ``9127`` で実行され、Goランタイム接頭辞\ ``go_*`` に関連するメトリックも提供します。 .. Note:: :ref:`エクスポートされたメトリックを検査する方法 <エクスポートされたメトリックを検査する方法>` で提供されている指示に従い、正しいIPと`9127` ポートを使用していることを確認して、PgBouncerを実行しているポッドでエクスポートされたメトリックを検査できます。 ``cnpg_pgbouncer`` メトリックの出力の例 .. code:: text # HELP cnpg_pgbouncer_collection_duration_seconds Collection time duration in seconds # TYPE cnpg_pgbouncer_collection_duration_seconds gauge cnpg_pgbouncer_collection_duration_seconds{collector="Collect.up"} 0.002443168 # HELP cnpg_pgbouncer_collections_total Total number of times PostgreSQL was accessed for metrics. # TYPE cnpg_pgbouncer_collections_total counter cnpg_pgbouncer_collections_total 1 # HELP cnpg_pgbouncer_last_collection_error 1 if the last collection ended with error, 0 otherwise. # TYPE cnpg_pgbouncer_last_collection_error gauge cnpg_pgbouncer_last_collection_error 0 # HELP cnpg_pgbouncer_lists_databases Count of databases. # TYPE cnpg_pgbouncer_lists_databases gauge cnpg_pgbouncer_lists_databases 1 # HELP cnpg_pgbouncer_lists_dns_names Count of DNS names in the cache. # TYPE cnpg_pgbouncer_lists_dns_names gauge cnpg_pgbouncer_lists_dns_names 0 # HELP cnpg_pgbouncer_lists_dns_pending Not used. # TYPE cnpg_pgbouncer_lists_dns_pending gauge cnpg_pgbouncer_lists_dns_pending 0 # HELP cnpg_pgbouncer_lists_dns_queries Count of in-flight DNS queries. # TYPE cnpg_pgbouncer_lists_dns_queries gauge cnpg_pgbouncer_lists_dns_queries 0 # HELP cnpg_pgbouncer_lists_dns_zones Count of DNS zones in the cache. # TYPE cnpg_pgbouncer_lists_dns_zones gauge cnpg_pgbouncer_lists_dns_zones 0 # HELP cnpg_pgbouncer_lists_free_clients Count of free clients. # TYPE cnpg_pgbouncer_lists_free_clients gauge cnpg_pgbouncer_lists_free_clients 49 # HELP cnpg_pgbouncer_lists_free_servers Count of free servers. # TYPE cnpg_pgbouncer_lists_free_servers gauge cnpg_pgbouncer_lists_free_servers 0 # HELP cnpg_pgbouncer_lists_login_clients Count of clients in login state. # TYPE cnpg_pgbouncer_lists_login_clients gauge cnpg_pgbouncer_lists_login_clients 0 # HELP cnpg_pgbouncer_lists_pools Count of pools. # TYPE cnpg_pgbouncer_lists_pools gauge cnpg_pgbouncer_lists_pools 1 # HELP cnpg_pgbouncer_lists_used_clients Count of used clients. # TYPE cnpg_pgbouncer_lists_used_clients gauge cnpg_pgbouncer_lists_used_clients 1 # HELP cnpg_pgbouncer_lists_used_servers Count of used servers. # TYPE cnpg_pgbouncer_lists_used_servers gauge cnpg_pgbouncer_lists_used_servers 0 # HELP cnpg_pgbouncer_lists_users Count of users. # TYPE cnpg_pgbouncer_lists_users gauge cnpg_pgbouncer_lists_users 2 # HELP cnpg_pgbouncer_pools_cl_active Client connections that are linked to server connection and can process queries. # TYPE cnpg_pgbouncer_pools_cl_active gauge cnpg_pgbouncer_pools_cl_active{database="pgbouncer",user="pgbouncer"} 1 # HELP cnpg_pgbouncer_pools_cl_cancel_req Client connections that have not forwarded query cancellations to the server yet. # TYPE cnpg_pgbouncer_pools_cl_cancel_req gauge cnpg_pgbouncer_pools_cl_cancel_req{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_cl_waiting Client connections that have sent queries but have not yet got a server connection. # TYPE cnpg_pgbouncer_pools_cl_waiting gauge cnpg_pgbouncer_pools_cl_waiting{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_maxwait How long the first (oldest) client in the queue has waited, in seconds. If this starts increasing, then the current pool of servers does not handle requests quickly enough. The reason may be either an overloaded server or just too small of a pool_size setting. # TYPE cnpg_pgbouncer_pools_maxwait gauge cnpg_pgbouncer_pools_maxwait{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_maxwait_us Microsecond part of the maximum waiting time. # TYPE cnpg_pgbouncer_pools_maxwait_us gauge cnpg_pgbouncer_pools_maxwait_us{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_pool_mode The pooling mode in use. 1 for session, 2 for transaction, 3 for statement, -1 if unknown # TYPE cnpg_pgbouncer_pools_pool_mode gauge cnpg_pgbouncer_pools_pool_mode{database="pgbouncer",user="pgbouncer"} 3 # HELP cnpg_pgbouncer_pools_sv_active Server connections that are linked to a client. # TYPE cnpg_pgbouncer_pools_sv_active gauge cnpg_pgbouncer_pools_sv_active{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_sv_idle Server connections that are unused and immediately usable for client queries. # TYPE cnpg_pgbouncer_pools_sv_idle gauge cnpg_pgbouncer_pools_sv_idle{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_sv_login Server connections currently in the process of logging in. # TYPE cnpg_pgbouncer_pools_sv_login gauge cnpg_pgbouncer_pools_sv_login{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_sv_tested Server connections that are currently running either server_reset_query or server_check_query. # TYPE cnpg_pgbouncer_pools_sv_tested gauge cnpg_pgbouncer_pools_sv_tested{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_pools_sv_used Server connections that have been idle for more than server_check_delay, so they need server_check_query to run on them before they can be used again. # TYPE cnpg_pgbouncer_pools_sv_used gauge cnpg_pgbouncer_pools_sv_used{database="pgbouncer",user="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_avg_query_count Average queries per second in last stat period. # TYPE cnpg_pgbouncer_stats_avg_query_count gauge cnpg_pgbouncer_stats_avg_query_count{database="pgbouncer"} 1 # HELP cnpg_pgbouncer_stats_avg_query_time Average query duration, in microseconds. # TYPE cnpg_pgbouncer_stats_avg_query_time gauge cnpg_pgbouncer_stats_avg_query_time{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_avg_recv Average received (from clients) bytes per second. # TYPE cnpg_pgbouncer_stats_avg_recv gauge cnpg_pgbouncer_stats_avg_recv{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_avg_sent Average sent (to clients) bytes per second. # TYPE cnpg_pgbouncer_stats_avg_sent gauge cnpg_pgbouncer_stats_avg_sent{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_avg_wait_time Time spent by clients waiting for a server, in microseconds (average per second). # TYPE cnpg_pgbouncer_stats_avg_wait_time gauge cnpg_pgbouncer_stats_avg_wait_time{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_avg_xact_count Average transactions per second in last stat period. # TYPE cnpg_pgbouncer_stats_avg_xact_count gauge cnpg_pgbouncer_stats_avg_xact_count{database="pgbouncer"} 1 # HELP cnpg_pgbouncer_stats_avg_xact_time Average transaction duration, in microseconds. # TYPE cnpg_pgbouncer_stats_avg_xact_time gauge cnpg_pgbouncer_stats_avg_xact_time{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_total_query_count Total number of SQL queries pooled by pgbouncer. # TYPE cnpg_pgbouncer_stats_total_query_count gauge cnpg_pgbouncer_stats_total_query_count{database="pgbouncer"} 3 # HELP cnpg_pgbouncer_stats_total_query_time Total number of microseconds spent by pgbouncer when actively connected to PostgreSQL, executing queries. # TYPE cnpg_pgbouncer_stats_total_query_time gauge cnpg_pgbouncer_stats_total_query_time{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_total_received Total volume in bytes of network traffic received by pgbouncer. # TYPE cnpg_pgbouncer_stats_total_received gauge cnpg_pgbouncer_stats_total_received{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_total_sent Total volume in bytes of network traffic sent by pgbouncer. # TYPE cnpg_pgbouncer_stats_total_sent gauge cnpg_pgbouncer_stats_total_sent{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_total_wait_time Time spent by clients waiting for a server, in microseconds. # TYPE cnpg_pgbouncer_stats_total_wait_time gauge cnpg_pgbouncer_stats_total_wait_time{database="pgbouncer"} 0 # HELP cnpg_pgbouncer_stats_total_xact_count Total number of SQL transactions pooled by pgbouncer. # TYPE cnpg_pgbouncer_stats_total_xact_count gauge cnpg_pgbouncer_stats_total_xact_count{database="pgbouncer"} 3 # HELP cnpg_pgbouncer_stats_total_xact_time Total number of microseconds spent by pgbouncer when connected to PostgreSQL in a transaction, either idle in transaction or executing queries. # TYPE cnpg_pgbouncer_stats_total_xact_time gauge cnpg_pgbouncer_stats_total_xact_time{database="pgbouncer"} 0 ``Clusters`` の場合と同様に、特定の\ ``Pooler`` は、 `Prometheus Operator's `_ リソース `PodMonitor `_ を使用してモニタできます。 ``Pooler`` リソース自分自身デフォルトfalseで\ ``.spec.monitoring.enablePodMonitor`` から\ ``true`` を設定することにより、オペレーターが\ ``Pooler`` を正しく指す\ ``PodMonitor`` を自動的に作成できます。 .. Important:: 自動的に作成される`PodMonitor` への変更は、次の調整サイクルでオペレーターによってオーバーライドされます。カスタマイズが必要な場合は、以下の説明に従って行うことができます。 特定のプーラーに\ ``PodMonitor`` を手動で展開するには、次のように定義し、必要に応じて変更するだけです。 .. code:: yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: spec: selector: matchLabels: cnpg.io/poolerName: podMetricsEndpoints: - port: metrics ロギング -------- ログは、次の例のように、JSON形式で標準出力に直接送信されます。 .. code:: json { "level": "info", "ts": SECONDS.MICROSECONDS, "msg": "record", "pipe": "stderr", "record": { "timestamp": "YYYY-MM-DD HH:MM:SS.MS UTC", "pid": "", "level": "LOG", "msg": "kernel file descriptor limit: 1048576 (hard: 1048576); max_client_conn: 100, max expected fd use: 112" } } 接続の一時停止 -------------- ``Pooler`` 仕様では、宣言的構成のみを使用して、PgBouncerの\ ``PAUSE`` および\ ``RESUME`` コマンドを利用できます。\ ``paused`` オプション、デフォルトで\ ``false`` に設定。 ``true`` に設定されている場合、オペレーターはPgBouncerの\ ``PAUSE`` コマンドを内部的に呼び出します。 1.クエリが完了するのを待った後、PostgreSQLサーバーへのアクティブな接続をすべて閉じます。 2.クライアントからの新しい接続を一時停止します ``paused`` オプションが\ ``false`` に設定されている場合、オペレーターはPgBouncerで\ ``RESUME`` コマンドを呼び出し、\ ``Pooler`` で定義されたPostgreSQLサービスへのタップを再度開きます。 .. Seealso:: 詳細については、 `PAUSE `_ を参照してください。 .. Important:: 将来のバージョンでは、スイッチオーバー操作はPgBouncerプーラーと完全に統合され、 `PAUSE` / `RESUME` 機能を利用してクライアントアプリケーションによる知覚的なダウンタイムを削減します。現時点では、 `paused` 属性を`true` に設定し、 :ref:`Backup {postgresql-cnpg-io-v1-Backup} ` を介してswitchoverコマンドを発行し、最後に`paused` 属性を`false` に復元することにより、同じ結果を得ることができます。 制限事項 -------- 単一のPostgreSQLクラスター ^^^^^^^^^^^^^^^^^^^^^^^^^^ プーラーの現在の実装は、特定のCloudNativePGクラスター正確にはサービスの一部として動作するように設計されています。現時点では、複数のクラスターにまたがるプーラーを作成することはできません。 制御された構成可能性 ^^^^^^^^^^^^^^^^^^^^ CloudNativePGは、PgBouncerレイヤーがPostgreSQLと通信するために使用されるいくつかの構成オプションを透過的に管理します。このようなオプションは外部から構成できず、TLS証明書、認証設定、\ ``databases`` セクション、および\ ``users`` セクションが含まれます。また、単一のPostgreSQLクラスターの特定のユースケースを考慮して、採用される基準は、ユーザーが構成できるオプションを明示的にリストすることです。 .. Note:: 採用されたソリューションはほとんどのユースケースに対応しているが、PgBouncerの別のオペレーターを将来的に実装して、より高度なカスタマイズされたシナリオでガンマを完了する余地を残していると信じる理由があります。