CloudNativePG プラグイン¶
CloudNativePG は、kubectl が Kubernetes
でクラスターを管理するためのプラグインを提供します。
インストール¶
cnpg プラグインは、さまざまな方法でインストールできます。
注釈
エアギャップ システムの場合、以前にダウンロードしたファイルを使用してパッケージ マネージャーを介してインストールするのが適切なオプションです。
インストールスクリプト経由¶
curl -sSfL \
https://github.com/cloudnative-pg/cloudnative-pg/raw/main/hack/install-cnpg-plugin.sh | \
sudo sh -s -- -b /usr/local/bin
Debian または RedHat パッケージの使用¶
releases section of the GitHub repository では、関心のある任意のリリースに移動でき (CloudNativePG
オペレーターと同じか新しいリリースを選択)、その中に Assets セクションがあります。そのセクションには、さまざまなシステム用のビルド済みパッケージがあります。その結果、標準的な方法と指示に従ってシステムにインストールできます。
Debian パッケージ¶
たとえば、Intel ベースの 64 ビット サーバー用に、プラグインの 1.18.1
リリースをインストールしてみましょう。まず、正しい .deb
ファイルをダウンロードします。
$ wget https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.18.1/kubectl-cnpg_1.18.1_linux_x86_64.deb
次に、dpkg を使用してローカル ファイルからインストールします。
$ dpkg -i kubectl-cnpg_1.18.1_linux_x86_64.deb
(Reading database ... 16102 files and directories currently installed.)
Preparing to unpack kubectl-cnpg_1.18.1_linux_x86_64.deb ...
Unpacking cnpg (1.18.1) over (1.18.1) ...
Setting up cnpg (1.18.1) ...
RPM パッケージ¶
.deb パッケージの例のように、Intel 64 ビット マシン用の 1.18.1
リリースをインストールしましょう。ファイル名を提供する --output
フラグに注意してください。
curl -L https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.18.1/kubectl-cnpg_1.18.1_linux_x86_64.rpm \
--output kube-plugin.rpm
次に、yum をインストールすると、使用する準備が整います。
$ yum --disablerepo=* localinstall kube-plugin.rpm
yum --disablerepo=* localinstall kube-plugin.rpm
Failed to set locale, defaulting to C.UTF-8
Dependencies resolved.
====================================================================================================
Package Architecture Version Repository Size
====================================================================================================
Installing:
cnpg x86_64 1.18.1-1 @commandline 14 M
Transaction Summary
====================================================================================================
Install 1 Package
Total size: 14 M
Installed size: 43 M
Is this ok [y/N]: y
クルーの使用¶
クルーの使用 が既にインストールされている場合は、次を実行するだけです。
kubectl krew install cnpg
サポートされているアーキテクチャ¶
CloudNativePG プラグインは現在、次のオペレーティング システムとアーキテクチャ用に構築されています。
Linux * amd64 * arm 5/6/7 * arm64 * s390x * ppc64le
macOS * amd64 * arm64
Windows * 386 * amd64 * アーム 5/6/7 * arm64
使用¶
プラグインをインストールして展開したら、次のように使用を開始できます。
kubectl cnpg <command> <args...>
インストール マニフェストの生成¶
cnpg プラグインを使用して、オペレーターのインストール用の YAML
マニフェストを生成できます。通常、このオプションは、レプリカの数、インストール名前空間、監視する名前空間などの一部のデフォルト構成をオーバーライドする場合に使用されます。
詳細と利用可能なオプションについては、次を実行してください。
kubectl cnpg install generate --help
主なオプションは次のとおりです。
-n: オペレーターをインストールする名前空間 (デフォルト:cnpg-system)--replicas: デプロイ内のレプリカの数--version:1.17など、インストールするオペレーターのマイナー バージョン。マイナー バージョンが指定されている場合、プラグインはそのマイナー バージョンの最新のパッチ バージョンをインストールします。バージョンが指定されていない場合、プラグインはオペレーターの最新のMAJOR.MINOR.PATCHバージョンをインストールします。--watch-namespace: 監視する名前空間を含むカンマ区切りの文字列 (デフォルトではすべての名前空間)
オペレーターをインストールする YAML マニフェストを生成する generate
コマンドの例は次のとおりです。
kubectl cnpg install generate \
-n king \
--version 1.17 \
--replicas 3 \
--watch-namespace "albert, bb, freddie" \
> operator.yaml
上記のコマンドのフラグには、次の意味があります。
-n kingCNPG オペレーターをking名前空間にインストールします--version 1.17は、マイナー バージョン 1.17 の最新のパッチ バージョンをインストールします。--replicas 3は、3 つのレプリカを持つオペレーターをインストールします--watch-namespaces "albert, bb, freddie"では、albert、bb、およびfreddie名前空間のみの変更を監視するオペレーターがいます。
スターテス¶
status
コマンドは、次のようなクラスターの現在のステータスの概要を提供します。
一般情報 : クラスターの名前、PostgreSQL のシステム ID、インスタンス数、現在のタイムライン、および WAL 内の位置
バックアップ : 回復可能ポイント、およびプライマリからの
pg_stat_archiverビューによって返される WAL アーカイブ ステータス、またはレプリカ クラスタの場合は指定されたプライマリストリーミングレプリケーション : プライマリ インスタンスの
pg_stat_replicationビューから直接取得した情報インスタンス : 各インスタンス マネージャーによって直接取得される、各 Postgres インスタンスに関する情報。スタンバイの場合、
Current LSNフィールドは、リカバリ中にリプレイされた最新のログ先行書き込みの場所に対応します (リプレイ LSN)。
重要
上記のステータス情報は、さまざまな時点でさまざまな場所で取得されているため、返される値に若干の一貫性がありません。たとえば、メイン ヘッダーの Current Write LSN の場所は、2 つの異なる時間間隔で取得されるため、インスタンス ステータスの Current LSN フィールドとは異なる場合があります。
kubectl cnpg status sandbox
Cluster in healthy state
Name: sandbox
Namespace: default
System ID: 7039966298120953877
PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:15.2
Primary instance: sandbox-2
Instances: 3
Ready instances: 3
Current Write LSN: 3AF/EAFA6168 (Timeline: 8 - WAL File: 00000008000003AF00000075)
Continuous Backup status
First Point of Recoverability: Not Available
Working WAL archiving: OK
Last Archived WAL: 00000008000003AE00000079 @ 2021-12-14T10:16:29.340047Z
Last Failed WAL: -
Certificates Status
Certificate Name Expiration Date Days Left Until Expiration
- --------------- --------------- --------------------------
cluster-example-ca 2022-05-05 15:02:42 +0000 UTC 87.23
cluster-example-replication 2022-05-05 15:02:42 +0000 UTC 87.23
cluster-example-server 2022-05-05 15:02:42 +0000 UTC 87.23
Streaming Replication status
Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority
- --- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- -------------
sandbox-1 3AF/EB0524F0 3AF/EB011760 3AF/EAFEDE50 3AF/EAFEDE50 00:00:00.004461 00:00:00.007901 00:00:00.007901 streaming quorum 1
sandbox-3 3AF/EB0524F0 3AF/EB030B00 3AF/EB030B00 3AF/EB011760 00:00:00.000977 00:00:00.004194 00:00:00.008252 streaming quorum 1
Instances status
Name Database Size Current LSN Replication role Status QoS Manager Version
- --- ------------- ----------- ---------------- ------ --- ---------------
sandbox-1 302 GB 3AF/E9FFFFE0 Standby (sync) OK Guaranteed 1.11.0
sandbox-2 302 GB 3AF/EAFA6168 Primary OK Guaranteed 1.11.0
sandbox-3 302 GB 3AF/EBAD5D18 Standby (sync) OK Guaranteed 1.11.0
--verbose または単に -v
を追加することで、ステータスのより詳細なバージョンを取得することもできます
kubectl cnpg status sandbox --verbose
Cluster in healthy state
Name: sandbox
Namespace: default
System ID: 7039966298120953877
PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:15.2
Primary instance: sandbox-2
Instances: 3
Ready instances: 3
Current Write LSN: 3B1/61DE3158 (Timeline: 8 - WAL File: 00000008000003B100000030)
PostgreSQL Configuration
archive_command = /controller/manager wal-archive --log-destination /controller/log/postgres.json %p
archive_mode = on
archive_timeout = 5min
checkpoint_completion_target = 0.9
checkpoint_timeout = 900s
cluster_name = sandbox
dynamic_shared_memory_type = sysv
full_page_writes = on
hot_standby = true
jit = on
listen_addresses = *
log_autovacuum_min_duration = 1s
log_checkpoints = on
log_destination = csvlog
log_directory = /controller/log
log_filename = postgres
log_lock_waits = on
log_min_duration_statement = 1000
log_rotation_age = 0
log_rotation_size = 0
log_statement = ddl
log_temp_files = 1024
log_truncate_on_rotation = false
logging_collector = on
maintenance_work_mem = 2GB
max_connections = 1000
max_parallel_workers = 32
max_replication_slots = 32
max_wal_size = 15GB
max_worker_processes = 32
pg_stat_statements.max = 10000
pg_stat_statements.track = all
port = 5432
shared_buffers = 16GB
shared_memory_type = sysv
shared_preload_libraries = pg_stat_statements
ssl = on
ssl_ca_file = /controller/certificates/client-ca.crt
ssl_cert_file = /controller/certificates/server.crt
ssl_key_file = /controller/certificates/server.key
synchronous_standby_names = ANY 1 ("sandbox-1","sandbox-3")
unix_socket_directories = /controller/run
wal_keep_size = 512MB
wal_level = logical
wal_log_hints = on
cnpg.config_sha256 = 3cfa683e23fe513afaee7c97b50ce0628e0cc634bca8b096517538a9a4428efc
PostgreSQL HBA Rules
# Grant local access
local all all peer map=local
# Require client certificate authentication for the streaming_replica user
hostssl postgres streaming_replica all cert
hostssl replication streaming_replica all cert
hostssl all cnpg_pooler_pgbouncer all cert
# Otherwise use the default authentication method
host all all all scram-sha-256
Continuous Backup status
First Point of Recoverability: Not Available
Working WAL archiving: OK
Last Archived WAL: 00000008000003B00000001D @ 2021-12-14T10:20:42.272815Z
Last Failed WAL: -
Streaming Replication status
Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority
- --- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- -------------
sandbox-1 3B1/61E26448 3B1/61DF82F0 3B1/61DF82F0 3B1/61DF82F0 00:00:00.000333 00:00:00.000333 00:00:00.005484 streaming quorum 1
sandbox-3 3B1/61E26448 3B1/61E26448 3B1/61DF82F0 3B1/61DF82F0 00:00:00.000756 00:00:00.000756 00:00:00.000756 streaming quorum 1
Instances status
Name Database Size Current LSN Replication role Status QoS Manager Version
- --- ------------- ----------- ---------------- ------ --- ---------------
sandbox-1 3B1/610204B8 Standby (sync) OK Guaranteed 1.11.0
sandbox-2 3B1/61DE3158 Primary OK Guaranteed 1.11.0
sandbox-3 3B1/62618470 Standby (sync) OK Guaranteed 1.11.0
このコマンドは、yaml および json
形式の出力もサポートしています。
促進¶
このコマンドの意味は、クラスター内のポッドをプライマリーに promote
することです。そのため、メンテナンス作業を開始したり、クラスターで切り替え状況をテストしたりできます。
kubectl cnpg promote cluster-example cluster-example-2
または、インスタンス ノード番号を使用して昇格することもできます
kubectl cnpg promote cluster-example 2
証明書¶
CloudNativePG オペレーターを使用して作成されたクラスターは、CA と連携して TLS 認証証明書に署名します。
証明書を取得するには、資格情報を格納するためのシークレットの名前、クラスター名、およびこの証明書のユーザーを指定する必要があります。
kubectl cnpg certificate cluster-cert --cnpg-cluster cluster-example --cnpg-user appuser
secrete が作成されたら、kubectl を使用して取得できます。
kubectl get secret cluster-cert
そして、次のコマンドを使用してプレーンテキストで同じ内容を取得します。
kubectl get secret cluster-cert -o json | jq -r .data | map(@base64d) | .[]
再起動¶
kubectl cnpg restart コマンドは、次の 2 つのケースで使用できます。
特定のクラスターのロールアウトの再起動を調整するようにオペレーターに要求する。これは、カスタム監視クエリを含む ConfigMap などのクラスター依存オブジェクトに構成変更を適用するのに役立ちます。
インスタンスがクラスターのプライマリの場合はインプレースで、レプリカの場合はポッドを削除して再作成する、単一インスタンスの再起動を要求します。
# this command will restart a whole cluster in a rollout fashion
kubectl cnpg restart [clusterName]
# this command will restart a single instance, according to the policy above
kubectl cnpg restart [clusterName] [pod]
インプレース再起動が要求されたが、スイッチオーバーなしでは変更を適用できない場合、インプレース再起動よりもスイッチオーバーが優先されます。これの一般的なケースは、PostgreSQL イメージのマイナー アップグレードです。
注釈
インスタンスによって ConfigMap とシークレットを 自動的に リロードする場合は、キー cnpg.io/reload のラベルを追加できます。
リロード¶
kubectl cnpg reload
コマンドは、特定のクラスターの調整ループをトリガーするようにオペレーターに要求します。これは、カスタム監視クエリを含む
ConfigMap
などのクラスター依存オブジェクトに構成変更を適用するのに役立ちます。
次のコマンドは、特定のクラスターのすべての構成を再読み込みします。
kubectl cnpg reload [cluster_name]
メンテナンス¶
kubectl cnpg maintenance コマンドは、名前空間全体で 1
つ以上のクラスターを変更し、メンテナンス
ウィンドウの値を設定するのに役立ちます。次のフィールドが変更されます。
.spec.nodeMaintenanceWindow.inProgress
.spec.nodeMaintenanceWindow.reusePVC
引数 set および unset
として受け入れます。これを使用して、set の場合は inProgress を
true に設定し、unset の場合は false に設定します。
デフォルトでは、--reusePVC フラグが渡されない限り、reusePVC
は常に false に設定されます。
プラグインは、変更するクラスターのリストとその新しい値の確認を求めます。これが受け入れられると、このアクションはリスト内のすべてのクラスターに適用されます。
Kubernetes クラスター内のすべての PostgreSQL をメンテナンスに設定する場合は、次のコマンドを記述するだけです。
kubectl cnpg maintenance set --all-namespaces
そして、更新するすべてのクラスターのリストが表示されます
The following are the new values for the clusters
Namespace Cluster Name Maintenance reusePVC
- -------- ------------ ----------- --------
default cluster-example true false
default pg-backup true false
test cluster-example true false
Do you want to proceed? [y/n]: y
報告¶
kubectl cnpg report コマンドは、さまざまな情報を ZIP
ファイルにまとめます。本番環境でクラスターの問題をデバッグするために必要なコンテキストを提供することを目的としています。
operator と cluster の 2 つのサブコマンドがあります。
レポート オペレータ¶
operator
サブコマンドは、オペレーターのデプロイ、構成、およびイベントに関する情報を提供するようオペレーターに要求します。
重要
Secrets と ConfigMaps のすべての機密情報は編集済みです。データ マップには キー が表示されますが、値は空になります。フラグ -S / --stopRedaction は編集を無効にし、値を表示します。自己責任でのみ使用してください。これにより、個人データが共有されます。
注釈
デフォルトでは、オペレーター ログは収集されませんが、--logs フラグを使用してオペレーター ログの収集を有効にすることができます
デプロイメント情報 : operator Deployment および operator Pod
構成 : オペレーター名前空間の Secret と ConfigMap
events : オペレーター名前空間のイベント
webhook構成 : Webhook 構成の変更と検証
webhookサービス : Webhook サービス
logs : JSON 行形式のオペレーター Pod (オプション、デフォルトではオフ) のログ
このコマンドは、YAML 形式のさまざまなマニフェストを含む ZIP
ファイルを生成します (既定では、-o フラグを使用して JSON
に設定できます)。 -f
フラグを使用して、結果ファイルに明示的に名前を付けます。 -f
フラグが使用されていない場合、デフォルトのタイムスタンプ付きファイル名が
zip ファイル用に作成されます。
注釈
レポート プラグインは kubectl 規則に従い、名前空間によって制約されたオブジェクトを探します。 CNPG Operator は通常、クラスターと同じ名前空間にはインストールされません。例えば。デフォルトのインストール名前空間は cnpg-system です
kubectl cnpg report operator -n <namespace>
結果は
Successfully written report to "report_operator_<TIMESTAMP>.zip" (format: "yaml")
-f フラグが設定されている場合:
kubectl cnpg report operator -n <namespace> -f reportRedacted.zip
ファイルを解凍すると、タイムスタンプ付きの最上位フォルダーが作成され、ディレクトリが整理されます。
unzip reportRedacted.zip
結果は次のとおりです。
Archive: reportRedacted.zip
creating: report_operator_<TIMESTAMP>/
creating: report_operator_<TIMESTAMP>/manifests/
inflating: report_operator_<TIMESTAMP>/manifests/deployment.yaml
inflating: report_operator_<TIMESTAMP>/manifests/operator-pod.yaml
inflating: report_operator_<TIMESTAMP>/manifests/events.yaml
inflating: report_operator_<TIMESTAMP>/manifests/validating-webhook-configuration.yaml
inflating: report_operator_<TIMESTAMP>/manifests/mutating-webhook-configuration.yaml
inflating: report_operator_<TIMESTAMP>/manifests/webhook-service.yaml
inflating: report_operator_<TIMESTAMP>/manifests/cnpg-ca-secret.yaml
inflating: report_operator_<TIMESTAMP>/manifests/cnpg-webhook-cert.yaml
機密情報が編集済みであることを確認できます。
cd report_operator_<TIMESTAMP>/manifests/
head cnpg-ca-secret.yaml
data:
ca.crt: ""
ca.key: ""
metadata:
creationTimestamp: "2022-03-22T10:42:28Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
-S (--stopRedaction )
オプションを有効にすると、シークレットが表示されます。
kubectl cnpg report operator -n <namespace> -f reportNonRedacted.zip -S
機密情報を表示しようとしていることを知らせるリマインダーが表示されます。
WARNING: secret Redaction is OFF. Use it with caution
Successfully written report to "reportNonRedacted.zip" (format: "yaml")
unzip reportNonRedacted.zip
head cnpg-ca-secret.yaml
data:
ca.crt: LS0tLS1CRUdJTiBD…
ca.key: LS0tLS1CRUdJTiBF…
metadata:
creationTimestamp: "2022-03-22T10:42:28Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
レポート クラスター¶
cluster サブコマンドは、以下を収集します。
クラスターリソース : クラスター情報、
kubectl get cluster -o yamlと同じclusterpods : クラスター名と一致するクラスター名前空間内のポッド
クラスタージョブ : クラスター名と一致するクラスター名前空間内のジョブ (存在する場合)
events : クラスター名前空間のイベント
ポッドログ : JSON 行形式のクラスター ポッド (オプション、デフォルトではオフ) のログ
ジョブログ : ジョブによって作成された Pod のログ (オプション、デフォルトではオフ)、JSON 行形式
cluster サブコマンドは、operator と同様に、-f および
-o フラグを受け入れます。 -f
フラグが使用されていない場合、デフォルトのタイムスタンプ付きレポート名が使用されます。クラスター情報には構成
Secrets / ConfigMaps が含まれていないため、-S
は無効になっていることに注意してください。
注釈
デフォルトでは、クラスター ログは収集されませんが、--logs フラグを使用してクラスター ログ収集を有効にすることができます
使用法：
kubectl cnpg report cluster <clusterName> [flags]
operator サブコマンドとは異なり、cluster
サブコマンドの場合、クラスターがデフォルトのものでない限り、クラスター名とおそらく名前空間を提供する必要があることに注意してください。
kubectl cnpg report cluster example -f report.zip -n example_namespace
その後：
unzip report.zip
Archive: report.zip
creating: report_cluster_example_<TIMESTAMP>/
creating: report_cluster_example_<TIMESTAMP>/manifests/
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-pods.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-jobs.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/events.yaml
--logs フラグを使用して、ポッドとジョブ ログを ZIP
に追加できることに注意してください。
kubectl cnpg report cluster example -n example_namespace --logs
結果は次のとおりです。
Successfully written report to "report_cluster_example_<TIMESTAMP>.zip" (format: "yaml")
unzip report_cluster_<TIMESTAMP>.zip
Archive: report_cluster_example_<TIMESTAMP>.zip
creating: report_cluster_example_<TIMESTAMP>/
creating: report_cluster_example_<TIMESTAMP>/manifests/
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-pods.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-jobs.yaml
inflating: report_cluster_example_<TIMESTAMP>/manifests/events.yaml
creating: report_cluster_example_<TIMESTAMP>/logs/
inflating: report_cluster_example_<TIMESTAMP>/logs/cluster-example-full-1.jsonl
creating: report_cluster_example_<TIMESTAMP>/job-logs/
inflating: report_cluster_example_<TIMESTAMP>/job-logs/cluster-example-full-1-initdb-qnnvw.jsonl
inflating: report_cluster_example_<TIMESTAMP>/job-logs/cluster-example-full-2-join-tvj8r.jsonl
``` ### 破棄
`kubectl cnpg destroy` コマンドは、インスタンスと関連するすべての PVC を Kubernetes クラスターから削除するのに役立ちます。
オプションの `--keep-pvc` フラグを指定すると、インスタンスによって設定されたすべての `metadata.ownerReferences` を削除しながら、PVC を保持できます。さらに、PVC の `cnpg.io/pvcStatus` ラベルは `ready` から `detached` に変更され、使用されなくなったことを示します。
`--keep-pvc` フラグを指定せずにコマンドを再度実行すると、切り離された PVC が削除されます。
使用法：
kubectl cnpg destroy [CLUSTER_NAME] [INSTANCE_ID]
次の例では、`cluster-example-2` ポッドと関連する PVC を削除します。
kubectl cnpg destroy cluster-example 2
### クラスターの休止状態
データを保持しながら CloudNativePG `Cluster` の実行を一時停止し、後でそのアクティビティを再開したい場合があります。この機能を **クラスター休止状態** と呼んでいます。
ハイバネーションは、`kubectl cnpg hibernate [on|off]` コマンドを介してのみ利用できます。
CloudNativePG クラスターを休止状態にすることは、PostgreSQL プライマリ インスタンスに属する PVC を除いて、クラスターによって生成されたすべてのリソースを破棄することを意味します。
以下を使用してクラスターを休止状態にすることができます。
kubectl cnpg hibernate on
この意志：
1. すべての PostgreSQL インスタンスをシャットダウンします
2. プライマリ インスタンスのデータを含む PVC を切り離し、最新のデータベース ステータスと最新のクラスタ構成で注釈を付けます。
3. 前述の PVC を除く、生成されたすべてのリソースを含む `Cluster` リソースを削除します。
休止状態の場合、CloudNativePG クラスターは、`PGDATA` を含むものに `pg_controldata` のコンテンツを含む最新の利用可能なステータスで注釈が付けられた PVC のグループだけで表されます。
.. Warning::
フェンシングも休止手順の一部であるため、フェンシングされたインスタンスを持つクラスターは休止状態にできません。
エラーが発生した場合、オペレーターは手順を元に戻すことができません。次のコマンドを使用して操作を強制することもできます。
kubectl cnpg hibernate on cluster-example –force
休止状態のクラスターは、次の方法で再開できます。
kubectl cnpg hibernate off
クラスターが休止状態になると、最後の構成とシャットダウン後の PostgreSQL の状態を表示できます。それは次のように行うことができます:
kubectl cnpg hibernate status
### pgbench によるデータベースのベンチマーク
Pgbench は、次のコマンドを使用して既存の PostgreSQL クラスターで実行できます。
kubectl cnpg pgbench – –time 30 –client 1 –jobs 1
詳細については、 :ref:`Benchmarking pgbench section <benchmarking.md#pgbench>` を参照してください。
### fio によるストレージのベンチマーク
次のコマンドを使用して、既存のストレージ クラスで fio を実行できます。
kubectl cnpg fio -n
詳細については、 :ref:`Benchmarking fio section <benchmarking.md#fio>` を参照してください。
### 新しい基本バックアップのリクエスト
`kubectl cnpg backup` コマンドは、新しい `Backup` リソースを作成することにより、既存の Postgres クラスターの新しい物理ベース バックアップを要求します。
次の例では、特定のクラスターのオンデマンド バックアップを要求します。
```shell
kubectl cnpg backup [cluster_name]
作成されたバックアップは、リクエスト時間に基づいて名前が付けられます。
edb_notranlate_50
デフォルトでは、新しく作成されたバックアップは、クラスターで定義されたバックアップ
ターゲット ポリシーを使用して、実行するインスタンスを選択します。
--backup-target
オプションを使用して、このポリシーをオーバーライドすることもできます。
バックアップとリカバリ を参照してください
バックアップ ターゲットの詳細については、
psql の起動¶
kubectl cnpg psql
コマンドは、実際のポッドから実行しているかのように、既存の Postgres
クラスターに接続された新しい PostgreSQL インタラクティブ フロントエンド
プロセス (psql) を開始します。これは、postgres
ユーザーを使用することを意味します。
重要
postgres ユーザーとして接続するため、本番環境では、このメソッドは許可された担当者のみが細心の注意を払って使用する必要があります。
kubectl cnpg psql cluster-example
psql (15.2 (Debian 15.2-1.pgdg110+1))
Type "help" for help.
postgres=#
デフォルトでは、コマンドはプライマリ
インスタンスに接続します。ユーザーは、--replica
オプションを使用して、レプリカに対して作業することを選択できます。
kubectl cnpg psql --replica cluster-example
psql (15.2 (Debian 15.2-1.pgdg110+1))
Type "help" for help.
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
- ------------------
t
(1 row)
postgres=# \q
このコマンドは kubectl exec
を開始します。正しく機能するには、PATH 変数で kubectl
実行可能ファイルにアクセスできる必要があります。
