کرچی ڈیٹا PGO کے ساتھ PostgreSQL اعلی دستیابی: انٹرپرائز Kubernetes تعیناتی۔

Kubernetes پر پیداوار میں PostgreSQL چلانا ایک مستقل والیوم کے ساتھ اسٹیٹفل سیٹ سے زیادہ کا مطالبہ کرتا ہے۔ آپ کو خودکار فیل اوور، مسلسل بیک اپ اور پوائنٹ ان ٹائم ریکوری، کنکشن پولنگ، TLS انکرپشن، مانیٹرنگ، اور کلاؤڈ فراہم کنندگان اور ننگی دھات میں مستقل طور پر تعینات کرنے کی صلاحیت کی ضرورت ہے۔ کرنچی ڈیٹا PGO (Postgres آپریٹر) v5 یہ سب ایک واحد Kubernetes-مقامی کسٹم وسیلہ کے ذریعے فراہم کرتا ہے —PostgresClusterCRD — جس کی پشت پناہی جنگ کے ٹیسٹ شدہ اجزاء سے ہوتی ہے: اتفاق پر مبنی HA کے لیے Patroni، انٹرپرائز بیک اپ کے لیے pgBackRest، کنکشن پولنگ کے لیے PgBouncer، اور XPR0 کے لیے observable کے لیے۔

یہ گائیڈ PGO کے زیر انتظام PostgreSQL کلسٹر کو ابتدائی تعیناتی سے لے کر AWS EKS، Azure AKS، GCP GKE، اور رینچر کے ساتھ ننگی دھات k3s میں پروڈکشن گریڈ آپریشن تک لے جانے کے لیے درکار ہر چیز کا احاطہ کرتی ہے۔ ہر سیکشن میں ٹھوس YAML، Helm اقدار، اور آپریشنل طریقہ کار شامل ہیں جو آپ اپنے ماحول کے مطابق کر سکتے ہیں۔

کرنچی ڈیٹا PGO v5 آرکیٹیکچر

PGO v5 کرچی Postgres آپریٹر کی مکمل دوبارہ تحریر ہے۔ یہ پچھلے pgcluster/pgreplica/pgpolicy CRDs کو ایک واحدPostgresClusterوسائل سے بدل دیتا ہے جو PostgreSQL تعیناتی کے ہر پہلو کو واضح طور پر بیان کرتا ہے۔ آپریٹر اس وسائل میں ہونے والی تبدیلیوں کو دیکھتا ہے اور مطلوبہ حالت سے ملنے کے لیے بنیادی Kubernetes اشیاء — StatefulSets، سروسز، ConfigMaps، Secrets، Jobs — کو ملاتا ہے۔

فن تعمیر چار ستونوں پر بنایا گیا ہے۔Patroniہر PostgreSQL پوڈ میں ایک سائڈ کار کے طور پر چلتا ہے اور Kubernetes- مقامی تقسیم شدہ اتفاق رائے کا استعمال کرتے ہوئے لیڈر الیکشن، ریپلیکیشن ٹوپولوجی، اور خودکار فیل اوور کا انتظام کرتا ہے۔pgBackRestآبجیکٹ اسٹوریج (S3, GCS, Azure Blob) یا مقامی 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 synchronous replication۔ پوڈ اینٹی ایفینیٹی اصول یہ یقینی بناتا ہے کہ تینوں مثالیں مختلف Kubernetes نوڈس پر اتریں۔

Patroni-based HA اور آٹومیٹک فیل اوور

Patroni HA فریم ورک ہے جو ہر PGO کے زیر انتظام PostgreSQL پوڈ میں سرایت کرتا ہے۔ یہ Kubernetes API کو اپنے تقسیم شدہ کنفیگریشن اسٹور (DCS) کے طور پر استعمال کرتا ہے — کوئی علیحدہ etcd یا ZooKeeper کلسٹر کی ضرورت نہیں ہے۔ پیٹرونی PostgreSQL پرائمری اور نقل کی صحت کی مسلسل نگرانی کرتا ہے۔ جب پرائمری غیر جوابدہ ہو جاتی ہے، پیٹرونی ایک خودکار فیل اوور شروع کرتا ہے: یہ سب سے تازہ ترین نقل کو پرائمری میں فروغ دیتا ہے اور نئے لیڈر کی پیروی کرنے کے لیے بقیہ ریپلیکا کو دوبارہ ترتیب دیتا ہے۔

PGO میں فیل اوور کا عمل اس طرح کام کرتا ہے۔ پیٹرونی ہر پوڈ پر Kubernetes میں ایک لیڈر لاک رکھتا ہے (اینڈ پوائنٹس یا کنفیگ میپ آبجیکٹ کے ذریعے)۔ موجودہ پرائمری کو ایک قابل ترتیب وقفہ پر اس لاک کی تجدید کرنی چاہیے (پہلے سے طے شدہ 10 سیکنڈ TTL، 3 سیکنڈ لوپ انتظار)۔ اگر پرائمری کی تجدید کرنے میں ناکام ہو جاتا ہے — کیونکہ یہ کریش ہو گیا، نوڈ مر گیا، یا نیٹ ورک نے اسے تقسیم کر دیا — ایک نقل جو پرائمری کی WAL پوزیشن کے قریب ہے، لاک کو حاصل کر لے گی اور خود کو فروغ دے گی۔ پورا عمل عام طور پر 10 سے 30 سیکنڈ میں مکمل ہو جاتا ہے۔

سنکرونس ریپلیکیشن موڈ، قدرے زیادہ لکھنے میں تاخیر کی قیمت پر صفر ڈیٹا نقصان (RPO = 0) کی ضمانت دیتا ہے۔ ہم وقت ساز موڈ میں، لین دین کو کلائنٹ کو اس وقت تک تسلیم نہیں کیا جاتا جب تک کہ کم از کم ایک نقل WAL حاصل کرنے کی تصدیق نہ کر دے۔ اگر کوئی ہم وقت ساز نقل دستیاب نہیں ہے تو، Patroni دستیابی کو برقرار رکھنے کے لیے ہم وقت ساز موڈ کو عارضی طور پر غیر فعال کر دیتا ہے — اگر آپ مستقل مزاجی کے لیے دستیابی کو قربان کرنے کو ترجیح دیتے ہیں تو آپ اسے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 سے زیادہ میٹرکس کا احاطہ کرتا ہے، بشمول کنکشن، ریپلیکشن لیگ، لین دین کی شرح، کیش ہٹ ریشو، ٹیبل اور انڈیکس کے اعدادوشمار، WAL جنریشن کی شرح، مواد۔

# 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

PostgreSQL

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 بالٹی اور علاقے کا حوالہ دیں۔ PGO پوڈ کے سروس اکاؤنٹ کی اسناد (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 اسٹوریج کے لیے Persistent Disk (pd-ssd) اور pgBackRest بیک اپ کے لیے GCS استعمال کرتا ہے۔ GKE Workload Identity محفوظ، کیلیس تصدیق کے لیے Kubernetes سروس اکاؤنٹس کو گوگل کلاؤڈ سروس اکاؤنٹس سے نقشہ بناتا ہے۔

# 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کو مخصوص میں سیٹ کریں اور تبدیلی کو لاگو کریں۔ پی جی او اسٹینڈ بائی کو ایک آزاد پرائمری کلسٹر میں فروغ دیتا ہے۔ یہ پروموشن ناقابل واپسی ہے — آپ کو اصلی پرائمری ریجن کے ٹھیک ہو جانے کے بعد دوبارہ سے نقل کے رشتے کو دوبارہ بنانے کی ضرورت ہوگی۔

ننگی دھات k3s/رینچر تعیناتی

رینچر مینجمنٹ کے ساتھ ننگی دھات 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 کے ساتھ مقامی PVC یا NFS برائے ننگی دھات

# 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

یہ پیرامیٹرز 16 CPU cores اور PostgreSQL کے لیے وقف 32 GB RAM کے ساتھ ایک نوڈ فرض کرتے ہیں۔shared_buffersکو تقریباً 25% دستیاب RAM اور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 والیوم: WAL کو ایک مخصوص PVC پر رکھنے کے لیے ہمیشہwalVolumeClaimSpecکا استعمال کریں۔ یہ تحریری بھاری WAL سرگرمی کو ڈیٹا I/O کے ساتھ مقابلہ کرنے سے روکتا ہے۔
• ہائی-IOPS اسٹوریج: gp3 (AWS)، پریمیم SSD v2 (Azure)، pd-ssd (GCP)، یا NVMe کی حمایت یافتہ Longhorn کو ننگی دھات پر استعمال کریں۔ PostgreSQL کے بے ترتیب I/O پیٹرن کم تاخیر والے اسٹوریج کا مطالبہ کرتے ہیں۔
• حجم کی توسیع: یقینی بنائیں کہ آپ کے اسٹوریج کلاس میںallowVolumeExpansion: trueہے۔ PGO معاون اسٹوریج فراہم کنندگان پر PVCs کو غیر خلل اندازی سے بڑھا سکتا ہے۔

Pod Disruption Budges

PGO خود بخود آپ کے PostgreSQL مثالوں کے لیے PDBs بناتا ہے، لیکن تصدیق کریں کہ وہ آپ کے 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 کی درخواستوں کو قدامت پسندانہ طور پر سیٹ کریں اور ویکیوم یا دیکھ بھال کے کاموں کے دوران پھٹنے کی اجازت دینے کے لیے زیادہ حد تک محدود کریں۔
• پی جی مانیٹر میٹرکس کے ذریعے اصل استعمال کی نگرانی کریں اور سہ ماہی ایڈجسٹ کریں۔

کنکشن مینجمنٹ

• ہمیشہ 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اسپیک کا اشتراک کرتے ہیں — اسٹوریج کلاس، بیک اپ ریپوزٹری کنفیگریشن، اور نیٹ ورکنگ پرت میں کیا تبدیلیاں آتی ہیں۔ یہ مستقل مزاجی آپریٹر پر مبنی نقطہ نظر کی اصل قدر ہے: آپ کی ٹیم ایک ٹول، ایک آپریشنل ماڈل، اور رن بکس کا ایک سیٹ سیکھتی ہے جو ہر جگہ کام کرتی ہے۔

تھری انسٹینس کلسٹر کے ساتھ شروع کریں، ٹرانزیکشن پولنگ موڈ میں پی جی باؤنسر، ہفتہ وار فل پلس ڈیلی ڈیفرنشل بیک اپ شیڈول، اور بنیادی Prometheus الرٹس۔ پہلے دن اپنے بیک اپ کی بحالی کے طریقہ کار کی توثیق کریں — اس وقت نہیں جب آپ کو پہلی بار ضرورت ہو۔ آپ کی دستیابی کی ضروریات اور آپریشنل میچورٹی بڑھنے کے ساتھ ملٹی ریجن اسٹینڈ بائی کلسٹرز، سنکرونس ریپلیکیشن، اور ایڈوانس ٹیوننگ تک پھیلائیں۔ آپریٹر میکینکس کو سنبھالتا ہے؛ آپ کی ذمہ داری یہ ہے کہ آپ فن تعمیر کو اچھی طرح سمجھیں تاکہ آپ کے کام کے بوجھ کے لیے صحیح تجارت ہو سکے۔