مستقر کردن و مدیریت کردن AlloyDB Omni در Kubernetes (GKE یا Bring-Your-Own Cluster)

۱. مقدمه

در این codelab، نحوه نصب کردن اپراتور AlloyDB Omni Kubernetes (ارکستراتور محفظه) را در خوشه Google Kubernetes Engine (GKE) Autopilot یا خوشه Kubernetes خودتان یاد می‌گیرید و گردش‌های کار چرخه حیات پایگاه داده سرتاسر و «مسیرهای قطعی کاربر» (CUJ) را مدیریت می‌کنید.

‫AlloyDB Omni نسخه بارگیری‌شدنی AlloyDB است که برای اجرا در هر جایی طراحی شده است—از محیط‌های درمحل گرفته تا Google Cloud یا محاسبات لبه‌ای. با هماهنگ‌کننده محفظه، AlloyDB Omni دسترسی‌پذیری بالا، انتقال خودکار به سیستم پشتیبان، خودبهبودی، نگهداری چرخشی با حداقل زمان ازکارافتادگی، ادغام اتصال، پشتیبان‌گیری خودکار، و بازیابی نقطه‌زمانی را خودکارسازی می‌کند.

انتخاب مسیر محیط

می‌توانید این codelab را بااستفاده از یکی از دو مسیر زیر تکمیل کنید:

  1. مسیر ۱: داشتن «حساب Google Cloud»‏ (GKE Autopilot) — بااستفاده از Google Cloud Shell یا «کنسول Google Cloud»، یک خوشه GKE Autopilot کاملاً مدیریت‌شده را تأمین کنید.
  2. مسیر ۲: «حساب Google Cloud» ندارید (خوشه Kubernetes خودتان را بیاورید) — از خوشه Kubernetes موجود (نسخه ۱.۲۱ یا جدیدتر) با kubectl و helm پیکربندی‌شده در ایستگاه کاری‌تان استفاده کنید. به حساب Google Cloud یا gcloud CLI نیاز نیست.

پیش‌نیازها

  • آشنایی اولیه با مفاهیم Kubernetes (kubectl،‏ Helm،‏ Custom Resource Definitions).
  • برای مسیر ۱ (Google Cloud / ‏ GKE Autopilot):
    • پروژه Google Cloud با صورت‌حساب فعال.
    • دسترسی به Google Cloud Shell یا ایستگاه کاری پیکربندی‌شده با gcloud،‏ kubectl، و helm.
  • برای مسیر ۲ (خوشه Kubernetes خودتان را بیاورید):
    • خوشه Kubernetes با نسخه ۱.۲۱ یا جدیدتر با StorageClass پیش‌فرض برای تدارک PersistentVolume پویا.
    • گره‌های کارگر که هسته لینوکس نسخه ۴.۱۸ و بالاتر را با cgroup v2 فعال (x86-64/AMD64) و حداقل ۸ پردازنده مجازی و ۲۴ گیبی‌بایت RAM قابل‌تخصیص در سراسر خوشه اجرا می‌کنند.
    • ایستگاه کاری پیکربندی‌شده با kubectl و helm به خوشه شما متصل شد.

آنچه خواهید آموخت

  • نحوه تدارک خوشه GKE Autopilot (مسیر ۱) یا اعتبارسنجی خوشه Kubernetes موجود (مسیر ۲).
  • نحوه نصب کردن cert-manager و اپراتور AlloyDB Omni Kubernetes ازطریق Helm.
  • نحوه مستقر کردن AlloyDB Omni تک‌نمونه‌ای DBCluster.
  • نحوه مقیاس‌بندی به «دسترسی بالا» (HA) با آماده‌به‌کارهای همگام و فعال کردن قابلیت آماده‌به‌کار فقط خواندنی.
  • نحوه پیکربندی پشتیبان‌گیری‌های خودکار زمان‌بندی‌شده در فضای ذخیره‌سازی مخزن محلی (و به‌طور اختیاری Google Cloud Storage در مسیر ۱).
  • نحوه انجام پشتیبان‌گیری درخواستی و تأیید بازیابی داده‌ها به حالت قبلی.
  • نحوه انجام «بازیابی نقطه‌ای» (PITR) در خوشه پایگاه داده کلون‌شده جدید.
  • نحوه استقرار ادغام اتصال PgBouncer برای مقیاس‌بندی اتصال مشتری.
  • نحوه استقرار pgAdmin4 برای مدیریت و پرسمان پایگاه داده به‌صورت تصویری.
  • نحوه اجرای «نگهداری با زمان اَکار کم» (LDTM) برای مقیاس‌بندی منابع واحد پردازش مرکزی و حافظه.

آنچه نیاز خواهید داشت

  • مسیر ۱: Google Cloud Shell با ابزارهای کمکی gcloud، kubectl، و helm ازپیش نصب‌شده.
  • مسیر ۲: پایانه‌ای با kubectl و helm متصل به خوشه Kubernetes شما.
  • برای اسناد مرجع، به راهنمای رسمی استقرار AlloyDB Omni مراجعه کنید.

۲. راه‌اندازی و شرایط لازم

اگر از حساب Google Cloud برای ایجاد خوشه GKE Autopilot استفاده می‌کنید، مسیر ۱ را انتخاب کنید، یا اگر از خوشه Kubernetes خودتان بدون حساب Google Cloud استفاده می‌کنید، مسیر ۲ را انتخاب کنید.

مسیر ۱: راه‌اندازی پروژه Google Cloud‏ (GKE Autopilot)

  1. در کنسول Google Cloud، پروژه Google Cloud را انتخاب یا ایجاد کنید.
  2. مطمئن شوید که صورت‌حساب برای پروژه‌تان فعال باشد. با نحوه درستی‌سنجی وضعیت صورت‌حساب آشنا شوید.
  3. با کلیک کردن روی نماد فعال کردن Cloud Shell در گوشه بالا سمت چپ «کنسول Google Cloud» یا با رفتن به shell.cloud.google.com،‏ Google Cloud Shell را باز کنید. Cloud Shell محیط محاسباتی بارشده با gcloud،‏ kubectl، و helm را فراهم می‌کند.
  4. شناسه پروژه‌تان را به‌عنوان متغیر محیطی تنظیم کنید و gcloud را پیکربندی کنید:
export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}
  1. میاناهای برنامه‌سازی کاربردی Google Cloud موردنیاز را برای GKE و Cloud Storage فعال کنید:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

مسیر ۲: راه‌اندازی خوشه Bring-Your-Own (بدون حساب Google Cloud)

اگر حساب Google Cloud ندارید و از خوشه Kubernetes خودتان استفاده می‌کنید، پیش‌از ادامه دادن، پیش‌نیازهای زیر را از پایانه خودتان درستی‌سنجی کنید:

  1. تأیید کنید که kubectl و helm می‌توانند به خوشه‌تان دسترسی داشته باشند و گره‌هایتان Ready هستند:
kubectl get nodes
helm version
  1. درستی‌سنجی کنید که خوشه‌تان StorageClass پیش‌فرض با علامت (default) داشته باشد. مانیفست‌های DBCluster و BackupPlan به‌طور پویا PersistentVolumeClaims را بااستفاده از StorageClass پیش‌فرض خوشه فراهم می‌کنند:
kubectl get storageclass

اگر هیچ StorageClass به‌عنوان (default) علامت‌گذاری نشده است، قبل‌از ادامه دادن، یکی را به‌عنوان پیش‌فرض تعیین کنید:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. تأیید کنید که گره‌های کارگر شما الزامات سخت‌افزاری و سیستم‌عامل اپراتور را برآورده می‌کنند:
    • سیستم‌عامل و هسته: هسته Linux نسخه ۴.۱۸ یا جدیدتر با cgroup v2 فعال‌شده در گره‌های x86-64/AMD64.
    • ظرفیت خوشه: حداقل ۸ واحد پردازش مرکزی مجازی و ۲۴ گیبی‌بایت حافظه قابل‌تخصیص در گره‌های کارگر برای اجرای هم‌زمان نمونه‌های پایگاه داده HA (در مرحله ۱۲ به ۲ واحد پردازش مرکزی مجازی و ۸ گیبی‌بایت برای هرکدام مقیاس‌بندی شده است)، نمونه کلون‌شده PITR،‏ PgBouncer، و pgAdmin4.
    • دسترسی به شبکه: دسترسی به اینترنت برون‌مرزی برای دریافت تصاویر محفظه از gcr.io/alloydb-omni، quay.io/jetstack، و docker.io.

۳. تأمین یا اتصال به خوشه Kubernetes

اگر مسیر ۱ (حساب Google Cloud) را دنبال می‌کنید، GKE Autopilot یک حالت Kubernetes کاملاً مدیریت‌شده و بدون دخالت ارائه می‌دهد که در آن Google زیرساخت خوشه، تأمین گره، و مقیاس‌بندی خودکار را مدیریت می‌کند. می‌توانید خوشه GKE Autopilot خود را بااستفاده از Google Cloud CLI یا «کنسول Google Cloud» ایجاد کنید.

گزینه الف: ایجاد خوشه GKE Autopilot ازطریق CLI (مسیر ۱)

فرمان gcloud زیر را در Cloud Shell اجرا کنید:

gcloud container clusters create-auto ${CLUSTER_NAME} \
    --region=${REGION} \
    --project=${PROJECT_ID}

گزینه ب: ایجاد خوشه GKE Autopilot ازطریق کنسول (مسیر ۱)

  1. Kubernetes Engine را در «کنسول Google Cloud» باز کنید.
  2. در قاب پیمایش سمت راست، روی خوشه‌ها کلیک کنید.
  3. روی ایجاد کردن کلیک کنید.
  4. در بخش GKE Autopilot، روی پیکربندی کلیک کنید.
  5. نام خوشه‌تان را مشخص کنید (برای مثال، omni-autopilot-cluster) و منطقه ترجیحی‌تان را انتخاب کنید (us-central1).
  6. روی ایجاد کردن کلیک کنید.

درستی‌سنجی اتصال‌پذیری خوشه (مسیر ۱ و مسیر ۲)

اگر خوشه GKE Autopilot را در مسیر ۱ ایجاد کرده‌اید، اعتبارنامه kubectl را پیکربندی کنید:

gcloud container clusters get-credentials ${CLUSTER_NAME} --region=${REGION} --project=${PROJECT_ID}

برای مسیر ۱ و مسیر ۲، اتصال‌پذیری به خوشه Kubernetes خود را تأیید کنید:

kubectl get nodes

۴. نصب پیش‌نیازهای اپراتور و اپراتور

اپراتور AlloyDB Omni Kubernetes برای مدیریت گواهینامه‌های TLS وب‌قلاب پذیرش به cert-manager نیاز دارد.

۱. نصب cert-manager

cert-manager را بااستفاده از نمودار Helm رسمی آن نصب کنید:

helm install \
  cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --version v1.21.2 \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true \
  --set global.leaderElection.namespace=cert-manager

تأیید کنید که پادهای cert-manager درحال اجرا هستند:

kubectl wait --namespace cert-manager \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/instance=cert-manager \
  --timeout=120s

۲. نصب AlloyDB Omni Operator

اپراتور AlloyDB Omni Kubernetes را بااستفاده از Helm در فضای نام alloydb-omni-system مستقر کنید:

helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
  --version 1.8.2 \
  --create-namespace \
  --namespace alloydb-omni-system \
  $(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
  --timeout 5m

بررسی کنید که پادهای اپراتور سالم و درحال اجرا باشند:

kubectl get pods -n alloydb-omni-system

۵. ایجاد خوشه پایگاه داده تک‌نمونه‌ای

در این مرحله، یک فضای نام برنامه اختصاصی ایجاد خواهید کرد و یک AlloyDB Omni DBCluster تک‌نمونه‌ای را مستقر خواهید کرد.

۱. ایجاد فضای نام و رمز اعتبارنامه سرپرست

فضای نام omni-demo را برای حجم‌های کاری پایگاه داده ایجاد کنید:

kubectl create namespace omni-demo

یک Kubernetes Secret ایجاد کنید که گذرواژه را برای کاربر سرپرست پایگاه داده پیش‌فرض postgres ذخیره کند:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-adbo
type: Opaque
data:
  adbo: "Q2hhbmdlTWUxMjM=" # Base64 for "ChangeMe123"
EOF

۲. مستقر کردن DBCluster تک‌نمونه‌ای

ایجاد مانیفست DBCluster تک‌نمونه‌ای:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: adbo
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-adbo
    resources:
      cpu: 1
      memory: 4Gi
      disks:
      - name: DataDisk
        size: 10Gi
EOF

۳. درستی‌سنجی آمادگی خوشه

وضعیت خوشه را تا زمانی که DBCLUSTERPHASE به DBClusterReady برسد پایش کنید. تأمین اولیه ممکن است چند دقیقه طول بکشد: اپراتور باید حجم پایدار را ایجاد کند و تصویر پایگاه داده را بکشد، و در GKE Autopilot ممکن است ابتدا لازم باشد گره جدیدی تأمین شود.

kubectl get dbcluster -n omni-demo -w

وقتی DBCLUSTERPHASE به DBClusterReady رسید، Ctrl+C را فشار دهید تا از حالت تماشا خارج شوید.

نمونه برونداد:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

نشانی IP PRIMARYENDPOINT را که ClusterIP مربوط به «سرویس Kubernetes» خواندن-نوشتن al-adbo-rw-ilb است یادداشت کنید. ‫AlloyDB Omni در درگاه پیش‌فرض PostgreSQL 5432 گوش می‌دهد.

منابعی را که اپراتور از مانیفست DBCluster واحد تطبیق داده است بررسی کنید—پاد پایگاه داده، DataDisk PersistentVolumeClaim، و al-adbo-rw-ilb سرویس:

kubectl get pods,svc,pvc -n omni-demo

‫۶. ارتقا به «دسترسی‌پذیری بالا» (HA) و فعال کردن «آماده‌به‌کار فقط خواندنی»

‫AlloyDB Omni با تکرار جاری‌سازی، پایش خودکار سلامت، انتقال خودکار به سیستم پشتیبان، و ارائه نسخه تکراری خواندنی، «دسترسی‌پذیری بالا» (HA) داخلی ارائه می‌دهد.

۱. فعال کردن قابلیت HA و Read Replica

مشخصات DBCluster را به‌روز کنید تا ۱ نمونه آماده‌به‌کار پیکربندی شود و مسیریابی آماده‌به‌کار فقط خواندنی فعال شود:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "availability": {
      "numberOfStandbys": 1,
      "enableStandbyAsReadReplica": true
    }
  }
}'

۲. تأیید پایداری HA

صبر کنید تا نمونه آماده‌به‌کار آماده شود و به تکرار جاری‌سازی سالم برسد (HAREADYSTATUS به True و HAREADYREASON به Ready می‌رسد)، سپس Ctrl+C را فشار دهید تا از حالت تماشا خارج شوید:

kubectl get dbcluster adbo -n omni-demo -w

شرط وضعیت HAReady را بررسی کنید:

kubectl get dbcluster.alloydbomni.dbadmin.goog adbo -n omni-demo -o jsonpath='{.status.conditions[?(@.type == "HAReady")]}'

تأیید کنید که هر دو نقطه پایان خواندن-نوشتن و فقط خواندنی منتشر شده باشند:

kubectl describe dbcluster adbo -n omni-demo | grep -A 8 "Endpoints:"

نمونه برونداد:

Endpoints:
  Name: Read-Write
  Value: 10.128.0.45:5432
  Name: Read-Only
  Value: 10.128.0.46:5432

نقطه پایانی «خواندن-نوشتن» (سرویس al-adbo-rw-ilb) به پایگاه داده اصلی هدایت می‌شود، درحالی‌که نقطه پایانی «فقط خواندنی» (سرویس al-adbo-ro-ilb) پُرسمان‌های خواندن را در نمونه‌های آماده‌به‌کار توزیع می‌کند.

‫۷. پیکربندی BackupPlans خودکارسازی‌شده (محلی و GCS)

AlloyDB Omni پشتیبان‌گیری فیزیکی و بایگانی WAL را ازطریق «منبع سفارشی» BackupPlan ارائه می‌دهد. می‌توانید حفظ پشتیبان‌گیری، زمان‌بندی‌های cron خودکار، و اهداف پشتیبان‌گیری (حجم‌های پایدار محلی یا Google Cloud Storage) را پیکربندی کنید.

۱. ایجاد Local BackupPlan

BackupPlan ایجاد کنید که نسخه‌های پشتیبان را در فضای ذخیره‌سازی محلی Kubernetes متصل به نمونه‌های پایگاه داده بنویسد:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-local
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 2 * * *" # Daily at 02:00 UTC
    incremental: "0 */4 * * *" # Every 4 hours
  backupRetainDays: 7
EOF

تأیید کنید که BackupPlan محلی آماده است:

kubectl get backupplan backupplan-local -n omni-demo

منتظر بمانید تا PHASE گزارش Ready و NEXTBACKUPTIME زمان‌بندی شود.

۲. ایجاد GCS BackupPlan (مسیر ۱: فقط Google Cloud — اختیاری)

برای ذخیره کردن پشتیبان‌گیری‌ها به‌صورت خارجی در مخزن Google Cloud Storage، مخزن GCS ایجاد کنید، کلید محرمانه حساب سرویس را پیکربندی کنید، و BackupPlan ابری را اعمال کنید.

  1. ایجاد مخزن Cloud Storage:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. حساب خدماتی با اجازه‌های «سرپرست شیء فضای ذخیره‌سازی» ایجاد کنید و کلیدی برای آن بسازید:

export SA_NAME="omni-backup-sa"
gcloud iam service-accounts create ${SA_NAME} --display-name="AlloyDB Omni Backup SA"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts keys create /tmp/gcs-key.json \
  --iam-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
  1. رمز را در فضای نام Kubernetes ایجاد کنید:
kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json
  1. مانیفست GCS BackupPlan را اعمال کنید. فیلد key پوشه‌ای در سطل است که اپراتور نسخه‌های پشتیبان را در آن می‌نویسد. باید با / شروع شود.
kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-gcs
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 1 * * *"
    incremental: "0 */6 * * *"
  backupRetainDays: 14
  backupLocation:
    type: GCS
    gcsOptions:
      bucket: ${BUCKET_NAME}
      key: /omni-backups/adbo
      secretRef:
        name: gcs-backup-secret
        namespace: omni-demo
EOF

درستی‌سنجی کردن وضعیت GCS BackupPlan:

kubectl get backupplan backupplan-gcs -n omni-demo

منتظر بمانید تا PHASE گزارش Ready و NEXTBACKUPTIME زمان‌بندی شود.

‫۸. وارد کردن داده، راه‌اندازی پشتیبان‌گیری، و آزمایش بازیابی

در این مرحله، داده‌های اولیه را در پایگاه داده اصلی وارد می‌کنید، پشتیبان‌گیری دستی درخواستی را راه‌اندازی می‌کنید، داده‌های بعدی را اضافه می‌کنید، و از نسخه پشتیبان بازیابی می‌کنید تا بازگشت داده‌ها را اثبات کنید.

۱. پر کردن داده‌های اولیه

یک پاد موقت مشتری PostgreSQL را اجرا کنید تا ازطریق «سرویس» خواندن-نوشتن al-adbo-rw-ilb به‌عنوان کاربر postgres به پایگاه داده متصل شوید:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    CREATE TABLE customers (id SERIAL PRIMARY KEY, name TEXT, created_at TIMESTAMPTZ DEFAULT pg_catalog.now());
    INSERT INTO customers (name) VALUES ('Alpha Co'), ('Beta LLC');
    SELECT * FROM customers;
  "

وقتی از شما خواسته شد گذرواژه را وارد کنید، ChangeMe123 را وارد کنید. این گذرواژه‌ای است که در مرحله ۵ در «رمز» db-pw-adbo با کدبندی ۶۴پایه‌ای کدبندی کردید.

۲. راه‌اندازی «پشتیبان‌گیری درصورت درخواست»

ایجاد منبع سفارشی Backup دستی که به BackupPlan محلی‌تان ارجاع می‌دهد:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: initial-customer-backup
spec:
  dbclusterRef: adbo
  backupPlanRef: backupplan-local
  manual: true
EOF

پیشرفت پشتیبان‌گیری را پایش کنید:

kubectl get backup initial-customer-backup -n omni-demo -w

منتظر بمانید تا PHASE به Succeeded تبدیل شود.

۳. تغییر داده‌ها (افزودن سوابق جدید)

سوابق اضافی را پس‌از پشتیبان‌گیری درج کنید:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Gamma Inc'), ('Delta Corp');
    SELECT * FROM customers;
  "

پایگاه داده اکنون ۴ ردیف دارد.

۴. بازیابی از نسخه پشتیبان

بازیابی را به وضعیت ثبت‌شده در initial-customer-backup راه‌اندازی کنید:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-to-initial
spec:
  sourceDBCluster: adbo
  backup: initial-customer-backup
EOF

عملیات بازیابی را پایش کنید:

kubectl get restore restore-to-initial -n omni-demo -w

صبر کنید تا PHASE به ProvisionSucceeded برسد و بررسی کنید که DBCluster به DBClusterReady برگردد:

kubectl get dbcluster adbo -n omni-demo -w

‫۵. درستی‌سنجی کردن وضعیت داده‌های بازیابی‌شده

جدول customers را پرسمان کنید تا تأیید شود فقط سوابق پیش‌از پشتیبان‌گیری وجود دارد:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

خروجی تأیید می‌کند که فقط ۲ ردیف (Alpha Co و Beta LLC) وجود دارد، که نشان می‌دهد پایگاه داده دقیقاً به حالت پشتیبان‌گیری بازیابی شده است.

‫۹. بازیابی نقطه‌زمانی (PITR) به پایگاه داده کلون‌شده

«بازیابی نقطه‌ای» (PITR) امکان بازیابی پایگاه داده را به هر ثانیه دلخواه در پنجره بازیابی بااستفاده از پشتیبان‌گیری‌های پایه و گزارش‌های جریان WAL فراهم می‌کند و داده‌های بازیابی‌شده را در خوشه پایگاه داده شبیه‌سازی‌شده جدیدی ارائه می‌دهد.

ازآنجایی‌که اپراتور به‌طور مداوم «گزارش پیش‌نویس» (WAL) را بایگانی می‌کند، PITR به شما امکان می‌دهد با شبیه‌سازی پایگاه داده دقیقاً در ثانیه قبل‌از وقوع اشتباه (ساعت ۲:۱۴:۵۹ بعدازظهر)، بدون دست زدن به خوشه اصلی، از خطاهای تصادفی انسانی یا برنامه‌ای (برای مثال، DELETE یا DROP TABLE ناخواسته در ساعت ۲:۱۵:۰۰ بعدازظهر) بازیابی کنید.

۱. ثبت مُهر زمان فعلی و تغییر داده‌ها

مُهر زمان فعلی ساعت هماهنگ جهانی را بازیابی کنید:

export PITR_TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "PITR Target Timestamp: ${PITR_TIMESTAMP}"

یک سابقه آزمایشی وارد کنید که نشان‌دهنده تغییر ناخواسته بعداز این مُهر زمان باشد:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Unwanted Record Post-Timestamp');
    SELECT * FROM customers;
  "

۲. انجام بازیابی نقطه زمانی

اعمال پیکربندی Restore Custom Resource pointInTime و clonedDBClusterConfig:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-pitr-clone
spec:
  sourceDBCluster: adbo
  pointInTime: "${PITR_TIMESTAMP}"
  clonedDBClusterConfig:
    dbclusterName: adbo-cloned
EOF

عملیات بازیابی را تا زمانی که PHASE به ProvisionSucceeded برسد نظارت کنید:

kubectl get restore restore-pitr-clone -n omni-demo -w

۳. درستی‌سنجی کردن پایگاه داده تکثیرشده

پس‌از تکمیل بازیابی، منتظر بمانید تا DBCluster شبیه‌سازی‌شده جدید به DBClusterReady برسد (برای خروج از حالت تماشا، Ctrl+C را فشار دهید):

kubectl get dbcluster adbo-cloned -n omni-demo -w

Query the cloned database adbo-cloned through its read-write Service al-adbo-cloned-rw-ilb:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-cloned-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

توجه داشته باشید که Unwanted Record Post-Timestamp در خوشه کلون‌شده وجود ندارد، که نشان‌دهنده بازیابی دقیق به نقطه هدف دقیق در زمان است.

‫۱۰. استقرار PgBouncer Connection Pooler

ادغام اتصال، سربار حافظه پایگاه داده و تأخیر اتصال را کاهش می‌دهد. اپراتور نمونه‌های PgBouncer را به‌طور بومی ازطریق «منبع سفارشی» PgBouncer مدیریت می‌کند.

PostgreSQL برای هر اتصال کارخواه یک فرایند سیستم‌عامل جداگانه ایجاد می‌کند، بنابراین صدها اتصال هم‌زمان از سرویس‌های وب، ریزسرویس‌ها، یا عامل‌های هوش مصنوعی می‌توانند حافظه پایگاه داده را تمام کنند. PgBouncer در جلوی پایگاه داده قرار می‌گیرد و بسیاری از اتصالات کارخواه کوتاه‌مدت (تا max_client_conn) را روی یک استخر کوچک از اتصالات سرور PostgreSQL بلندمدت (default_pool_size برای هر جفت کاربر/پایگاه داده، با سقف max_db_connections) چندگانه می‌کند.

۱. پیاده‌سازی PgBouncer

استقرار تجمیع‌کننده PgBouncer با ۲ نسخه تکراری پیوندشده به خوشه adbo:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: omni-pgbouncer
spec:
  dbclusterRef: adbo
  allowSuperUserAccess: true
  replicaCount: 2
  parameters:
    pool_mode: transaction
    default_pool_size: "20"
    max_client_conn: "500"
    max_db_connections: "100"
  podSpec:
    resources:
      cpu: 1
      memory: 1Gi
    image: "gcr.io/alloydb-omni/operator/g-pgbouncer:1.4.0"
  serviceOptions:
    type: ClusterIP
EOF

۲. درستی‌سنجی وضعیت PgBouncer

وضعیت PgBouncer را تماشا کنید تا PHASE به Ready تبدیل شود:

kubectl get pgbouncer omni-pgbouncer -n omni-demo -w

پادها و سرویس PgBouncer درحال اجرا را بررسی کنید:

kubectl get pods -n omni-demo
kubectl get svc al-omni-pgbouncer-pgb-svc -n omni-demo

۳. اتصال ازطریق PgBouncer

اتصال کارخواه ازطریق سرویس PgBouncer در درگاه 6432:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-omni-pgbouncer-pgb-svc -p 6432 -U postgres -d postgres -c "
    SELECT pg_catalog.version();
    SELECT * FROM customers;
  "

PgBouncer پُرسمان را به‌طور یکپارچه به پایگاه داده اصلی AlloyDB Omni پروکسی می‌کند.

‫۱۱. استقرار pgAdmin4 برای دسترسی به پایگاه داده

می‌توانید pgAdmin4 را مستقیماً در خوشه Kubernetes اجرا کنید تا کنسول سرپرستی مبتنی بر وب برای پُرسمان، مدیریت، و بازرسی AlloyDB Omni ارائه شود.

۱. نصب pgAdmin4 ازطریق Helm

pgadmin4 را در فضای نام omni-demo نصب کنید:

helm install my-pgadmin oci://docker.io/dpage/pgadmin4-helm \
  --namespace omni-demo \
  --set ingress.enabled=false \
  --set image.tag=latest \
  --set auth.email="admin@example.com" \
  --set auth.password="AdminPassword123"

این نمودار منابع Kubernetes خود را pgadmin4 (استقرار، سرویس، PersistentVolumeClaim) می‌نامد و Pods خود را با app=pgadmin4 برچسب‌گذاری می‌کند، صرف‌نظر از نام انتشار Helm‏ (my-pgadmin).

تأیید کنید که pod مربوط به pgAdmin4 درحال اجرا است:

kubectl wait --namespace omni-demo \
  --for=condition=ready pod \
  --selector=app=pgadmin4 \
  --timeout=300s

۲. بازارسال کردن درگاه و دسترسی به میانای کاربر وب

‫pgAdmin4 را به محیط محلی یا Cloud Shell خود ارجاع درگاهی کنید:

kubectl port-forward service/pgadmin4 5050:80 -n omni-demo

تا زمانی‌که از واسط کاربر وب pgAdmin4 استفاده می‌کنید، kubectl port-forward در پیش‌زمینه اجرا می‌شود. برای فرمان‌های دیگر، پایانه دوم (یا برگه جدید Cloud Shell) را باز کنید و وقتی آماده رفتن به مرحله بعدی بودید، Ctrl+C را در این پایانه فشار دهید.

میانای وب pgAdmin4 را باز کنید:

  • مسیر ۱ (Google Cloud Shell): روی دکمه پیش‌نمایش وب در منو بالا سمت چپ کلیک کنید، تغییر درگاه را انتخاب کنید، 5050 را وارد کنید، و روی تغییر و پیش‌نمایش کلیک کنید.
  • مسیر ۲ (ایستگاه کاری محلی): http://localhost:5050 را در مرورگرتان باز کنید درحالی‌که فرمان kubectl port-forward درحال اجرا است.

ورود به سیستم بااستفاده از:

  • ایمیل: admin@example.com
  • گذرواژه: AdminPassword123

۳. ثبت AlloyDB Omni در pgAdmin4

  1. در pgAdmin4، روی سرورها > ثبت > سرور... کلیک راست کنید.
  2. در برگه موارد کلی:
    • نام: AlloyDB Omni Primary
  3. در برگه اتصال:
    • نام/نشانی میزبان: al-adbo-rw-ilb.omni-demo.svc.cluster.local (یا al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local برای PgBouncer)
    • درگاه: 5432 (یا 6432 برای PgBouncer)
    • پایگاه داده نگهداری: postgres
    • نام کاربری: postgres
    • گذرواژه: ChangeMe123
  4. روی ذخیره کلیک کنید و جلسه و جدول‌های پایگاه داده فعال را درستی‌سنجی کنید.

‫۱۲. مقیاس‌بندی واحد پردازش مرکزی و حافظه با «نگهداری با زمان خرابی کم» (LDTM)

هنگام مقیاس‌بندی عمودی محاسبات و حافظه در پایگاه داده تولید، به‌روزرسانی‌های سنتی باعث اختلال در بازراه‌اندازی پایگاه داده می‌شوند. AlloyDB Omni نگهداری با زمان خرابی کم (LDTM) را برای اعمال به‌روزرسانی‌ها ازطریق نسخه‌های کپی با حداقل اختلال در برنامه ارائه می‌دهد.

۱. فعال کردن حاشیه‌نویسی LDTM

DBCluster را حاشیه‌نویسی کنید تا LDTM برای به‌روزرسانی‌ها فعال شود:

kubectl annotate dbclusters.alloydbomni.dbadmin.goog adbo -n omni-demo dbcluster.dbadmin.goog/enableLDTM=true --overwrite

۲. مقیاس‌بندی منابع واحد پردازش مرکزی و حافظه

به‌روزرسانی منابع اصلی از cpu: 1, memory: 4Gi به cpu: 2, memory: 8Gi:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "primarySpec": {
      "resources": {
        "cpu": 2,
        "memory": "8Gi"
      }
    }
  }
}'

۳. پایش پیشرفت مقیاس‌بندی LDTM

به‌روزرسانی تدریجی و شرایط جابه‌جایی از حالت آماده‌به‌کار به حالت اصلی را پایش کنید:

kubectl get dbcluster adbo -n omni-demo -o yaml | grep -A 5 -B 2 "LDTMScalingInProgress"

غلاف‌ها را که به‌آرامی می‌چرخند مشاهده کنید:

kubectl get pods -n omni-demo -w

LDTM ابتدا آماده‌به‌کار به‌روزشده را آماده می‌کند، تکرار جاری‌سازی را تأیید می‌کند، یک جابه‌جایی سریع را اجرا می‌کند، و نمونه باقی‌مانده را بدون وقفه در سرویس به‌روز می‌کند.

تأیید تخصیص منابع به‌روزشده:

kubectl get dbcluster adbo -n omni-demo -o jsonpath='{.spec.primarySpec.resources}'

‫۱۳. پاک‌سازی منابع

برای آزاد کردن ظرفیت خوشه و جلوگیری از کسر هزینه‌های غیرضروری از حساب Google Cloud، منابعی را که درطول این codelab فراهم شده است پاک کنید.

اگر پاک‌سازی را در جلسه پایانه جدیدی (مسیر ۱) اجرا می‌کنید، متغیرهای محیطی مراحل قبلی دیگر تنظیم نمی‌شوند. آن‌ها را با همان مقادیری که قبلاً استفاده کرده‌اید دوباره صادر کنید:

export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
export SA_NAME="omni-backup-sa"
gcloud config set project ${PROJECT_ID}

۱. حذف بارهای کاری پایگاه داده (مسیر ۱ و مسیر ۲)

هر دو خوشه را به‌عنوان حذف‌شده علامت‌گذاری کنید تا بررسی‌های وب‌قلاب پذیرش را بگذرانند، منتظر بمانید تا اپراتور منابع DBCluster را بردارد، و سپس فضای نام را حذف کنید:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl patch dbcluster adbo-cloned -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl wait --for=delete dbcluster/adbo dbcluster/adbo-cloned -n omni-demo --timeout=300s
kubectl delete namespace omni-demo

اگر از خوشه Kubernetes خودتان (مسیر ۲) استفاده کرده‌اید و می‌خواهید اپراتور AlloyDB Omni و cert-manager را نیز بردارید:

helm uninstall alloydbomni-operator -n alloydb-omni-system
kubectl delete namespace alloydb-omni-system
helm uninstall cert-manager -n cert-manager
kubectl delete namespace cert-manager

۲. حذف کردن GCS Bucket و حساب سرویس IAM (فقط مسیر ۱)

اگر حساب خدمات و سطل Google Cloud Storage را در مسیر ۱ ایجاد کرده‌اید:

gcloud storage rm --recursive gs://${BUCKET_NAME}
gcloud projects remove-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"
gcloud iam service-accounts delete ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com --quiet

۳. حذف خوشه GKE (فقط مسیر ۱)

اگر خوشه GKE Autopilot را در مسیر ۱ تأمین کرده‌اید:

gcloud container clusters delete ${CLUSTER_NAME} --region=${REGION} --quiet

‫۱۴. تبریک می‌گوییم

تبریک! ‫AlloyDB Omni را در codelab مربوط به Kubernetes تکمیل کرده‌اید.

آنچه پوشش دادیم

  • یک خوشه GKE Autopilot را آماده کرده‌اید (مسیر ۱) یا یک خوشه Kubernetes موجود را آماده کرده‌اید (مسیر ۲).
  • ‫cert-manager و اپراتور AlloyDB Omni Kubernetes را ازطریق Helm مستقر کردید.
  • یک AlloyDB Omni تک‌نمونه‌ای DBCluster مستقر شد.
  • خوشه را به «دسترسی‌پذیری بالا» (HA) با آماده‌به‌کارهای همگام ارتقا دادیم و مسیریابی آماده‌به‌کار فقط خواندنی را فعال کردیم.
  • منابع خودکار BackupPlan را برای فضای ذخیره‌سازی پایدار محلی و Google Cloud Storage (GCS) ایجاد کرد.
  • پشتیبان‌گیری‌های درخواستی را انجام داد و بازیابی‌های پایگاه داده را اعتبارسنجی کرد.
  • «بازیابی نقطه‌زمانی» (PITR) در خوشه پایگاه داده کلون‌شده جدید اجرا شد.
  • یک تجمیع‌کننده اتصال PgBouncer برای اتصالات کارخواه مقیاس‌پذیر مستقر کردیم.
  • pgAdmin4 برای مدیریت پایگاه داده مستقر و متصل شد.
  • «تعمیرات با زمان خرابی کم» (LDTM) را برای مقیاس‌بندی پویای منابع محاسباتی و حافظه اجرا کرد.

مراحل بعدی

‫۱۵. نظرسنجی

چگونه از این آموزش استفاده خواهید کرد؟

فقط آن را خوانده‌اید آن را خوانده‌اید و تمرین‌ها را تکمیل کرده‌اید