ਕਰੰਚੀ ਡੇਟਾ ਪੀਜੀਓ ਦੇ ਨਾਲ PostgreSQL ਉੱਚ ਉਪਲਬਧਤਾ: ਐਂਟਰਪ੍ਰਾਈਜ਼ Kubernetes ਤੈਨਾਤੀ

Kubernetes 'ਤੇ ਉਤਪਾਦਨ ਵਿੱਚ PostgreSQL ਚੱਲ ਰਿਹਾ ਹੈ, ਇੱਕ ਸਥਾਈ ਵਾਲੀਅਮ ਦੇ ਨਾਲ ਇੱਕ ਸਟੇਟਫੁੱਲਸੈੱਟ ਤੋਂ ਵੱਧ ਮੰਗ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਸਵੈਚਲਿਤ ਫੇਲਓਵਰ, ਨਿਰੰਤਰ ਬੈਕਅਪ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ, TLS ਐਨਕ੍ਰਿਪਸ਼ਨ, ਨਿਗਰਾਨੀ, ਅਤੇ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਅਤੇ ਬੇਅਰ ਮੈਟਲ ਵਿੱਚ ਲਗਾਤਾਰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੀ ਲੋੜ ਹੈ। Crunchy Data PGO (Postgres ਆਪਰੇਟਰ) v5 ਇਹ ਸਭ ਇੱਕ ਸਿੰਗਲ Kubernetes-ਨੇਟਿਵ ਕਸਟਮ ਸਰੋਤ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ —PostgresClusterCRD — ਲੜਾਈ-ਟੈਸਟ ਕੀਤੇ ਭਾਗਾਂ ਦੁਆਰਾ ਸਮਰਥਤ: ਸਹਿਮਤੀ-ਅਧਾਰਤ HA ਲਈ Patroni, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਲਈ pgBackRest, ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਲਈ PgBouncer, ਅਤੇ XPRg ਪੂਲਿੰਗ ਲਈ observable-0 XPR.

ਇਹ ਗਾਈਡ ਰੈਂਚਰ ਦੇ ਨਾਲ AWS EKS, Azure AKS, GCP GKE, ਅਤੇ ਬੇਅਰ ਮੈਟਲ k3s ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਤੈਨਾਤੀ ਤੋਂ ਲੈ ਕੇ ਉਤਪਾਦਨ-ਗਰੇਡ ਓਪਰੇਸ਼ਨ ਤੱਕ ਇੱਕ PGO-ਪ੍ਰਬੰਧਿਤ PostgreSQL ਕਲੱਸਟਰ ਲੈਣ ਲਈ ਲੋੜੀਂਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਭਾਗ ਵਿੱਚ ਠੋਸ YAML, Helm ਮੁੱਲ, ਅਤੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਵਾਤਾਵਰਣ ਦੇ ਅਨੁਕੂਲ ਬਣਾ ਸਕਦੇ ਹੋ।

ਕਰੰਚੀ ਡੇਟਾ PGO v5 ਆਰਕੀਟੈਕਚਰ

PGO v5 ਕ੍ਰੰਚੀ Postgres ਆਪਰੇਟਰ ਦਾ ਸੰਪੂਰਨ ਰੀਰਾਈਟ ਹੈ। ਇਹ ਪਿਛਲੇ pgcluster/pgreplica/pgpolicy CRDs ਨੂੰ ਇੱਕ ਸਿੰਗਲPostgresClusterਸਰੋਤ ਨਾਲ ਬਦਲਦਾ ਹੈ ਜੋ ਇੱਕ PostgreSQL ਤੈਨਾਤੀ ਦੇ ਹਰ ਪਹਿਲੂ ਦਾ ਵਰਣਨਯੋਗ ਰੂਪ ਵਿੱਚ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਓਪਰੇਟਰ ਇਸ ਸਰੋਤ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਅੰਡਰਲਾਈੰਗ Kubernetes ਵਸਤੂਆਂ — ਸਟੇਟਫੁਲਸੈੱਟਸ, ਸੇਵਾਵਾਂ, ਕੌਨਫਿਗਮੈਪਸ, ਸੀਕਰੇਟਸ, ਜੌਬਸ — ਨੂੰ ਮਿਲਾ ਲੈਂਦਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਚਾਰ ਥੰਮ੍ਹਾਂ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ।Patroniਹਰੇਕ PostgreSQL ਪੌਡ ਵਿੱਚ ਇੱਕ ਸਾਈਡਕਾਰ ਵਜੋਂ ਚੱਲਦਾ ਹੈ ਅਤੇ Kubernetes-ਦੇਸੀ ਵੰਡੀ ਸਹਿਮਤੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਲੀਡਰ ਚੋਣ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਟੋਪੋਲੋਜੀ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ।pgBackRestਆਬਜੈਕਟ ਸਟੋਰੇਜ (S3, GCS, Azure ਬਲੌਬ) ਜਾਂ ਸਥਾਨਕ PVCs ਲਈ ਪੂਰੇ, ਵਿਭਿੰਨਤਾ, ਅਤੇ ਵਾਧੇ ਵਾਲੇ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਨਾਲ ਲਗਾਤਾਰ WAL ਪੁਰਾਲੇਖ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।PgBouncerਹਲਕੇ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ PostgreSQL ਨੂੰ ਕੁਨੈਕਸ਼ਨ ਤੂਫਾਨਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।pgMonitorਤੁਹਾਡੇ ਮੌਜੂਦਾ ਨਿਰੀਖਣਯੋਗਤਾ ਸਟੈਕ ਨਾਲ ਏਕੀਕਰਣ ਲਈ Prometheus ਨਿਰਯਾਤਕ ਸਾਈਡਕਾਰ ਦੁਆਰਾ PostgreSQL ਮੈਟ੍ਰਿਕਸ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ।

ਆਪਰੇਟਰ ਖੁਦ ਸਟੇਟਲੈੱਸ ਹੈ — ਸਾਰੀਆਂ ਸਥਾਈ ਸਥਿਤੀ PostgreSQL ਕਲੱਸਟਰ ਅਤੇ ਇਸਦੇ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਚੱਲ ਰਹੇ ਡੇਟਾਬੇਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਆਪਰੇਟਰ ਨੂੰ ਅੱਪਗਰੇਡ ਜਾਂ ਰੀਸਟਾਰਟ ਕਰ ਸਕਦੇ ਹੋ। ਆਪਰੇਟਰ ਰੀਕਸੀਲੀਏਸ਼ਨ ਲੂਪ ਅਯੋਗ ਹੈ: ਇੱਕੋPostgresClusterਸਪੇਕ ਨੂੰ ਕਈ ਵਾਰ ਲਾਗੂ ਕਰਨ ਨਾਲ Kubernetes ਵਸਤੂਆਂ ਦਾ ਇੱਕੋ ਸੈੱਟ ਪੈਦਾ ਹੁੰਦਾ ਹੈ।

PGO v5

PGO v5 ਨੂੰ Helm ਜਾਂ ਡਾਇਰੈਕਟ kubectl ਮੈਨੀਫੈਸਟ ਦੁਆਰਾ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। Helm ਪਹੁੰਚ ਨੂੰ ਉਤਪਾਦਨ ਲਈ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ GitOps ਵਰਕਫਲੋਜ਼ ਦੇ ਨਾਲ ਸਾਫ਼-ਸੁਥਰਾ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੰਸਕਰਣ-ਨਿਯੰਤਰਿਤ ਅੱਪਗਰੇਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

# Add the Crunchy Data Helm repository
helm repo add crunchydata https://charts.crunchydata.com
helm repo update

# Install PGO into its own namespace
helm install pgo crunchydata/pgo \
  --namespace postgres-operator \
  --create-namespace \
  --set controllerImages.cluster=registry.crunchydata.com/crunchydata/postgres-operator:ubi8-5.7.2-0 \
  --set relatedImages.postgres_16=registry.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.6-1 \
  --set relatedImages.pgbackrest=registry.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.54.1-0 \
  --set relatedImages.pgbouncer=registry.crunchydata.com/crunchydata/crunchy-pgbouncer:ubi8-1.23.1-0 \
  --set relatedImages.pgexporter=registry.crunchydata.com/crunchydata/crunchy-postgres-exporter:ubi8-0.16.0-0

ਏਅਰ-ਗੈਪਡ ਵਾਤਾਵਰਨ ਲਈ, ਲੋੜੀਂਦੇ ਚਿੱਤਰਾਂ ਨੂੰ ਆਪਣੀ ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਵਿੱਚ ਮਿਰਰ ਕਰੋ ਅਤੇ ਉਸ ਅਨੁਸਾਰrelatedImagesਮੁੱਲਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ। PGO ਸਿਰਫ਼ Helm ਮੁੱਲਾਂ ਜਾਂPostgresClusterਸਪੇਕ ਵਿੱਚ ਦਰਸਾਏ ਚਿੱਤਰਾਂ ਨੂੰ ਖਿੱਚੇਗਾ — ਇਹ ਰਨਟਾਈਮ 'ਤੇ ਕਦੇ ਵੀ ਬਾਹਰੀ ਰਜਿਸਟਰੀਆਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ ਜਦੋਂ ਤੱਕ ਕਿ ਅਜਿਹਾ ਕਰਨ ਲਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।

# Verify the operator is running
kubectl get pods -n postgres-operator
NAME                                READY   STATUS    RESTARTS   AGE
pgo-controller-manager-7d8f9b6c4-xk2pt   1/1     Running   0          45s

PostgresCluster CRD ਨਿਰਧਾਰਨ

PostgresClusterCRD ਤੁਹਾਡੀ ਪੂਰੀ PostgreSQL ਤੈਨਾਤੀ ਲਈ ਸਿੰਗਲ ਘੋਸ਼ਣਾਤਮਕ ਸਤਹ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਉਤਪਾਦਨ-ਤਿਆਰ ਨਿਰਧਾਰਨ ਹੈ ਜੋ ਮੁੱਖ ਭਾਗਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਗਾਈਡ ਦੇ ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ਹਰੇਕ ਭਾਗ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ।

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: production-db
  namespace: databases
spec:
  postgresVersion: 16
  image: registry.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.6-1

  instances:
    - name: pgha1
      replicas: 3
      resources:
        requests:
          cpu: "2"
          memory: 8Gi
        limits:
          cpu: "4"
          memory: 16Gi
      dataVolumeClaimSpec:
        storageClassName: gp3-csi
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi
      walVolumeClaimSpec:
        storageClassName: gp3-csi
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 20Gi
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - topologyKey: kubernetes.io/hostname
              labelSelector:
                matchLabels:
                  postgres-operator.crunchydata.com/cluster: production-db
      tolerations:
        - key: "workload"
          operator: "Equal"
          value: "database"
          effect: "NoSchedule"

  backups:
    pgbackrest:
      image: registry.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.54.1-0
      configuration:
        - secret:
            name: pgbackrest-s3-creds
      global:
        repo1-retention-full: "7"
        repo1-retention-diff: "14"
        repo1-path: /pgbackrest/production-db/repo1
        repo1-s3-uri-style: path
      repos:
        - name: repo1
          schedules:
            full: "0 2 * * 0"         # Sunday 2am
            differential: "0 2 * * 1-6" # Mon-Sat 2am
            incremental: "0 */4 * * *"  # Every 4 hours
          s3:
            bucket: mycompany-pg-backups
            endpoint: s3.eu-west-1.amazonaws.com
            region: eu-west-1

  proxy:
    pgBouncer:
      image: registry.crunchydata.com/crunchydata/crunchy-pgbouncer:ubi8-1.23.1-0
      replicas: 2
      resources:
        requests:
          cpu: 500m
          memory: 256Mi
        limits:
          cpu: "1"
          memory: 512Mi
      config:
        global:
          pool_mode: transaction
          max_client_conn: "1000"
          default_pool_size: "25"
          min_pool_size: "5"
          reserve_pool_size: "5"
          reserve_pool_timeout: "3"

  monitoring:
    pgmonitor:
      exporter:
        image: registry.crunchydata.com/crunchydata/crunchy-postgres-exporter:ubi8-0.16.0-0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

  patroni:
    dynamicConfiguration:
      synchronous_mode: true
      postgresql:
        parameters:
          shared_buffers: 2GB
          effective_cache_size: 6GB
          work_mem: 32MB
          maintenance_work_mem: 512MB
          max_connections: 200
          wal_buffers: 64MB
          checkpoint_completion_target: 0.9
          random_page_cost: 1.1
          effective_io_concurrency: 200
          min_wal_size: 1GB
          max_wal_size: 4GB
          max_worker_processes: 8
          max_parallel_workers_per_gather: 4
          max_parallel_workers: 8
          log_min_duration_statement: 500
          log_checkpoints: "on"
          log_connections: "on"
          log_disconnections: "on"
          log_lock_waits: "on"

  users:
    - name: appuser
      databases: ["appdb"]
      options: "NOSUPERUSER"
    - name: readonly
      databases: ["appdb"]
      options: "NOSUPERUSER"

  databaseInitSQL:
    name: init-sql-configmap
    key: init.sql

ਇਹ ਨਿਰਧਾਰਨ ਵੱਖਰੇ ਡੇਟਾ ਅਤੇ WAL ਵੌਲਯੂਮ ਦੇ ਨਾਲ ਇੱਕ ਤਿੰਨ-ਇਨਸਟੈਂਸ PostgreSQL 16 ਕਲੱਸਟਰ ਬਣਾਉਂਦਾ ਹੈ, ਇੱਕ ਪੂਰੇ/ਵਿਭਿੰਨ/ਵਧੇਰੇ ਅਨੁਸੂਚੀ 'ਤੇ S3-ਬੈਕਡ ਬੈਕਅੱਪ, ਲੈਣ-ਦੇਣ ਮੋਡ ਵਿੱਚ PgBouncer ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ, Prometheus ਮੈਟ੍ਰਿਕਸ ਨਿਰਯਾਤ, ਅਤੇ Patroni ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ। ਪੌਡ ਐਂਟੀ-ਐਫੀਨਿਟੀ ਨਿਯਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤਿੰਨੋਂ ਸਥਿਤੀਆਂ ਵੱਖ-ਵੱਖ Kubernetes ਨੋਡਾਂ 'ਤੇ ਉਤਰਦੀਆਂ ਹਨ।

ਪੈਟਰੋਨੀ-ਅਧਾਰਿਤ HA ਅਤੇ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ

Patroni ਇੱਕ HA ਫਰੇਮਵਰਕ ਹੈ ਜੋ PGO-ਪ੍ਰਬੰਧਿਤ PostgreSQL ਪੌਡ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ Kubernetes API ਨੂੰ ਇਸਦੇ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਟੋਰ (DCS) ਦੇ ਤੌਰ ਤੇ ਵਰਤਦਾ ਹੈ — ਕੋਈ ਵੱਖਰੀ etcd ਜਾਂ ZooKeeper ਕਲੱਸਟਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਪੈਟਰੋਨੀ PostgreSQL ਪ੍ਰਾਇਮਰੀ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਸਿਹਤ ਦੀ ਲਗਾਤਾਰ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਪ੍ਰਾਇਮਰੀ ਗੈਰ-ਜਵਾਬਦੇਹ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪੈਟਰੋਨੀ ਇੱਕ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦਾ ਹੈ: ਇਹ ਸਭ ਤੋਂ ਨਵੀਨਤਮ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਤੱਕ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਲੀਡਰ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਬਾਕੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ।

PGO ਵਿੱਚ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਪੌਡ 'ਤੇ ਪੈਟਰੋਨੀ Kubernetes (ਐਂਡਪੁਆਇੰਟ ਜਾਂ ਕੌਨਫਿਗਮੈਪ ਆਬਜੈਕਟ ਰਾਹੀਂ) ਵਿੱਚ ਇੱਕ ਲੀਡਰ ਲਾਕ ਰੱਖਦਾ ਹੈ। ਮੌਜੂਦਾ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਇੱਕ ਸੰਰਚਨਾਯੋਗ ਅੰਤਰਾਲ 'ਤੇ ਇਸ ਲਾਕ ਨੂੰ ਰੀਨਿਊ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਡਿਫੌਲਟ 10 ਸਕਿੰਟ TTL, 3 ਸਕਿੰਟ ਲੂਪ ਉਡੀਕ)। ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਰੀਨਿਊ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ — ਕਿਉਂਕਿ ਇਹ ਕਰੈਸ਼ ਹੋ ਗਿਆ, ਨੋਡ ਮਰ ਗਿਆ, ਜਾਂ ਨੈੱਟਵਰਕ ਨੇ ਇਸਨੂੰ ਵੰਡ ਦਿੱਤਾ — ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜੋ ਪ੍ਰਾਇਮਰੀ ਦੀ WAL ਸਥਿਤੀ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਹੈ, ਲਾਕ ਨੂੰ ਹਾਸਲ ਕਰੇਗੀ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰੇਗੀ। ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਆਮ ਤੌਰ 'ਤੇ 10 ਤੋਂ 30 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਮੋਡ, ਪੈਟਰੋਨੀ ਸੰਰਚਨਾ ਵਿੱਚsynchronous_mode: trueਦੁਆਰਾ ਸਮਰਥਿਤ, ਥੋੜ੍ਹਾ ਵੱਧ ਲਿਖਣ ਦੀ ਲੇਟੈਂਸੀ ਦੀ ਕੀਮਤ 'ਤੇ ਜ਼ੀਰੋ ਡਾਟਾ ਨੁਕਸਾਨ (RPO = 0) ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ। ਸਮਕਾਲੀ ਮੋਡ ਵਿੱਚ, ਇੱਕ ਲੈਣ-ਦੇਣ ਗਾਹਕ ਨੂੰ ਉਦੋਂ ਤੱਕ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੇ WAL ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਪੈਟਰੋਨੀ ਉਪਲਬਧਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਮਕਾਲੀ ਮੋਡ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ — ਜੇਕਰ ਤੁਸੀਂ ਇਕਸਾਰਤਾ ਲਈ ਉਪਲਬਧਤਾ ਨੂੰ ਕੁਰਬਾਨ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰsynchronous_mode_strict: trueਨਾਲ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ।

# Check Patroni cluster status
kubectl exec -it production-db-pgha1-0 -n databases -- patronictl list

+----------------------------+-------------------+---------+---------+----+-----------+
| Member                     | Host              | Role    | State   | TL | Lag in MB |
+----------------------------+-------------------+---------+---------+----+-----------+
| production-db-pgha1-0      | 10.244.0.15       | Leader  | running |  3 |           |
| production-db-pgha1-1      | 10.244.1.22       | Replica | running |  3 |         0 |
| production-db-pgha1-2      | 10.244.2.18       | Replica | running |  3 |         0 |
+----------------------------+-------------------+---------+---------+----+-----------+

# Manual switchover (planned, zero downtime)
kubectl exec -it production-db-pgha1-0 -n databases -- \
  patronictl switchover --master production-db-pgha1-0 --candidate production-db-pgha1-1 --force

# Manual failover (forced, for emergencies)
kubectl exec -it production-db-pgha1-1 -n databases -- \
  patronictl failover --candidate production-db-pgha1-1 --force

PGO ਪੈਟਰੋਨੀ ਲੀਡਰ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ Kubernetes ਸੇਵਾਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ।production-db-primaryਸੇਵਾ ਹਮੇਸ਼ਾਂ ਉਸ ਪੌਡ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਲੀਡਰ ਲਾਕ ਹੈ, ਇਸਲਈ ਇਸ ਸੇਵਾ ਦੁਆਰਾ ਕਨੈਕਟ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਸਿਰਫ ਇੱਕ ਸੰਖੇਪ ਕੁਨੈਕਸ਼ਨ ਰੀਸੈਟ ਨਾਲ ਸਹਿਜ ਫੇਲਓਵਰ ਦਾ ਅਨੁਭਵ ਕਰਦੀਆਂ ਹਨ।

pgBackRest ਬੈਕਅੱਪ ਅਤੇ

pgBackRest PGO ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅੱਪ ਇੰਜਣ ਹੈ। ਇਹ ਤਿੰਨ ਬੈਕਅੱਪ ਕਿਸਮਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ — ਫੁੱਲ, ਡਿਫਰੈਂਸ਼ੀਅਲ, ਅਤੇ ਇਨਕਰੀਮੈਂਟਲ — ਨਾਲ ਹੀ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਲਈ ਲਗਾਤਾਰ WAL ਆਰਕਾਈਵਿੰਗ। ਇਹ ਸਮਝਣਾ ਕਿ ਇਹ ਕਿਵੇਂ ਇਕੱਠੇ ਫਿੱਟ ਹਨ ਇੱਕ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਤਿਆਰ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਜੋ ਸਟੋਰੇਜ ਲਾਗਤ, ਬੈਕਅੱਪ ਸਪੀਡ, ਅਤੇ ਰਿਕਵਰੀ ਸਮੇਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਦੀ ਹੈ।

Aਪੂਰਾ ਬੈਕਅੱਪਪੂਰੀ PostgreSQL ਡਾਟਾ ਡਾਇਰੈਕਟਰੀ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਾਰੀਆਂ ਬੈਕਅੱਪ ਕਿਸਮਾਂ ਲਈ ਬੇਸਲਾਈਨ ਹੈ। ਇੱਕਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪਸਿਰਫ਼ ਉਹਨਾਂ ਪੰਨਿਆਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜੋ ਪਿਛਲੇ ਪੂਰੇ ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ ਬਦਲ ਗਏ ਹਨ। ਇੱਕਵਾਧੇ ਵਾਲਾ ਬੈਕਅੱਪਸਿਰਫ਼ ਉਹਨਾਂ ਪੰਨਿਆਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਪਿਛਲੇ ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ ਬਦਲ ਗਏ ਹਨ। ਰੀਸਟੋਰ ਦੇ ਦੌਰਾਨ, pgBackRest ਆਪਣੇ ਆਪ ਹੀ ਲੋੜੀਂਦੇ ਬੈਕਅੱਪਾਂ ਨੂੰ ਇਕੱਠੇ ਚੇਨ ਕਰਦਾ ਹੈ — ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵਾਧੇ ਤੋਂ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਇਨਕਰੀਮੈਂਟਲ ਪਲੱਸ ਪੁਰਾਣੇ ਡਿਫਰੈਂਸ਼ੀਅਲ (ਜਾਂ ਪੂਰਾ) ਅਤੇ ਪੂਰੇ ਬੈਕਅੱਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾਲ ਹੀ ਟਾਰਗੇਟ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਲੋੜੀਂਦੇ ਕਿਸੇ ਵੀ WAL ਹਿੱਸੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ ਕੌਂਫਿਗਰੇਸ਼ਨ

ਬੈਕਅੱਪ ਅਨੁਸੂਚੀ ਨੂੰPostgresClusterਸਪੇਕ ਦੇ ਅੰਦਰ pgBackRest ਸੰਰਚਨਾ ਦੇreposਭਾਗ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕ ਠੋਸ ਉਤਪਾਦਨ ਅਨੁਸੂਚੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਹਫ਼ਤਾਵਾਰ ਪੂਰਾ, ਰੋਜ਼ਾਨਾ ਅੰਤਰ, ਅਤੇ ਵਧੇਰੇ ਵਾਰ-ਵਾਰ ਵਾਧੇ ਵਾਲੇ ਬੈਕਅਪ ਚਲਾਉਂਦੀ ਹੈ।

backups:
  pgbackrest:
    global:
      repo1-retention-full: "4"        # Keep 4 full backups
      repo1-retention-full-type: count
      repo1-retention-diff: "14"       # Keep 14 differentials
    repos:
      - name: repo1
        schedules:
          full: "0 2 * * 0"            # Weekly full: Sunday 2am
          differential: "0 2 * * 1-6"  # Daily diff: Mon-Sat 2am
          incremental: "0 */6 * * *"   # Every 6 hours
        s3:
          bucket: mycompany-pg-backups
          endpoint: s3.eu-west-1.amazonaws.com
          region: eu-west-1

ਮੈਨੁਅਲ ਬੈਕਅੱਪ ਅਤੇ

# Trigger a manual full backup
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/pgbackrest-backup="$(date +%s)" \
  --overwrite

# Check backup status
kubectl exec -it production-db-pgha1-0 -n databases -- \
  pgbackrest info --stanza=db

# Restore to a specific point in time
# First, update the PostgresCluster spec:
spec:
  backups:
    pgbackrest:
      restore:
        enabled: true
        repoName: repo1
        options:
          - --type=time
          - --target="2026-04-12 08:30:00+00"
          - --target-action=promote

# Apply the restore annotation
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/pgbackrest-restore="$(date +%s)" \
  --overwrite

ਇੱਕ PITR ਰੀਸਟੋਰ ਦੇ ਦੌਰਾਨ, PGO ਸਾਰੀਆਂ PostgreSQL ਉਦਾਹਰਨਾਂ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਨਜ਼ਦੀਕੀ ਪੂਰੇ ਜਾਂ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਤੋਂ ਰੀਸਟੋਰ ਕਰਦਾ ਹੈ, WAL ਖੰਡਾਂ ਨੂੰ ਟੀਚੇ ਦੇ ਸਮੇਂ ਤੱਕ ਰੀਪਲੇ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਸਾਰੀ ਕਾਰਵਾਈ ਆਪਰੇਟਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ - ਵਿਅਕਤੀਗਤ ਪੌਡਾਂ 'ਤੇ ਕਿਸੇ ਹੱਥੀਂ ਦਖਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

PgBouncer ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ

PostgreSQL ਹਰੇਕ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਲਈ ਇੱਕ ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਂਦਾ ਹੈ। ਪੈਮਾਨੇ 'ਤੇ - ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਐਪਲੀਕੇਸ਼ਨ ਪੌਡ ਹਰੇਕ ਕੁਨੈਕਸ਼ਨ ਪੂਲ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹਨ - ਇਹ ਮਾਡਲ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। PgBouncer ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ PostgreSQL ਦੇ ਵਿਚਕਾਰ ਬੈਠਦਾ ਹੈ, ਸਰਵਰ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੰਖਿਆ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਮਲਟੀਪਲੈਕਸ ਕਰਦਾ ਹੈ।

PGO ਆਪਣੀ ਖੁਦ ਦੀ ਸੇਵਾ ਨਾਲ PgBouncer ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਤੈਨਾਤੀ ਵਜੋਂ ਤੈਨਾਤ ਕਰਦਾ ਹੈ।production-db-pgbouncerਸੇਵਾ ਉਹ ਹੈ ਜਿਸ ਨਾਲ ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਨੈਕਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, PostgreSQL ਪ੍ਰਾਇਮਰੀ ਸੇਵਾ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਹੀਂ। PgBouncer ਤਿੰਨ ਪੂਲ ਮੋਡਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ:

• ਸੈਸ਼ਨ ਪੂਲਿੰਗ— ਇੱਕ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਦੇ ਜੀਵਨ ਕਾਲ ਲਈ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ, ਪਰ ਘੱਟ ਕੁਸ਼ਲ।
• ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪੂਲਿੰਗ— ਇੱਕ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਸਿਰਫ ਇੱਕ ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਵੈੱਬ ਵਰਕਲੋਡ ਲਈ ਸਭ ਤੋਂ ਕੁਸ਼ਲ. ਇਹ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਡਿਫੌਲਟ ਹੈ।
• ਸਟੇਟਮੈਂਟ ਪੂਲਿੰਗ— ਇੱਕ ਸਿੰਗਲ ਸਟੇਟਮੈਂਟ ਲਈ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਿਰਫ਼ ਸਧਾਰਨ, ਗੈਰ-ਲੈਣ-ਦੇਣ ਵਾਲੇ ਵਰਕਲੋਡ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ।

proxy:
  pgBouncer:
    replicas: 3
    config:
      global:
        pool_mode: transaction
        max_client_conn: "2000"
        default_pool_size: "30"
        min_pool_size: "10"
        reserve_pool_size: "10"
        reserve_pool_timeout: "3"
        server_idle_timeout: "300"
        server_lifetime: "3600"
        client_idle_timeout: "600"
        tcp_keepalive: "1"
        tcp_keepidle: "30"
        tcp_keepintvl: "10"
        tcp_keepcnt: "3"
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
              labelSelector:
                matchLabels:
                  postgres-operator.crunchydata.com/role: pgbouncer

tcp_keepaliveਸੈਟਿੰਗਾਂ ਨੂੰ ਨੋਟ ਕਰੋ — ਜਦੋਂ PgBouncer ਇੱਕ ਕਲਾਊਡ ਲੋਡ ਬੈਲੈਂਸਰ ਜਾਂ Kubernetes ਸੇਵਾ ਦੇ ਪਿੱਛੇ ਚੱਲਦਾ ਹੈ ਤਾਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਹਮਲਾਵਰ ਰੱਖ-ਰਖਾਅ ਦੇ ਬਿਨਾਂ, ਨਿਸ਼ਕਿਰਿਆ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਵਿਚਕਾਰਲੇ ਨੈੱਟਵਰਕ ਕੰਪੋਨੈਂਟਸ ਦੁਆਰਾ ਚੁੱਪਚਾਪ ਸੁੱਟਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਗਲੀ ਪੁੱਛਗਿੱਛ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

pgMonitor ਅਤੇ Prometheus/Grafana ਨਿਗਰਾਨੀ

PGO ਦੀ ਨਿਗਰਾਨੀ ਏਕੀਕਰਣ ਹਰੇਕ PostgreSQL ਪੌਡ ਵਿੱਚ ਇੱਕcrunchy-postgres-exporterਸਾਈਡਕਾਰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ। ਇਹ ਨਿਰਯਾਤਕਰਤਾ PostgreSQL ਦੇ ਅੰਦਰੂਨੀ ਅੰਕੜਿਆਂ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਸਕ੍ਰੈਪ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪੋਰਟ 9187 'ਤੇ Prometheus ਮੈਟ੍ਰਿਕਸ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ਨਿਰਯਾਤਕ 150 ਤੋਂ ਵੱਧ ਮੀਟ੍ਰਿਕਸ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਕੁਨੈਕਸ਼ਨ, ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦਰਾਂ, ਕੈਸ਼ ਹਿੱਟ ਅਨੁਪਾਤ, ਟੇਬਲ ਅਤੇ ਸੂਚਕਾਂਕ ਅੰਕੜੇ, ਡਬਲਯੂ.ਏ.ਐਲ.

# ServiceMonitor for Prometheus Operator auto-discovery
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: postgres-monitoring
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      postgres-operator.crunchydata.com/cluster: production-db
      postgres-operator.crunchydata.com/crunchy-postgres-exporter: "true"
  endpoints:
    - port: exporter
      interval: 15s
      scrapeTimeout: 10s

ਕਰੰਚੀ ਡੇਟਾ ਪੂਰਵ-ਨਿਰਮਿਤ Grafana ਡੈਸ਼ਬੋਰਡਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਿੱਧੇ ਆਯਾਤ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ PostgreSQL ਸੰਖੇਪ ਜਾਣਕਾਰੀ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਥਿਤੀ, pgBackRest ਬੈਕਅੱਪ ਸਥਿਤੀ, PgBouncer ਅੰਕੜੇ, ਅਤੇ ਪੌਡ-ਪੱਧਰ ਦੇ ਸਰੋਤ ਵਰਤੋਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ Grafana ਦੇ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਦੁਆਰਾ ਜਾਂ ਕ੍ਰੰਚੀ ਡੇਟਾ ਉਦਾਹਰਣਾਂ ਦੇ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਹੱਥੀਂ ਆਯਾਤ ਕਰੋ।

# Install Grafana dashboards as ConfigMaps
kubectl create configmap grafana-pg-overview \
  --from-file=pg-overview.json=dashboards/pg-overview.json \
  -n monitoring
kubectl label configmap grafana-pg-overview grafana_dashboard=1 -n monitoring

ਗੰਭੀਰ ਚੇਤਾਵਨੀ ਨਿਯਮ

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: postgres-alerts
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: postgresql-health
      rules:
        - alert: PostgresReplicationLagHigh
          expr: ccp_replication_lag_size_bytes > 104857600
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Replica {{ $labels.pod }} lag exceeds 100MB"

        - alert: PostgresConnectionsExhausted
          expr: ccp_connection_stats_active / ccp_connection_stats_max_connections > 0.85
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "PostgreSQL connections above 85% capacity"

        - alert: PostgresDeadlockDetected
          expr: rate(ccp_stat_database_deadlocks[5m]) > 0
          for: 1m
          labels:
            severity: warning
          annotations:
            summary: "Deadlocks detected in {{ $labels.datname }}"

        - alert: PostgresCacheHitRatioLow
          expr: ccp_stat_database_blks_hit / (ccp_stat_database_blks_hit + ccp_stat_database_blks_read) < 0.95
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Cache hit ratio below 95% for {{ $labels.datname }}"

        - alert: PgBackRestStaleBackup
          expr: time() - ccp_backrest_last_full_backup_time_since_completion_seconds > 604800
          for: 1h
          labels:
            severity: critical
          annotations:
            summary: "No full backup in the last 7 days"

AWS EKS ਤੈਨਾਤੀ

AWS EKS 'ਤੇ PGO ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਨਿਰੰਤਰ ਵਾਲੀਅਮ ਲਈ EBS CSI ਡਰਾਈਵਰ ਅਤੇ S3 ਬੈਕਅੱਪ ਪਹੁੰਚ ਲਈ ਸੇਵਾ ਖਾਤਿਆਂ ਲਈ IAM ਰੋਲ (IRSA) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ Kubernetes ਭੇਦ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਦੇ AWS ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚਦੀ ਹੈ।

# Install the EBS CSI driver (required for gp3 volumes)
eksctl create addon --name aws-ebs-csi-driver --cluster my-cluster --region eu-west-1 \
  --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole

# Create a gp3 StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-csi
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

# IAM policy for pgBackRest S3 access
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mycompany-pg-backups",
        "arn:aws:s3:::mycompany-pg-backups/*"
      ]
    }
  ]
}

# Create an IRSA-enabled service account
eksctl create iamserviceaccount \
  --name pgbackrest-sa \
  --namespace databases \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::111122223333:policy/PGBackRestS3Policy \
  --approve

PostgresClusterਸਪੇਕ ਵਿੱਚ, S3 ਬਾਲਟੀ ਅਤੇ ਖੇਤਰ ਦਾ ਹਵਾਲਾ ਦਿਓ। ਪੀਜੀਓ ਪੋਡ ਦੇ ਸੇਵਾ ਖਾਤੇ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ (IRSA ਰਾਹੀਂ) ਆਪਣੇ ਆਪ ਹੀ ਵਰਤੇਗਾ — ਕਿਸੇ ਸਪੱਸ਼ਟ ਪਹੁੰਚ ਕੁੰਜੀਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

backups:
  pgbackrest:
    repos:
      - name: repo1
        s3:
          bucket: mycompany-pg-backups
          endpoint: s3.eu-west-1.amazonaws.com
          region: eu-west-1

ਮਲਟੀ-AZ ਲਚਕਤਾ ਲਈ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ EKS ਨੋਡ ਸਮੂਹ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ PostgreSQL ਪੌਡਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਪਹਿਲਾਂ ਦਿਖਾਈਆਂ ਗਈਆਂ ਟੌਪੋਲੋਜੀ ਫੈਲਾਅ ਪਾਬੰਦੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।

Azure AKS ਤੈਨਾਤੀ

Azure AKS ਨਿਰੰਤਰ ਸਟੋਰੇਜ ਲਈ ਪ੍ਰਬੰਧਿਤ ਡਿਸਕਾਂ ਅਤੇ pgBackRest ਬੈਕਅੱਪ ਲਈ Azure ਬਲੌਬ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਸਟੋਰੇਜ ਕਲਾਸ ਡਾਟਾਬੇਸ ਵਰਕਲੋਡ ਲਈ ਪ੍ਰੀਮੀਅਮ SSD v2 ਜਾਂ ਪ੍ਰੀਮੀਅਮ LRS ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।

# StorageClass for Azure Premium SSD
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-premium-ssd
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  kind: Managed
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# pgBackRest with Azure Blob Storage
backups:
  pgbackrest:
    configuration:
      - secret:
          name: pgbackrest-azure-creds
    global:
      repo1-azure-account: mystorageaccount
      repo1-retention-full: "7"
    repos:
      - name: repo1
        schedules:
          full: "0 2 * * 0"
          differential: "0 2 * * 1-6"
        azure:
          container: pg-backups

---
# Secret with Azure credentials
apiVersion: v1
kind: Secret
metadata:
  name: pgbackrest-azure-creds
  namespace: databases
stringData:
  azure.conf: |
    [global]
    repo1-azure-key=BASE64_STORAGE_ACCOUNT_KEY

ਵਰਕਲੋਡ ਪਛਾਣ ਲਈ (Azure AWS IRSA ਦੇ ਬਰਾਬਰ), AKS ਕਲੱਸਟਰ ਨੂੰ OIDC ਜਾਰੀਕਰਤਾ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰੋ ਅਤੇ pgBackRest ਸੇਵਾ ਖਾਤੇ ਲਈ ਇੱਕ ਸੰਘੀ ਪਛਾਣ ਪ੍ਰਮਾਣ ਪੱਤਰ ਬਣਾਓ। ਇਹ ਗੁਪਤ ਵਿੱਚ ਸਟੋਰੇਜ ਖਾਤਾ ਕੁੰਜੀਆਂ ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।

GCP GKE ਤੈਨਾਤੀ

GKE ਸਟੋਰੇਜ ਲਈ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ (pd-ssd) ਅਤੇ pgBackRest ਬੈਕਅੱਪ ਲਈ GCS ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। GKE ਵਰਕਲੋਡ ਆਈਡੈਂਟਿਟੀ ਸੁਰੱਖਿਅਤ, ਕੁੰਜੀ ਰਹਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ Kubernetes ਸੇਵਾ ਖਾਤਿਆਂ ਨੂੰ Google ਕਲਾਉਡ ਸੇਵਾ ਖਾਤਿਆਂ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ।

# StorageClass for GKE SSD Persistent Disk
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-ssd
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# pgBackRest with GCS
backups:
  pgbackrest:
    configuration:
      - secret:
          name: pgbackrest-gcs-creds
    repos:
      - name: repo1
        gcs:
          bucket: mycompany-pg-backups

---
# GCS service account key secret
apiVersion: v1
kind: Secret
metadata:
  name: pgbackrest-gcs-creds
  namespace: databases
stringData:
  gcs-key.json: |
    {
      "type": "service_account",
      "project_id": "my-project",
      ...
    }

# Enable Workload Identity on GKE
gcloud container clusters update my-cluster \
  --workload-pool=my-project.svc.id.goog

# Create and bind IAM service account
gcloud iam service-accounts create pgbackrest-gcs \
  --display-name="pgBackRest GCS Access"

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:pgbackrest-gcs@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts add-iam-policy-binding \
  pgbackrest-gcs@my-project.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:my-project.svc.id.goog[databases/production-db-pgbackrest]"

ਮਲਟੀ-ਰੀਜਨ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ

PGO ਅੰਤਰ-ਖੇਤਰ ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਪ੍ਰਾਇਮਰੀ ਕਲੱਸਟਰ ਦੇ pgBackRest ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ WAL ਨੂੰ ਲਗਾਤਾਰ ਰੀਪਲੇਅ ਕਰਦਾ ਹੈ, ਇੱਕ ਨਿੱਘੀ ਕਾਪੀ ਬਣਾਈ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਖੇਤਰੀ ਅਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਅੱਗੇ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

# Standby cluster in Region B
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: production-db-standby
  namespace: databases
spec:
  postgresVersion: 16
  image: registry.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.6-1

  standby:
    enabled: true
    repoName: repo1

  instances:
    - name: pgha1
      replicas: 2
      dataVolumeClaimSpec:
        storageClassName: gp3-csi
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi

  backups:
    pgbackrest:
      image: registry.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.54.1-0
      configuration:
        - secret:
            name: pgbackrest-s3-creds
      repos:
        - name: repo1
          s3:
            bucket: mycompany-pg-backups
            endpoint: s3.us-east-1.amazonaws.com
            region: us-east-1

ਕਿਸੇ ਆਫ਼ਤ ਦੇ ਦੌਰਾਨ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨ ਲਈ,standby.enabled: falseਨੂੰ ਸਪੈਕਸ ਵਿੱਚ ਸੈੱਟ ਕਰੋ ਅਤੇ ਤਬਦੀਲੀ ਨੂੰ ਲਾਗੂ ਕਰੋ। PGO ਸਟੈਂਡਬਾਏ ਨੂੰ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਾਇਮਰੀ ਕਲੱਸਟਰ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਪ੍ਰੋਮੋਸ਼ਨ ਅਟੱਲ ਹੈ — ਤੁਹਾਨੂੰ ਮੂਲ ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਦੇ ਠੀਕ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਕ੍ਰੈਚ ਤੋਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਬੰਧਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

ਬੇਅਰ ਮੈਟਲ k3s/Rancher ਤੈਨਾਤੀ

ਰੈਂਚਰ ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ ਬੇਅਰ ਮੈਟਲ k3s 'ਤੇ PGO ਚਲਾਉਣ ਲਈ ਸਟੋਰੇਜ ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਲਾਊਡ-ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਡਿਸਕਾਂ ਜਾਂ ਲੋਡ ਬੈਲੈਂਸਰ ਨਹੀਂ ਹਨ।

ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ

Longhorn Kubernetes ਲਈ ਇੱਕ ਹਲਕਾ, ਵੰਡਿਆ ਬਲਾਕ ਸਟੋਰੇਜ ਸਿਸਟਮ ਹੈ ਜੋ ਕਿ ਬੇਅਰ ਮੈਟਲ ਵਾਤਾਵਰਨ ਲਈ ਆਦਰਸ਼ ਹੈ। ਇਹ ਟਿਕਾਊਤਾ ਲਈ ਮਲਟੀਪਲ ਨੋਡਾਂ ਵਿੱਚ ਵੌਲਯੂਮ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ ਅਤੇ ਸਨੈਪਸ਼ਾਟ, ਬੈਕਅੱਪ ਅਤੇ ਵਾਲੀਅਮ ਵਿਸਥਾਰ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

# Install Longhorn via Helm
helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.storageOverProvisioningPercentage=100 \
  --set defaultSettings.storageMinimalAvailablePercentage=15

---
# Longhorn StorageClass for PostgreSQL
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-pg
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: best-effort
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

MetalLB

# Install MetalLB
helm repo add metallb https://metallb.github.io/metallb
helm install metallb metallb/metallb --namespace metallb-system --create-namespace

---
# Configure IP address pool
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pg-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.200-192.168.1.210
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: pg-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - pg-pool

MetalLB ਕੌਂਫਿਗਰ ਕੀਤੇ ਜਾਣ ਦੇ ਨਾਲ,LoadBalancerਕਿਸਮ ਦੀਆਂ PGO ਦੀਆਂ ਸੇਵਾਵਾਂ ਤੁਹਾਡੇ ਪੂਲ ਤੋਂ IP ਐਡਰੈੱਸ ਪ੍ਰਾਪਤ ਕਰਨਗੀਆਂ, PostgreSQL ਪ੍ਰਾਇਮਰੀ ਅਤੇ PgBouncer ਐਂਡਪੁਆਇੰਟਸ ਨੂੰ ਮੈਨੂਅਲ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਬਿਨਾਂ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਤੋਂ ਸਿੱਧੇ ਪਹੁੰਚਯੋਗ ਬਣਾਵੇਗੀ।

pgBackRest

# For environments without S3/GCS/Azure Blob, use a PVC-based repo
backups:
  pgbackrest:
    repos:
      - name: repo1
        schedules:
          full: "0 2 * * 0"
          differential: "0 2 * * 1-6"
        volume:
          volumeClaimSpec:
            storageClassName: longhorn-pg
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 200Gi

ਏਅਰ-ਗੈਪਡ ਵਾਤਾਵਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਸੈਕੰਡਰੀ pgBackRest ਰਿਪੋਜ਼ਟਰੀ ਵੀ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਇੱਕ NFS ਸ਼ੇਅਰ ਜਾਂ ਇੱਕ MinIO ਉਦਾਹਰਨ ਲਈ ਬੈਕਅੱਪ ਭੇਜਦਾ ਹੈ, ਜੋ ਕਿ ਕਲਾਉਡ ਨਿਰਭਰਤਾ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਆਫ-ਕਲੱਸਟਰ ਬੈਕਅੱਪ ਕਾਪੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

TLS/SSL ਇਨਕ੍ਰਿਪਸ਼ਨ ਸੰਰਚਨਾ

PGO ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਾਰੇ ਅੰਦਰੂਨੀ ਸੰਚਾਰ ਲਈ ਸਵੈ-ਹਸਤਾਖਰਿਤ TLS ਪ੍ਰਮਾਣ-ਪੱਤਰ ਤਿਆਰ ਕਰਦਾ ਹੈ — PostgreSQL ਉਦਾਹਰਨਾਂ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, pgBackRest, ਅਤੇ PgBouncer ਸਾਰੇ ਬਿਨਾਂ ਕਿਸੇ ਦਸਤੀ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਬੰਧਨ ਦੇ ਐਨਕ੍ਰਿਪਟਡ ਚੈਨਲਾਂ 'ਤੇ ਸੰਚਾਰ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਲਈ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੀ ਸੰਸਥਾ ਦੇ CA ਦੁਆਰਾ ਦਸਤਖਤ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

# Create a TLS secret with your CA-signed certificates
kubectl create secret tls production-db-tls \
  --cert=server.crt \
  --key=server.key \
  -n databases

kubectl create secret generic production-db-ca \
  --from-file=ca.crt=ca.crt \
  -n databases

---
# Reference in PostgresCluster spec
spec:
  customTLSSecret:
    name: production-db-tls
  customReplicationTLSSecret:
    name: production-db-replication-tls

PGO PostgreSQL ਨੂੰssl = onਨਾਲ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਢੁਕਵੇਂssl_cert_file,ssl_key_file, ਅਤੇssl_ca_fileਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ। PgBouncer ਨੂੰ ਇਸੇ ਤਰ੍ਹਾਂ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨਾਂ ਲਈ TLS ਦੀ ਲੋੜ ਲਈ ਅਤੇ PostgreSQL ਬੈਕਐਂਡ ਨਾਲ ਕਨੈਕਟ ਕਰਨ ਵੇਲੇ TLS ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

# Enforce TLS for all client connections via pg_hba.conf
spec:
  patroni:
    dynamicConfiguration:
      postgresql:
        pg_hba:
          - hostssl all all 0.0.0.0/0 scram-sha-256
          - hostssl replication all 0.0.0.0/0 scram-sha-256

ਕਸਟਮ PostgreSQL ਸੰਰਚਨਾ

PGO ਪੈਟਰੋਨੀ ਡਾਇਨਾਮਿਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸੈਕਸ਼ਨ ਦੁਆਰਾ PostgreSQL ਸੰਰਚਨਾ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਇਹ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਪਹੁੰਚ ਹੈ ਕਿਉਂਕਿ ਪੈਟਰੋਨੀ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਇਕਸਾਰ ਸੰਰਚਨਾ ਬਣਾਈ ਰੱਖਣ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਮੁੜ-ਚਾਲੂ ਹੋਣ ਨੂੰ ਸੰਭਾਲਦੀਆਂ ਹਨ।

patroni:
  dynamicConfiguration:
    postgresql:
      parameters:
        # Memory
        shared_buffers: 4GB
        effective_cache_size: 12GB
        work_mem: 64MB
        maintenance_work_mem: 1GB
        huge_pages: "try"

        # WAL
        wal_buffers: 128MB
        min_wal_size: 2GB
        max_wal_size: 8GB
        checkpoint_completion_target: 0.9
        wal_compression: lz4

        # Query Planning
        random_page_cost: 1.1
        effective_io_concurrency: 200
        default_statistics_target: 200

        # Parallelism
        max_worker_processes: 16
        max_parallel_workers_per_gather: 4
        max_parallel_workers: 8
        max_parallel_maintenance_workers: 4

        # Connections
        max_connections: 200
        idle_in_transaction_session_timeout: 60000
        statement_timeout: 300000

        # Logging
        log_min_duration_statement: 250
        log_checkpoints: "on"
        log_connections: "on"
        log_disconnections: "on"
        log_lock_waits: "on"
        log_temp_files: 0
        log_autovacuum_min_duration: 0

        # Autovacuum Tuning
        autovacuum_max_workers: 5
        autovacuum_naptime: 30
        autovacuum_vacuum_cost_limit: 800
        autovacuum_vacuum_scale_factor: 0.02
        autovacuum_analyze_scale_factor: 0.01

ਇਹ ਪੈਰਾਮੀਟਰ PostgreSQL ਨੂੰ ਸਮਰਪਿਤ 16 CPU ਕੋਰ ਅਤੇ 32 GB RAM ਦੇ ਨਾਲ ਇੱਕ ਨੋਡ ਮੰਨਦੇ ਹਨ।shared_buffersਨੂੰ ਉਪਲਬਧ ਰੈਮ ਦੇ ਲਗਭਗ 25% ਅਤੇeffective_cache_sizeਨੂੰ ਲਗਭਗ 75% ਵਿੱਚ ਵਿਵਸਥਿਤ ਕਰੋ। WAL ਅਤੇ ਚੈੱਕਪੁਆਇੰਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਲਿਖਣ-ਭਾਰੀ ਵਰਕਲੋਡ ਲਈ ਟਿਊਨ ਕੀਤਾ ਗਿਆ ਹੈ — ਰੀਡ-ਹੈਵੀ ਸਿਸਟਮਾਂ ਲਈmax_wal_sizeਨੂੰ ਘਟਾਓ ਜਿੱਥੇ ਚੈੱਕਪੁਆਇੰਟ ਬਾਰੰਬਾਰਤਾ ਘੱਟ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।

ਉਪਭੋਗਤਾ ਅਤੇ ਡਾਟਾਬੇਸ ਪ੍ਰਬੰਧਨ

PGOPostgresClusterਸਪੇਕ ਦੇusersਭਾਗ ਦੁਆਰਾ PostgreSQL ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਘੋਸ਼ਣਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਉਪਭੋਗਤਾ ਨੂੰ ਜੋੜਦੇ ਹੋ, ਤਾਂ PGO PostgreSQL ਵਿੱਚ ਭੂਮਿਕਾ ਬਣਾਉਂਦਾ ਹੈ, ਇੱਕ ਬੇਤਰਤੀਬ ਪਾਸਵਰਡ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ Kubernetes ਸੀਕਰੇਟ ਵਿੱਚ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ।

users:
  - name: appuser
    databases: ["appdb"]
    options: "NOSUPERUSER NOCREATEDB NOCREATEROLE"
  - name: readonly
    databases: ["appdb"]
    options: "NOSUPERUSER NOCREATEDB NOCREATEROLE"
  - name: migrations
    databases: ["appdb"]
    options: "NOSUPERUSER CREATEDB"
  - name: monitoring
    databases: ["postgres"]
    options: "NOSUPERUSER LOGIN"

---
# Access credentials from the generated secret
kubectl get secret production-db-pguser-appuser -n databases -o jsonpath='{.data.password}' | base64 -d

# The secret also contains a full connection URI
kubectl get secret production-db-pguser-appuser -n databases -o jsonpath='{.data.uri}' | base64 -d
# postgresql://appuser:PASSWORD@production-db-primary.databases.svc:5432/appdb

ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਪਹੁੰਚ ਦੇਣ ਲਈ, ਕਲੱਸਟਰ ਬਣਾਉਣ 'ਤੇ SQL ਨੂੰ ਚਲਾਉਣ ਲਈdatabaseInitSQLਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਰੋਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਾਰੀਆਂ ਟੇਬਲਾਂ 'ਤੇ SELECT ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

# init.sql ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: init-sql-configmap
  namespace: databases
data:
  init.sql: |
    -- Read-only role for reporting users
    ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly;
    GRANT CONNECT ON DATABASE appdb TO readonly;
    GRANT USAGE ON SCHEMA public TO readonly;
    GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

    -- Extensions
    CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
    CREATE EXTENSION IF NOT EXISTS pgcrypto;
    CREATE EXTENSION IF NOT EXISTS pg_trgm;

ਰੋਲਿੰਗ ਅੱਪਡੇਟ ਅਤੇ ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗ੍ਰੇਡ

PGO ਰੋਲਿੰਗ ਅੱਪਡੇਟਾਂ ਰਾਹੀਂ ਮਾਮੂਲੀ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂPostgresClusterਸਪੇਕ ਵਿੱਚ ਚਿੱਤਰ ਟੈਗ ਨੂੰ ਇੱਕ ਨਵੇਂ ਪੈਚ ਰੀਲੀਜ਼ ਵਿੱਚ ਬਦਲਦੇ ਹੋ, ਤਾਂ PGO ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਵਾਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਾਇਮਰੀ (ਜੋ ਕਿ ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਇੱਕ ਪੈਟਰੋਨੀ ਸਵਿਚਓਵਰ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ) ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।

# Minor version upgrade: change the image tag
spec:
  image: registry.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.7-0

ਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡਾਂ (ਉਦਾਹਰਨ ਲਈ, PostgreSQL 15 ਤੋਂ 16) ਲਈpg_upgradeਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ PGO ਇੱਕ ਵੱਖਰੇPGUpgradeCRD ਦੁਆਰਾ ਆਰਕੈਸਟ੍ਰੇਟ ਕਰਦਾ ਹੈ।

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PGUpgrade
metadata:
  name: production-db-upgrade
  namespace: databases
spec:
  postgresClusterName: production-db
  fromPostgresVersion: 15
  toPostgresVersion: 16
  image: registry.crunchydata.com/crunchydata/crunchy-upgrade:ubi8-5.7.2-0

ਅੱਪਗਰੇਡ ਪ੍ਰਕਿਰਿਆ ਮੌਜੂਦਾ ਕਲੱਸਟਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ, ਹਾਰਡ ਲਿੰਕਾਂ (ਡਾਟਾ ਕਾਪੀ ਕਰਨ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਇਨ-ਪਲੇਸ ਅੱਪਗਰੇਡ ਕਰਨ ਲਈpg_upgrade --linkਨੂੰ ਚਲਾਉਂਦੀ ਹੈ, ਅੱਪਗ੍ਰੇਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਸੰਸਕਰਣ 'ਤੇ ਕਲੱਸਟਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ। ਇੱਕ ਪ੍ਰਮੁੱਖ ਸੰਸਕਰਣ ਅੱਪਗਰੇਡ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾਂ ਇੱਕ ਪੂਰਾ ਬੈਕਅੱਪ ਲਓ ਅਤੇ ਪਹਿਲਾਂ ਇੱਕ ਗੈਰ-ਉਤਪਾਦਨ ਕਲੱਸਟਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਦੀ ਜਾਂਚ ਕਰੋ।

# Pre-upgrade checklist
# 1. Take a full backup
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/pgbackrest-backup="$(date +%s)" \
  --overwrite

# 2. Verify backup completed
kubectl exec -it production-db-pgha1-0 -n databases -- pgbackrest info --stanza=db

# 3. Shutdown the cluster (set replicas to 0 or use PGO shutdown annotation)
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/shutdown="$(date +%s)" \
  --overwrite

# 4. Apply the PGUpgrade resource
kubectl apply -f pg-upgrade.yaml

# 5. Update the PostgresCluster spec with the new version and image
# 6. Remove the shutdown annotation to start the upgraded cluster

ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ ਸਿਫ਼ਾਰਿਸ਼ਾਂ

ਉਤਪਾਦਨ ਵਿੱਚ ਚੱਲ ਰਹੇ PGO ਲਈ ਸ਼ੁਰੂਆਤੀ ਤੈਨਾਤੀ ਤੋਂ ਪਰੇ ਕਈ ਕਾਰਜਸ਼ੀਲ ਖੇਤਰਾਂ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।

ਸਟੋਰੇਜ ਪ੍ਰਦਰਸ਼ਨ

• ਵੱਖਰਾ ਡਾਟਾ ਅਤੇ WAL ਵਾਲੀਅਮ: ਇੱਕ ਸਮਰਪਿਤ PVC 'ਤੇ WAL ਨੂੰ ਰੱਖਣ ਲਈ ਹਮੇਸ਼ਾwalVolumeClaimSpecਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ WAL ਦੀ ਭਾਰੀ ਗਤੀਵਿਧੀ ਨੂੰ ਡਾਟਾ I/O ਨਾਲ ਵਿਵਾਦ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
• ਉੱਚ-IOPS ਸਟੋਰੇਜ: gp3 (AWS), ਪ੍ਰੀਮੀਅਮ SSD v2 (Azure), pd-ssd (GCP), ਜਾਂ ਨੰਗੀ ਧਾਤ 'ਤੇ NVMe-ਬੈਕਡ ਲੋਂਗਹੋਰਨ ਦੀ ਵਰਤੋਂ ਕਰੋ। PostgreSQL ਦੇ ਬੇਤਰਤੀਬੇ I/O ਪੈਟਰਨ ਘੱਟ-ਲੇਟੈਂਸੀ ਸਟੋਰੇਜ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ।
• ਵਾਲੀਅਮ ਵਿਸਥਾਰ: ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਸਟੋਰੇਜ ਕਲਾਸ ਵਿੱਚallowVolumeExpansion: trueਹੈ। PGO ਸਮਰਥਿਤ ਸਟੋਰੇਜ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ PVCs ਨੂੰ ਗੈਰ-ਵਿਘਨਕਾਰੀ ਢੰਗ ਨਾਲ ਵਧਾ ਸਕਦਾ ਹੈ।

ਪੌਡ ਵਿਘਨ ਬਜਟ

PGO ਤੁਹਾਡੇ PostgreSQL ਮੌਕਿਆਂ ਲਈ ਆਪਣੇ ਆਪ PDB ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਤੁਹਾਡੀਆਂ HA ਲੋੜਾਂ ਲਈ ਢੁਕਵੇਂ ਹਨ।

# Check PDBs
kubectl get pdb -n databases
NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
production-db-pgha1     1               N/A               2                     7d

ਸਰੋਤ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ

• OOM ਕਿੱਲਾਂ ਨੂੰ ਰੋਕਣ ਅਤੇ ਗਾਰੰਟੀਸ਼ੁਦਾ QoS ਕਲਾਸ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਡੇਟਾਬੇਸ ਪੌਡਾਂ ਲਈ ਸੀਮਾਵਾਂ ਦੇ ਬਰਾਬਰ ਮੈਮੋਰੀ ਬੇਨਤੀਆਂ ਨੂੰ ਸੈੱਟ ਕਰੋ।
• CPU ਬੇਨਤੀਆਂ ਨੂੰ ਕੰਜ਼ਰਵੇਟਿਵ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕਰੋ ਅਤੇ ਵੈਕਿਊਮ ਜਾਂ ਰੱਖ-ਰਖਾਅ ਕਾਰਜਾਂ ਦੌਰਾਨ ਬਰਸਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਉੱਚ ਸੀਮਾਵਾਂ ਨੂੰ ਸੀਮਤ ਕਰੋ।
• pgMonitor ਮੈਟ੍ਰਿਕਸ ਦੁਆਰਾ ਅਸਲ ਵਰਤੋਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਅਤੇ ਤਿਮਾਹੀ ਵਿਵਸਥਿਤ ਕਰੋ।

ਕਨੈਕਸ਼ਨ ਪ੍ਰਬੰਧਨ

• ਹਮੇਸ਼ਾ PgBouncer ਰਾਹੀਂ ਕਨੈਕਟ ਕਰੋ, PostgreSQL ਨਾਲ ਸਿੱਧੇ ਨਹੀਂ।
• PostgreSQL ਵਿੱਚmax_connectionsਨੂੰ ਇੱਕ ਮੁੱਲ ਵਿੱਚ ਸੈੱਟ ਕਰੋ ਜੋ PgBouncer ਦੇ ਪੂਲ ਸਾਈਜ਼ ਅਤੇ ਸਿਸਟਮ ਕਨੈਕਸ਼ਨਾਂ (ਰਿਪਲੀਕੇਸ਼ਨ, ਮਾਨੀਟਰਿੰਗ, ਸੁਪਰਯੂਜ਼ਰ) ਲਈ ਖਾਤਾ ਹੈ।
• ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪੂਲਿੰਗ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸੈਸ਼ਨ ਪੂਲਿੰਗ 'ਤੇ ਸਵਿੱਚ ਕਰੋ ਤਾਂ ਹੀ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਤਿਆਰ ਸਟੇਟਮੈਂਟਾਂ ਜਾਂ ਸੈਸ਼ਨ-ਪੱਧਰ ਦੀ ਸਥਿਤੀ (ਉਦਾਹਰਨ ਲਈ,SETਕਮਾਂਡਾਂ, ਅਸਥਾਈ ਟੇਬਲ) ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।

ਬੈਕਅੱਪ ਪ੍ਰਮਾਣਿਕਤਾ

• ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਬੈਕਅੱਪ ਤੋਂ ਕਲੋਨ ਕਲੱਸਟਰ ਬਣਾ ਕੇ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੇ ਸਮੋਕ ਟੈਸਟ ਚਲਾ ਕੇ ਰੀਸਟੋਰ ਦੀ ਜਾਂਚ ਕਰੋ।
• ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈPgBackRestStaleBackupਚੇਤਾਵਨੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਕਿ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਪੂਰਾ ਹੋ ਰਿਹਾ ਹੈ।
• ਖਾਸ ਟਾਈਮਸਟੈਂਪਾਂ 'ਤੇ ਬਹਾਲ ਕਰਕੇ ਅਤੇ ਡੇਟਾ ਇਕਸਾਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਕੇ PITR ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰੋ।

# Clone cluster for backup validation
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: backup-validation
  namespace: databases
spec:
  postgresVersion: 16
  image: registry.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.6-1
  dataSource:
    postgresCluster:
      clusterName: production-db
      repoName: repo1
      options:
        - --type=time
        - --target="2026-04-12 06:00:00+00"
  instances:
    - name: pgha1
      replicas: 1
      dataVolumeClaimSpec:
        storageClassName: gp3-csi
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi
  backups:
    pgbackrest:
      repos:
        - name: repo1
          volume:
            volumeClaimSpec:
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 50Gi

ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ

# Restrict PostgreSQL traffic to known namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-network-policy
  namespace: databases
spec:
  podSelector:
    matchLabels:
      postgres-operator.crunchydata.com/cluster: production-db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              app-access: database
        - podSelector:
            matchLabels:
              postgres-operator.crunchydata.com/cluster: production-db
      ports:
        - port: 5432
          protocol: TCP
        - port: 9187
          protocol: TCP

ਮਾਨੀਟਰਿੰਗ ਚੈੱਕਲਿਸਟ

• ਰਿਪਲੀਕੇਸ਼ਨ ਲੇਗ: ਜਦੋਂ ਕੋਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 100MB ਜਾਂ 60 ਸਕਿੰਟ ਦੇ ਲੈਗ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ।
• ਕਨੈਕਸ਼ਨ ਸੰਤ੍ਰਿਪਤਾ: ਚੇਤਾਵਨੀ ਜਦੋਂ ਕਿਰਿਆਸ਼ੀਲ ਕਨੈਕਸ਼ਨmax_connectionsਦੇ 80% ਤੋਂ ਵੱਧ ਹੁੰਦੇ ਹਨ।
• ਲੈਣ-ਦੇਣ ਦੀ ਦਰ ਵਿੱਚ ਵਿਗਾੜ: ਤੁਹਾਡੇ TPS ਨੂੰ ਬੇਸਲਾਈਨ ਕਰੋ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵਿਵਹਾਰਾਂ 'ਤੇ ਚੇਤਾਵਨੀ ਦਿਓ।
• ਡਿਸਕ ਵਰਤੋਂ: ਵੌਲਯੂਮ ਐਕਸਪੈਂਸ਼ਨ ਰਨਬੁੱਕਾਂ ਦੇ ਨਾਲ 70% ਅਤੇ 85% ਥ੍ਰੈਸ਼ਹੋਲਡ 'ਤੇ ਚੇਤਾਵਨੀ।
• ਬੈਕਅੱਪ ਤਾਜ਼ਗੀ: ਚੇਤਾਵਨੀ ਜਦੋਂ ਆਖਰੀ ਪੂਰਾ ਬੈਕਅੱਪ ਤੁਹਾਡੀ RPO ਵਿੰਡੋ ਤੋਂ ਪੁਰਾਣਾ ਹੋਵੇ।
• ਲਾਕ ਵਿਵਾਦ: ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੱਖੇ ਲਾਕ (> 30 ਸਕਿੰਟ) 'ਤੇ ਚੇਤਾਵਨੀ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਬੱਗ ਨੂੰ ਦਰਸਾ ਸਕਦੀ ਹੈ।
• ਆਟੋਵੈਕਿਊਮ ਹੈਲਥ: ਚੇਤਾਵਨੀ ਜਦੋਂ ਟੇਬਲਾਂ ਨੂੰ 24 ਘੰਟਿਆਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ ਖਾਲੀ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਰਨਬੁੱਕ

ਇੱਕ ਆਫ਼ਤ ਰਿਕਵਰੀ ਪਲਾਨ ਤਾਂ ਹੀ ਉਪਯੋਗੀ ਹੈ ਜੇਕਰ ਇਸਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਰਨਬੁੱਕ ਆਮ ਅਸਫਲਤਾ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਤੋਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦੀ ਹੈ।

ਸਿੰਗਲ ਪੋਡ ਅਸਫਲਤਾ

Patroni ਅਤੇ Kubernetes ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ ਸੰਭਾਲਦੇ ਹਨ। ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਪੌਡ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੈਟਰੋਨੀ 10-30 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਵਧਾਵਾ ਦਿੰਦਾ ਹੈ। Kubernetes ਅਸਫਲ ਪੌਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਮੁੜ ਜੁੜਦਾ ਹੈ।

ਸਿੰਗਲ ਨੋਡ ਅਸਫਲਤਾ

ਜੇਕਰ ਇੱਕ PostgreSQL ਪੌਡ ਚਲਾ ਰਿਹਾ ਇੱਕ ਨੋਡ ਮਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ Kubernetes ਇੱਕ ਸਿਹਤਮੰਦ ਨੋਡ 'ਤੇ ਪੌਡ ਨੂੰ ਮੁੜ ਤਹਿ ਕਰਦਾ ਹੈ। ਪੋਡ ਆਪਣੇ ਮੌਜੂਦਾ PVC ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ (ਜੇ ਸਟੋਰੇਜ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ) ਜਾਂ ਬੈਕਅੱਪ ਤੋਂ ਰੀਸਟੋਰ ਕਰਦੀ ਹੈ (ਜੇ ਸਥਾਨਕ ਸਟੋਰੇਜ ਵਰਤੀ ਗਈ ਸੀ)। ਪੌਡ-ਐਂਟੀ-ਐਫੀਨਿਟੀ ਨਿਯਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਬਾਕੀ ਮੌਕਿਆਂ 'ਤੇ ਟ੍ਰੈਫਿਕ ਦੀ ਸੇਵਾ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ।

ਸੰਪੂਰਨ ਕਲੱਸਟਰ ਘਾਟਾ

ਜੇਕਰ ਪੂਰਾ Kubernetes ਕਲੱਸਟਰ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਨਵਾਂ ਕਲੱਸਟਰ ਲਗਾਓ, PGO ਸਥਾਪਿਤ ਕਰੋ, ਅਤੇ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹੋਏdataSourceਨਾਲ ਇੱਕ ਨਵਾਂPostgresClusterਬਣਾਓ। PGO ਨਵੀਨਤਮ ਬੈਕਅੱਪ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਉਪਲਬਧ ਬਿੰਦੂ 'ਤੇ WAL ਨੂੰ ਰੀਪਲੇਅ ਕਰਦਾ ਹੈ।

ਖੇਤਰੀ ਫੇਲਓਵਰ

ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਗੁਆਚ ਗਿਆ ਹੈ, ਤਾਂstandby.enabled: falseਸੈੱਟ ਕਰਕੇ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਦਾ ਪ੍ਰਚਾਰ ਕਰੋ। ਨਵੇਂ ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਆਪਣੇ DNS ਜਾਂ ਲੋਡ ਬੈਲੇਂਸਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਅਸਲੀ ਖੇਤਰ ਠੀਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਿਵਰਸ ਵਿੱਚ ਸਟੈਂਡਬਾਏ ਰਿਸ਼ਤੇ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾ ਸਕਦੇ ਹੋ।

# Promote standby cluster
kubectl patch postgrescluster production-db-standby -n databases --type merge \
  -p '{"spec":{"standby":{"enabled":false}}}'

# Verify the cluster is now an independent primary
kubectl exec -it production-db-standby-pgha1-0 -n databases -- patronictl list

ਆਪਰੇਸ਼ਨਲ ਕਮਾਂਡਾਂ ਤਤਕਾਲ ਹਵਾਲਾ

# Cluster status
kubectl get postgrescluster -n databases
kubectl describe postgrescluster production-db -n databases

# Patroni status
kubectl exec -it production-db-pgha1-0 -n databases -- patronictl list
kubectl exec -it production-db-pgha1-0 -n databases -- patronictl history

# Connect to PostgreSQL
kubectl exec -it production-db-pgha1-0 -n databases -- psql -U postgres

# Backup info
kubectl exec -it production-db-pgha1-0 -n databases -- pgbackrest info --stanza=db

# Manual backup
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/pgbackrest-backup="$(date +%s)" --overwrite

# Restart PostgreSQL (rolling)
kubectl annotate postgrescluster production-db -n databases \
  postgres-operator.crunchydata.com/restart="$(date +%s)" --overwrite

# Logs
kubectl logs production-db-pgha1-0 -n databases -c database
kubectl logs production-db-pgha1-0 -n databases -c pgbackrest
kubectl logs production-db-pgha1-0 -n databases -c exporter

# PgBouncer status
kubectl exec -it $(kubectl get pod -l postgres-operator.crunchydata.com/role=pgbouncer -n databases -o name | head -1) -n databases -- psql -U pgbouncer pgbouncer -c "SHOW POOLS;"

# Scale replicas
kubectl patch postgrescluster production-db -n databases --type merge \
  -p '{"spec":{"instances":[{"name":"pgha1","replicas":5}]}}'

ਸਿੱਟਾ

ਕਰੰਚੀ ਡੇਟਾ PGO Kubernetes 'ਤੇ PostgreSQL ਨੂੰ ਇੱਕ ਸੰਚਾਲਨ ਬੋਝ ਤੋਂ ਇੱਕ ਪ੍ਰਬੰਧਨਯੋਗ, ਘੋਸ਼ਣਾਤਮਕ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।PostgresClusterCRD ਸਮੁੱਚੀ ਤੈਨਾਤੀ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ — ਉਦਾਹਰਣਾਂ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਬੈਕਅੱਪ, ਪੂਲਿੰਗ, ਨਿਗਰਾਨੀ, TLS — ਇੱਕ ਸਿੰਗਲ ਸੰਸਕਰਣ-ਨਿਯੰਤਰਿਤ ਸਰੋਤ ਵਿੱਚ। Patroni ਲੜਾਈ-ਟੈਸਟ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। pgBackRest ਕਿਸੇ ਵੀ ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰ ਨੂੰ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦੇ ਨਾਲ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਬੈਕਅੱਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। PgBouncer ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿਸਦੀ PostgreSQL ਦੀ ਪ੍ਰਕਿਰਿਆ-ਪ੍ਰਤੀ-ਕੁਨੈਕਸ਼ਨ ਮਾਡਲ ਪੈਮਾਨੇ 'ਤੇ ਮੰਗ ਕਰਦਾ ਹੈ। ਅਤੇ pgMonitor ਸੰਚਾਲਨ ਦ੍ਰਿਸ਼ਟੀ ਲਈ Prometheus ਅਤੇ Grafana ਵਿੱਚ ਲੋੜੀਂਦੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਫੀਡ ਕਰਦਾ ਹੈ।

AWS EKS, Azure AKS, GCP GKE, ਅਤੇ ਬੇਅਰ ਮੈਟਲ k3s ਵਿੱਚ ਤੈਨਾਤੀ ਪੈਟਰਨ ਇੱਕੋ ਕੋਰPostgresClusterਸਪੇਕ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ — ਸਟੋਰੇਜ ਕਲਾਸ, ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ ਲੇਅਰ ਵਿੱਚ ਕੀ ਬਦਲਾਅ ਹੁੰਦੇ ਹਨ। ਇਹ ਇਕਸਾਰਤਾ ਇੱਕ ਓਪਰੇਟਰ-ਆਧਾਰਿਤ ਪਹੁੰਚ ਦਾ ਅਸਲ ਮੁੱਲ ਹੈ: ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਟੂਲ, ਇੱਕ ਸੰਚਾਲਨ ਮਾਡਲ, ਅਤੇ ਰਨਬੁੱਕਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਸਿੱਖਦੀ ਹੈ ਜੋ ਹਰ ਥਾਂ ਕੰਮ ਕਰਦੀ ਹੈ।

ਇੱਕ ਤਿੰਨ-ਇਨਸਟੈਂਸ ਕਲੱਸਟਰ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪੂਲਿੰਗ ਮੋਡ ਵਿੱਚ PgBouncer, ਇੱਕ ਹਫਤਾਵਾਰੀ ਪੂਰਾ ਪਲੱਸ ਰੋਜ਼ਾਨਾ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ, ਅਤੇ ਕੋਰ Prometheus ਚੇਤਾਵਨੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਆਪਣੀ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪਹਿਲੇ ਦਿਨ ਪ੍ਰਮਾਣਿਤ ਕਰੋ — ਉਦੋਂ ਨਹੀਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਵਾਰ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਬਹੁ-ਖੇਤਰ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰਾਂ, ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਉੱਨਤ ਟਿਊਨਿੰਗ ਤੱਕ ਫੈਲਾਓ ਕਿਉਂਕਿ ਤੁਹਾਡੀਆਂ ਉਪਲਬਧਤਾ ਲੋੜਾਂ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਪਰਿਪੱਕਤਾ ਵਧਦੀ ਹੈ। ਆਪਰੇਟਰ ਮਕੈਨਿਕ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ; ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਣਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਲਈ ਸਹੀ ਟਰੇਡਆਫ ਹੋ ਸਕਣ।