### Install pgEdge Helm Chart

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Installs the pgEdge Helm chart into the Kubernetes cluster. This command uses a specified values file for configuration and waits for the deployment to complete.

```sh
helm install \
        --values examples/configs/single/values.yaml \
            --wait \
            pgedge ./
```

--------------------------------

### Connect to pgEdge Primary Instance

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Connects to the primary instance of a specified pgEdge node using the kubectl cnpg plugin. Requires the 'kubectl cnpg' plugin to be installed.

```sh
# The 'n1' node's primary instance
kubectl cnpg psql pgedge-n1 -- -U app app
```

--------------------------------

### Install CloudNativePG Operator

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Applies the CloudNativePG operator manifest to the Kubernetes cluster using kubectl. This command installs version 1.28.0 of the operator, which is a prerequisite for pgEdge.

```sh
kubectl apply --server-side -f \
    https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml
```

--------------------------------

### Install pgEdge Helm Chart

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Deploys a basic pgEdge distributed cluster with three nodes using the `helm install` command and an example values file. This command initiates the deployment process and waits for it to complete.

```shell
# Download and extract the chart from https://github.com/pgEdge/pgedge-helm/releases/

# Install with the example values file
helm install \
  --values examples/configs/single/values.yaml \
  --wait \
  pgedge ./

# Expected output:
# NAME: pgedge
# LAST DEPLOYED: Thu Oct 30 10:41:07 2025
# NAMESPACE: default
# STATUS: deployed
# REVISION: 1
# TEST SUITE: None
```

--------------------------------

### Install Cert-Manager

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Applies the cert-manager manifest to the Kubernetes cluster. Cert-manager is required for managing TLS certificates within the cluster, which is a dependency for pgEdge.

```sh
kubectl apply -f \
    https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml
```

--------------------------------

### Install pgEdge Helm Chart (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

This Helm command installs the pgEdge chart into your Kubernetes cluster. It uses a specified values file for configuration and waits for the installation to complete. Ensure you are in the extracted pgEdge Helm chart directory when running this command.

```shell
helm install \
--values examples/configs/single/values.yaml \
	--wait \
	pgedge ./
```

--------------------------------

### Create and Replicate Table Data using kubectl

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Demonstrates creating a table, inserting data, and verifying replication across pgEdge nodes using kubectl commands. Assumes pgEdge cluster is already deployed.

```shell
kubectl cnpg psql pgedge-n1 -- -U app app -c "create table example (id int primary key, data text);"
kubectl cnpg psql pgedge-n2 -- -U app app -c "insert into example (id, data) values (1, 'Hello, pgEdge!');"
kubectl cnpg psql pgedge-n1 -- -U app app -c "select * from example;"
```

--------------------------------

### Connect to pgEdge Read Replica

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Connects to a read replica instance of a specified pgEdge node using the kubectl cnpg plugin. This command is useful for querying data without impacting the primary instance.

```sh
# The first available read replica for the  'n1' node
kubectl cnpg psql pgedge-n1 --replica -- -U app app
```

--------------------------------

### Sample pgEdge Single Node Configuration

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

A sample YAML configuration for deploying a single pgEdge node within a Kubernetes cluster. This snippet shows how to define node properties, instance count, and storage size.

```yaml
pgEdge:
    appName: pgedge
    nodes:
        - name: n1
          hostname: pgedge-n1-rw
          clusterSpec:
              instances: 3
              postgresql:
              synchronous:
                  method: any
                  number: 1
                  dataDurability: required
    clusterSpec:
        storage:
        size: 1Gi
```

--------------------------------

### Install CloudNativePG and Cert-Manager Operators (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

This sequence of shell commands installs the CloudNativePG and cert-manager operators into your Kubernetes cluster. It applies the necessary YAML manifests and waits for the cert-manager deployments to become available.

```shell
kubectl apply --server-side -f \
https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml

kubectl apply -f \
https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml

kubectl wait --for=condition=Available deployment \
	-n cert-manager cert-manager cert-manager-cainjector cert-manager-webhook --timeout=120s
```

--------------------------------

### Install Barman Cloud CNPG-I Plugin (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/backups.md

Installs the Barman Cloud CNPG-I plugin using kubectl. This requires cert-manager to be pre-installed.

```shell
kubectl apply -f \
        https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/v0.6.0/manifest.yaml
```

--------------------------------

### Wait for Cert-Manager Availability

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Waits for the cert-manager, cert-manager-cainjector, and cert-manager-webhook deployments to become available in the 'cert-manager' namespace. This ensures cert-manager is fully operational before proceeding.

```sh
kubectl wait --for=condition=Available deployment \
        -n cert-manager cert-manager cert-manager-cainjector cert-manager-webhook --timeout=120s
```

--------------------------------

### Load Northwind Dataset using curl and kubectl

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Loads the Northwind sample dataset into a pgEdge database using curl to download the SQL dump and kubectl to execute it on the cluster. Verifies data by querying from another node.

```shell
curl https://downloads.pgedge.com/platform/examples/northwind/northwind.sql \
    | kubectl cnpg psql pgedge-n1 -- -U app app
kubectl cnpg psql pgedge-n2 -- -U app app -c "select * from northwind.shippers"
```

--------------------------------

### Set Kubectl Context and Namespace

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Sets the active Kubernetes context and namespace for kubectl commands. This ensures subsequent operations are applied to the correct cluster and namespace. Replace `<cluster-context>` and `<desired-namespace>` with your specific values.

```sh
kubectl config use-context <cluster-context> --namespace <desired-namespace>
```

--------------------------------

### Install pgEdge Helm Chart with Local Development Image

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Installs the pgEdge Helm chart using a local development image. It configures the chart to use the specified image for Spock initialization and waits for the deployment to complete.

```bash
helm install \
  --values examples/configs/single/values.yaml \
  --set pgEdge.initSpockImageName=pgedge-helm-utils:dev \
  --wait \
  pgedge ./
```

--------------------------------

### List Kubernetes Clusters and Users (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

These shell commands are used to identify the available Kubernetes clusters and user credentials configured in your local kubeconfig file. This information is necessary for setting up the correct kubectl context.

```shell
kubectl config get-clusters
kubectl config get-users
```

--------------------------------

### Connect to Distributed pgEdge Primary Instance

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Connects to the primary instance of a specific node (e.g., 'n2' or 'n3') in a distributed pgEdge deployment using the kubectl cnpg plugin. This allows direct access to individual node primaries.

```sh
# The 'n2' node's primary instance, if deploying a distributed database
kubectl cnpg psql pgedge-n2 -- -U app app
```

```sh
# The 'n3' node's primary instance, if deploying a distributed database
kubectl cnpg psql pgedge-n3 -- -U app app
```

--------------------------------

### Set PostgreSQL Parameters in values.yaml

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This example demonstrates how to set specific PostgreSQL parameters within the `postgresql.parameters` section of your `values.yaml` file. These parameters are crucial for configuring extensions like Spock.

```yaml
postgresql:
  parameters:
    wal_level: "logical"
    spock.enable_ddl_replication: "on"
    spock.conflict_resolution: "last_update_wins"
    # Other parameters...
```

--------------------------------

### Connect to pgEdge Database Instances (Shell)

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Demonstrates how to connect to pgEdge database instances using the `kubectl cnpg psql` command. It covers connecting to primary instances, read replicas, admin superuser, and nodes in a distributed setup.

```shell
# Connect to the primary instance of node n1 as the app user
kubectl cnpg psql pgedge-n1 -- -U app app

# Connect to a read replica of node n1
kubectl cnpg psql pgedge-n1 --replica -- -U app app

# Connect as the admin superuser
kubectl cnpg psql pgedge-n1 -- -U admin app

# Connect to other nodes in a distributed setup
kubectl cnpg psql pgedge-n2 -- -U app app
kubectl cnpg psql pgedge-n3 -- -U app app
```

--------------------------------

### Promoting a Replica using kubectl cnpg

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/standby.md

This section shows how to promote a standby replica to become the primary instance using the `kubectl cnpg promote` command. It includes an example of the command and the expected output, along with a note on monitoring the promotion status.

```shell
➜ kubectl cnpg promote pgedge-n1 pgedge-n1-2

{"level":"info","ts":"2025-10-14T16:17:16.217477-05:00","msg":"Cluster has become unhealthy"}
Node pgedge-n1-2 in cluster pgedge-n1 will be promoted
```

--------------------------------

### Uninstall pgEdge Helm Chart

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Command to uninstall the pgEdge Helm chart and remove all associated Kubernetes resources. Note that secrets created by cert-manager are retained by default.

```shell
helm uninstall pgedge
```

--------------------------------

### Example CloudNativePG Cluster Specification

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This is a comprehensive example of the `clusterSpec` object within `values.yaml`. It defines image, instances, managed roles, PostgreSQL parameters, pg_hba, pg_ident, and projected volumes.

```yaml
clusterSpec:
  imageName: "ghcr.io/pgedge/pgedge-postgres:17-spock5-standard"
  instances: 1
  managed:
    roles:
      - name: "admin"
        superuser: true
  postgresql:
    parameters:
      checkpoint_completion_target: "0.9"
      spock.allow_ddl_from_functions: "on"
    shared_preload_libraries:
      - "pg_stat_statements"
      - "snowflake"
      - "spock"
    pg_hba:
      - "hostssl app pgedge 0.0.0.0/0 cert"
    pg_ident:
      - "local postgres admin"
  certificates:
    clientCASecret: "client-ca-key-pair"
    replicationTLSSecret: "streaming-replica-client-cert"
```

--------------------------------

### Install CloudNativePG and cert-manager Operators

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Installs the necessary CloudNativePG and cert-manager operators required before deploying the pgEdge Helm chart. Ensures these foundational components are ready in the Kubernetes cluster.

```shell
# Install CloudNativePG operator
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml

# Install cert-manager
kubectl apply -f \
  https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml

# Wait for cert-manager to be ready
kubectl wait --for=condition=Available deployment \
  -n cert-manager cert-manager cert-manager-cainjector cert-manager-webhook --timeout=120s
```

--------------------------------

### Set Kubernetes Context (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

This command creates a new kubectl context named 'helm-test', associating it with the specified Kubernetes cluster and user credentials. This allows you to easily switch between different cluster configurations.

```shell
kubectl config set-context helm-test --cluster=kubernetes --user=kubernetes-admin
```

--------------------------------

### Delete pgEdge Helm Chart Secrets

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/quickstart.md

Demonstrates how to list and delete secrets created by cert-manager for the pgEdge Helm chart. These secrets store client certificates and are not removed by default during uninstallation.

```shell
kubectl get secrets
kubectl delete secret <name>
```

--------------------------------

### Configure Scheduled Backups for pgedge

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Create a ScheduledBackup resource to automate daily backups for a pgedge cluster. This example sets up daily backups at midnight using the Barman Cloud plugin.

```yaml
# ScheduledBackup for daily backups at midnight
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: scheduled-pgedge-n1
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
  cluster:
    name: pgedge-n1
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
```

--------------------------------

### Example pgedge-helm Configuration for Standby Instances

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/standby.md

This YAML configuration demonstrates how to set up a pgedge cluster with multiple instances per node for high availability. It specifies application name, node hostnames, the number of instances per node, synchronous replication settings, and storage size.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw
    - name: n3
      hostname: pgedge-n3-rw
  clusterSpec:
    instances: 3
    postgresql:
      synchronous:
        method: any
        number: 1
        dataDurability: required
    storage:
      size: 1Gi
```

--------------------------------

### Add Changelog Entry with changie

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/releasing.md

Use the changie CLI to create new changelog entries. This command prompts for the change type and description, saving the entry to the `changes/unreleased/` directory. Ensure changie is installed and you have write access to the repository.

```shell
changie new
```

--------------------------------

### Major Version Upgrade: Spock Bootstrap - Initial Setup (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/postgres_upgrades.md

This YAML snippet shows the initial configuration for a PostgreSQL cluster using pgEdge, with two nodes (n1 and n2) running Postgres 16 and Spock 5. This serves as the source environment before introducing a new major version.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw

  clusterSpec:
    imageName: ghcr.io/pgedge/pgedge-postgres:16-spock5-standard
    storage:
      size: 1Gi
```

--------------------------------

### Test Release Candidate Helm Chart

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/releasing.md

Download and install a release candidate (RC) Helm chart from GitHub releases. This allows for testing the chart and its associated Docker image before a final release. You can override the default image version if needed.

```shell
# Download the RC chart from GitHub releases
gh release download vX.Y.Z-rc.1 -p 'pgedge-*.tgz'

# Install with your values
helm install pgedge ./pgedge-X.Y.Z-rc.1.tgz \
  --values examples/configs/single/values.yaml
```

```shell
helm install pgedge ./ \
  --values examples/configs/single/values.yaml \
  --set pgEdge.initSpockImageName=ghcr.io/pgedge/pgedge-helm-utils:vX.Y.Z-rc.1
```

--------------------------------

### Configure Backups with Barman Cloud for pgedge

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Set up scheduled backups to AWS S3 using the Barman Cloud CloudNativePG plugin. This involves installing the plugin, creating AWS credentials, configuring the ObjectStore, and enabling backups in the Helm values.

```shell
# Install Barman Cloud plugin
kubectl apply -f \
  https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/v0.6.0/manifest.yaml

# Create AWS credentials secret
kubectl create secret generic aws-creds \
  --from-literal=ACCESS_KEY_ID=<ACCESS_KEY_ID> \
  --from-literal=ACCESS_SECRET_KEY=<ACCESS_SECRET_KEY>
```

```yaml
# ObjectStore configuration for S3
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: s3-store
spec:
  configuration:
    destinationPath: "s3://my-backup-bucket/pgedge-backups"
    s3Credentials:
      accessKeyId:
        name: aws-creds
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: aws-creds
        key: ACCESS_SECRET_KEY
```

```yaml
# values.yaml - Enable backups on node n1
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
      clusterSpec:
        plugins:
          - name: barman-cloud.cloudnative-pg.io
            isWALArchiver: true
            parameters:
              barmanObjectName: s3-store
    - name: n2
      hostname: pgedge-n2-rw
  clusterSpec:
    storage:
      size: 1Gi
```

```shell
# Run a backup manually
kubectl cnpg backup pgedge-n1 -m plugin --plugin-name barman-cloud.cloudnative-pg.io

# Monitor backup status
kubectl get backups
```

--------------------------------

### Define pgEdge Cluster Nodes in values.yaml

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This example shows the structure for defining individual nodes within the pgEdge cluster using the `pgEdge.nodes` list in `values.yaml`. Each entry represents a CloudNativePG Cluster.

```yaml
pgEdge:
  nodes:
    - name: "node1"
      clusterSpec:
        instances: 3
        # Other cluster specific configurations...
```

--------------------------------

### Connect to pgEdge Node with Password Authentication

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/connecting.md

Connect to a pgEdge database node using password authentication by fetching the password from a Kubernetes secret and using it with the `psql` command. This example retrieves the password for the `app` user from the `pgedge-n3-app` secret and connects to the `app` database on `pgedge-n3-rw`.

```shell
kubectl run psql-client --rm -it \
  --image=ghcr.io/pgedge/pgedge-postgres:17-spock5-standard \
  --env "PGPASSWORD=$(kubectl get secret pgedge-n3-app -o jsonpath='{.data.password}' | base64 -d)" \
  -- psql -h pgedge-n3-rw -d app -U app
```

--------------------------------

### Construct DSN for Client Certificate Authentication

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/connecting.md

Example of a Data Source Name (DSN) string configured for connecting to a pgEdge database using client certificate authentication. It specifies the host, database name, user, and paths to the SSL certificate and key files mounted in the application pod.

```text
host=pgedge-n1-rw dbname=app user=app sslcert=/certificates/app/tls.crt sslkey=/certificates/app/tls.key sslmode=require port=5432
```

--------------------------------

### Example Helm Chart Configuration for Postgres 16

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/postgres_upgrades.md

This YAML configuration defines a PostgreSQL cluster using CloudNativePG with two nodes, running version 16 of the Pgedge PostgreSQL image. It specifies the application name, node hostnames, and storage configuration.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw
  clusterSpec:
    imageName: ghcr.io/pgedge/pgedge-postgres:16-spock5-standard
    storage:
      size: 1Gi
```

--------------------------------

### Monitor Postgres Upgrade Progress

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

These shell commands are used to monitor the progress of a PostgreSQL upgrade within a Kubernetes cluster managed by pgEdge. `kubectl get clusters` provides an overview of cluster status, while `kubectl cnpg status <cluster-name>` offers detailed status for a specific cluster.

```shell
# Monitor upgrade progress
kubectl get clusters
kubectl cnpg status pgedge-n1
```

--------------------------------

### View and Format Postgres Node Logs using kubectl cnpg

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/monitoring.md

This command retrieves logs for a specified Postgres node and formats them for improved readability. It requires the `kubectl cnpg` plugin to be installed and configured. The input is the node name, and the output is formatted log lines.

```shell
kubectl cnpg logs cluster pgedge-n1 | kubectl cnpg logs pretty
```

--------------------------------

### Example Helm Chart Configuration for Postgres 17 Upgrade

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/postgres_upgrades.md

This YAML configuration demonstrates how to upgrade a PostgreSQL cluster to version 17. The `imageName` in `clusterSpec` is updated to point to the new Postgres 17 image, while other configurations remain the same. This change is applied via `helm upgrade`.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw

  clusterSpec:
    imageName: ghcr.io/pgedge/pgedge-postgres:17-spock5-standard
    storage:
      size: 1Gi
```

--------------------------------

### Configure External Nodes for pgEdge

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This example illustrates how to configure `pgEdge.externalNodes` in your `values.yaml` file. This is used for integrating nodes managed outside of this Helm chart, useful for multi-cluster setups.

```yaml
pgEdge:
  externalNodes:
    - host: "external-db.example.com"
      port: 5432
      # Other external node configurations...
```

--------------------------------

### Configure Enterprise pgEdge Helm Deployment (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

This YAML configuration demonstrates a single-region deployment for pgEdge Enterprise Postgres. It specifies a single node 'n1' with 3 instances, configured for synchronous operation with required data durability. The storage size is set to 1Gi.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
      clusterSpec:
        instances: 3
        postgresql:
          synchronous:
            method: any
            number: 1
            dataDurability: required
  clusterSpec:
    storage:
      size: 1Gi
```

--------------------------------

### Configure Distributed pgEdge Helm Deployment (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/install.md

This YAML configuration defines a distributed deployment of pgEdge Helm with three nodes (n1, n2, n3) in a single Kubernetes cluster. Node n1 is set up with 3 instances (1 primary, 2 standby), while n2 and n3 each have 1 primary instance. Storage is configured to 1Gi.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
      clusterSpec:
        instances: 3
        postgresql:
          synchronous:
            method: any
            number: 1
            dataDurability: required
    - name: n2
      hostname: pgedge-n2-rw
    - name: n3
      hostname: pgedge-n3-rw
  clusterSpec:
    storage:
      size: 1Gi
```

--------------------------------

### Perform Helm Upgrade to Apply Node Removal (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/removing_nodes.md

This command executes a `helm upgrade` to apply the changes made to the `values.yaml` file, effectively removing the specified node from the pgedge installation. The `--wait` flag ensures the upgrade completes before proceeding.

```shell
helm upgrade \
--values examples/configs/single/values.yaml \
    --wait \
    pgedge ./
```

--------------------------------

### Update values.yaml to Remove a Node (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/removing_nodes.md

This snippet demonstrates how to modify the `values.yaml` file to remove a node from the `nodes` list. It shows the structure before and after the removal of a node named 'n3'.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw
    - name: n3
      hostname: pgedge-n3-rw
  clusterSpec:
    storage:
      size: 1Gi
```

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw
  clusterSpec:
    storage:
      size: 1Gi
```

--------------------------------

### Check Instance Status and Promote Replica

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

These shell commands are used to manage standby instances. `kubectl cnpg status <cluster-name>` checks the status of instances within a cluster, and `kubectl cnpg promote <cluster-name> <instance-name>` manually promotes a replica to become the primary.

```shell
# Check instance status
kubectl cnpg status pgedge-n1

# Promote a replica manually
kubectl cnpg promote pgedge-n1 pgedge-n1-2
```

--------------------------------

### Perform Patch, Minor, or Major Release

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/releasing.md

Execute make commands to initiate a release. These commands automate the process of batching changelog entries, updating version files, creating release branches, tagging, and pushing changes. Choose the appropriate command based on the desired release type (patch, minor, or major).

```shell
# Patch release (0.1.0 -> 0.1.1)
make patch-release
```

```shell
# Minor release (0.1.0 -> 0.2.0)
make minor-release
```

```shell
# Major release (0.1.0 -> 1.0.0)
make major-release
```

--------------------------------

### Helm Chart Configuration for Cluster A (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/multicluster.md

Configuration for the first Kubernetes cluster in a multi-cluster pgEdge deployment. This setup enables certificate provisioning and configures the first node externally.

```yaml
pgEdge:
  appName: pgedge
  initSpock: false
  provisionCerts: true
  nodes:
    - name: n1
      hostname: n1.example.com           # External hostname for replication
      internalHostname: pgedge-n1-rw     # Cluster-local service for connectivity checks
      clusterSpec:
        instances: 3
        postgresql:
          synchronous:
            method: any
            number: 1
            dataDurability: required
  externalNodes:
    - name: n2
      hostname: n2.example.com
  clusterSpec:
    storage:
      size: 1Gi

```

--------------------------------

### Create Local kind Cluster

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/testing-locally.md

Creates a local Kubernetes cluster using kind with a specified configuration file. This is useful for local development and testing of Kubernetes applications.

```shell
kind create cluster --config examples/configs/single/kind.yaml
```

--------------------------------

### Helm Chart Configuration for Cluster B (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/multicluster.md

Configuration for the second Kubernetes cluster in a multi-cluster pgEdge deployment. This setup disables certificate provisioning and enables Spock initialization, assuming certificates are pre-copied.

```yaml
pgEdge:
  appName: pgedge
  initSpock: true
  provisionCerts: false
  nodes:
    - name: n2
      hostname: n2.example.com           # External hostname for replication
      internalHostname: pgedge-n2-rw     # Cluster-local service for connectivity checks
      clusterSpec:
        instances: 3
        postgresql:
          synchronous:
            method: any
            number: 1
            dataDurability: required
  externalNodes:
    - name: n1
      hostname: n1.example.com
  clusterSpec:
    storage:
      size: 1Gi

```

--------------------------------

### Build Development Docker Image for pgedge-helm-utils

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Builds the pgedge-helm-utils Docker image with development tags. This is typically the first step in a local development workflow.

```bash
make docker-build-dev
```

--------------------------------

### Configure PostgreSQL Shared Preload Libraries

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This snippet shows how to configure `shared_preload_libraries` in your `values.yaml` file. It includes default extensions and demonstrates how to add more. Ensure `spock` is always included for core functionality.

```yaml
postgresql:
  shared_preload_libraries:
    - pg_stat_statements
    - snowflake
    - spock
    # Add other extensions here if needed
```

--------------------------------

### Load Docker Image into Kind Cluster

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Loads a locally built Docker image into a Kind Kubernetes cluster. This makes the image available for deployment within the cluster.

```bash
kind load docker-image pgedge-helm-utils:dev --name my-cluster
```

--------------------------------

### Set kubectl Context for kind Cluster

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/testing-locally.md

Configures kubectl to use the newly created kind cluster and the 'default' namespace. This ensures that subsequent kubectl commands target the local test environment.

```shell
kubectl config use-context kind-single --namespace default
```

--------------------------------

### Configure PostgreSQL Extensions

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

This configuration enables additional PostgreSQL extensions by listing them in `shared_preload_libraries` within the `clusterSpec`. It also shows how to set extension-specific parameters.

```yaml
# values.yaml - Custom extensions configurationpgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
  clusterSpec:
    storage:
      size: 1Gi
    postgresql:
      shared_preload_libraries:
        - pg_stat_statements
        - snowflake
        - spock  # Required for pgEdge
        - pg_cron
      parameters:
        # Extension-specific parameters
        cron.database_name: "app"
```

--------------------------------

### Configure Standby Instances for High Availability

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

This configuration sets up three instances per node for high availability and automatic failover, utilizing synchronous replication. It defines the number of instances and replication parameters.

```yaml
# values.yaml - Three instances per node with synchronous replication
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
    - name: n2
      hostname: pgedge-n2-rw
    - name: n3
      hostname: pgedge-n3-rw
  clusterSpec:
    instances: 3
    postgresql:
      synchronous:
        method: any
        number: 1
        dataDurability: required
    storage:
      size: 1Gi
```

--------------------------------

### Node-Specific ClusterSpec Override in pgEdge Helm Chart (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

Example of overriding the default clusterSpec for a specific node (n1) to configure multiple instances and synchronous replication, while other nodes use default settings. This demonstrates granular control over CloudNativePG cluster configurations per node.

```yaml
pgEdge:
  appName: pgedge
  nodes:
    - name: n1
      hostname: pgedge-n1-rw
      clusterSpec:
        instances: 3
        postgresql:
          synchronous:
            method: any
            number: 1
            dataDurability: required
    - name: n2
      hostname: pgedge-n2-rw
    - name: n3
      hostname: pgedge-n3-rw
```

--------------------------------

### Checking Cluster Status with kubectl cnpg

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/standby.md

This command displays the status of a pgedge cluster, including details about the primary instance, replication status, and individual instance states. This is useful for monitoring cluster health and verifying replication before and after operations like promotion.

```sh
➜ kubectl cnpg status pgedge-n1
```

--------------------------------

### Configure Client Certificate Authentication (YAML)

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Shows how to configure a Kubernetes Pod to mount TLS certificates for secure client-based authentication with the pgEdge database. This involves defining volumes and volume mounts in the pod specification.

```yaml
# Pod specification with certificate volume mount
apiversion: v1
kind: Pod
metadata:
  name: your-application
spec:
  containers:
  - name: your-application
    image: your-application:latest
    volumeMounts:
    - name: app-client-cert
      mountPath: /certificates/app
      readOnly: true
  volumes:
    - name: app-client-cert
      secret:
        secretName: app-client-cert
        items:
          - key: tls.crt
            path: tls.crt
            mode: 0600
          - key: tls.key
            path: tls.key
            mode: 0600
          - key: ca.crt
            path: ca.crt
            mode: 0600
```

--------------------------------

### Initialize Spock Job Configuration

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

This YAML snippet shows the `pgEdge.initSpock` and `pgEdge.initSpockImageName` settings in `values.yaml`. `initSpock` controls the initialization job, and `initSpockImageName` allows specifying a custom image.

```yaml
pgEdge:
  initSpock: true
  initSpockImageName: "ghcr.io/pgedge/pgedge-helm-utils:v1.2.3"
```

--------------------------------

### Configure S3 ObjectStore (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/backups.md

Defines an ObjectStore resource pointing to an AWS S3 bucket and referencing the AWS credentials secret. This is used by the Barman Cloud plugin.

```yaml
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: s3-store
spec:
  configuration:
    destinationPath: "s3://<YOUR BUCKET NAME>/path/if/desired"
    s3Credentials:
      accessKeyId:
        name: aws-creds
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: aws-creds
        key: ACCESS_SECRET_KEY
```

--------------------------------

### Test Active-Active Replication (Shell)

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Verifies Spock replication by creating a table on one node, inserting data on another, and then checking for the data on the initial node. This confirms that data is being replicated correctly across the distributed cluster.

```shell
# Create a table on node n1
kubectl cnpg psql pgedge-n1 -- -U app app -c \
  "create table example (id int primary key, data text);"

# Insert data on node n2
kubectl cnpg psql pgedge-n2 -- -U app app -c \
  "insert into example (id, data) values (1, 'Hello, pgEdge!');"

# Verify replication back to node n1
kubectl cnpg psql pgedge-n1 -- -U app app -c "select * from example;"
# Output:
#  id |      data
# ----+----------------
#   1 | Hello, pgEdge!
```

--------------------------------

### Verify Helm Chart Signature

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/releasing.md

Use the `helm verify` command to check the GPG signature of a downloaded Helm chart and its provenance file. This ensures the integrity and authenticity of the released chart. Ensure you have the necessary public key in your keyring.

```shell
# Download the chart and provenance file from the GitHub release
helm verify pgedge-X.Y.Z.tgz
```

--------------------------------

### Default PostgreSQL Parameters for Spock Nodes (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/configuration.md

Illustrates the default PostgreSQL parameters automatically configured by the pgEdge Helm chart for Spock replication, specifically for 'snowflake.node' and 'lolor.node'. These settings ensure proper multi-master replication initialization.

```yaml
postgresql:
  parameters:
    lolor.node: "1"
    snowflake.node: "1"
```

--------------------------------

### Monitor pgEdge Spock Initialization Job

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Follows the logs of the Kubernetes job responsible for initializing Spock within the pgEdge cluster. This is useful for debugging initialization issues.

```bash
kubectl logs --follow jobs/pgedge-init-spock
```

--------------------------------

### Create AWS Credentials Secret (Shell)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/backups.md

Creates a Kubernetes secret to store AWS access keys for Barman Cloud. Replace placeholders with actual credentials.

```shell
kubectl create secret generic aws-creds \
    --from-literal=ACCESS_KEY_ID=<ACCESS_KEY_ID> \
    --from-literal=ACCESS_SECRET_KEY=<ACCESS_SECRET_KEY>
```

--------------------------------

### Create Scheduled Backup (YAML)

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/backups.md

Defines a ScheduledBackup resource to automate daily backups for a CloudNativePG cluster at midnight using the Barman plugin method.

```yaml
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: scheduled-pgedge-n1
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
  cluster:
    name: pgedge-n1
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
```

--------------------------------

### Configure Application for Client Certificate Authentication

Source: https://github.com/pgedge/pgedge-helm/blob/main/docs/usage/connecting.md

This YAML configuration demonstrates how to mount client certificates (tls.crt, tls.key, ca.crt) from a Kubernetes secret into an application pod. These certificates are used for secure authentication and encrypted traffic when connecting to the pgEdge database.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: your-application
spec:
  containers:
  - name: your-application
    image: your-application:latest
    volumeMounts:
    - name: app-client-cert
      mountPath: /certificates/app
      readOnly: true
volumes:
  - name: app-client-cert
    secret:
      secretName: app-client-cert
      items:
        - key: tls.crt
          path: tls.crt
          mode: 0600
        - key: tls.key
          path: tls.key
          mode: 0600
        - key: ca.crt
          path: ca.crt
          mode: 0600
```

--------------------------------

### Connect to pgedge with Password Authentication using kubectl

Source: https://context7.com/pgedge/pgedge-helm/llms.txt

Connect to a pgedge cluster using password authentication by retrieving credentials from Kubernetes secrets and running a psql client pod. This method is useful for interactive debugging and administration.

```shell
# Run a psql client pod with password from secret
kubectl run psql-client --rm -it \
  --image=ghcr.io/pgedge/pgedge-postgres:17-spock5-standard \
  --env "PGPASSWORD=$(kubectl get secret pgedge-n3-app -o jsonpath='{.data.password}' | base64 -d)" \
  -- psql -h pgedge-n3-rw -d app -U app
```