نشر AlloyDB Omni وإدارته على Kubernetes (مجموعة GKE أو مجموعة خاصة بك)

1. مقدمة

في هذا الدرس التطبيقي حول الترميز، ستتعلّم كيفية تثبيت مشغّل AlloyDB Omni Kubernetes (منسّق الحاويات) على مجموعة Google Kubernetes Engine‏ (GKE) Autopilot أو مجموعة Kubernetes الخاصة بك، وإدارة مهام سير العمل الكاملة لدورة حياة قاعدة البيانات ورحلات المستخدمين الأساسية (CUJ).

‫AlloyDB Omni هو إصدار قابل للتنزيل من AlloyDB مصمّم للتشغيل في أي مكان، بدءًا من البيئات داخل المؤسسة إلى Google Cloud أو الحوسبة الطرفية. باستخدام منسّق الحاويات، يعمل AlloyDB Omni على أتمتة ميزات التوفّر العالي، وعمليات تجاوز الفشل التلقائية، والإصلاح الذاتي، والصيانة المتجدّدة مع الحدّ الأدنى من وقت التوقّف عن العمل، وتجميع الاتصالات، والنسخ الاحتياطية المبرمَجة، والاسترداد في نقطة زمنية معيّنة.

‫AlloyDB for PostgreSQL مقابل AlloyDB Omni: AlloyDB for PostgreSQL هي خدمة قواعد بيانات مُدارة بالكامل على Google Cloud. يجمع AlloyDB Omni محرّك قاعدة بيانات AlloyDB نفسه في حاويات قابلة للتنزيل يمكنك تشغيلها بنفسك، سواء في المؤسسة أو في السُحب الإلكترونية الأخرى المتاحة للجميع (مثل Amazon EKS أو Azure AKS) أو على OpenShift أو على محطة عمل المطوّر، وذلك لتلبية متطلبات موقع البيانات أو السحابة المختلطة أو التطوير المحلي. في عمليات النشر الواقعية، يتم عادةً تشغيل عامل تشغيل AlloyDB Omni Kubernetes على مجموعة Kubernetes الخاصة بك (المسار 2). يستخدم المسار 1 وضع GKE Autopilot فقط كبيئة اختبار Kubernetes مريحة وبدون إعداد محلي إذا لم يكن لديك مجموعة حالية.

اختيار مسار البيئة

يمكنك إكمال هذا الدرس التطبيقي حول الترميز باستخدام أي من المسارَين التاليَين:

1. المسار 1: امتلاك حساب على Google Cloud (GKE Autopilot): يمكنك توفير مجموعة GKE Autopilot مُدارة بالكامل باستخدام Google Cloud Shell أو Google Cloud Console.
2. المسار 2: ليس لديك حساب على Google Cloud (استخدام مجموعة Kubernetes الخاصة بك): استخدِم مجموعة Kubernetes حالية (الإصدار 1.21 أو إصدار أحدث) مع ضبط kubectl وhelm على محطة العمل. لا حاجة إلى حساب على Google Cloud أو واجهة سطر أوامر gcloud.

المتطلبات الأساسية

• معرفة أساسية بمفاهيم Kubernetes (مثل kubectl وHelm وتعريفات الموارد المخصّصة)
• بالنسبة إلى المسار 1 (Google Cloud / GKE Autopilot):
  • مشروع على Google Cloud تم تفعيل الفوترة فيه
  • الوصول إلى Google Cloud Shell أو محطة عمل تم ضبطها باستخدام gcloud وkubectl وhelm
• بالنسبة إلى المسار 2 (استخدام مجموعة Kubernetes الخاصة بك):
  • مجموعة Kubernetes تعمل بالإصدار 1.21 أو إصدار أحدث مع StorageClass تلقائي لتوفير PersistentVolume ديناميكي
  • عُقد العامل التي تعمل بنظام التشغيل Linux kernel 4.18 والإصدارات الأحدث مع تفعيل cgroup v2 ‏ (x86-64/AMD64) و8 وحدات معالجة مركزية افتراضية على الأقل و24 غيبي بايت من ذاكرة الوصول العشوائي القابلة للتخصيص في جميع أنحاء المجموعة.
  • محطة عمل تم إعدادها باستخدام kubectl وhelm متصلة بالمجموعة العنقودية

ما ستتعلّمه

• كيفية توفير مجموعة GKE Autopilot (المسار 1) أو التحقّق من صحة مجموعة Kubernetes حالية (المسار 2)
• كيفية تثبيت cert-manager ومشغّل AlloyDB Omni Kubernetes من خلال Helm
• كيفية نشر AlloyDB Omni DBCluster في مثيل واحد
• كيفية توسيع نطاق التوفّر العالي (HA) باستخدام أجهزة احتياطية متزامنة وتفعيل إمكانية إذن بالقراءة فقط
• كيفية ضبط النُسخ الاحتياطية المبرمَجة والمجدوَلة في مساحة تخزين المستودع على الجهاز (وGoogle Cloud Storage اختياريًا في المسار 1)
• كيفية إجراء نُسخ احتياطية عند الطلب والتحقّق من استعادة البيانات إلى حالة سابقة
• كيفية إجراء عملية استرداد البيانات في نقطة زمنية معيّنة (PITR) إلى مجموعة قواعد بيانات جديدة مستنسَخة
• كيفية نشر تجميع اتصالات PgBouncer لتوسيع نطاق اتصالات العملاء
• كيفية نشر pgAdmin4 لإدارة قاعدة البيانات والاستعلام عنها بشكل مرئي
• كيفية تنفيذ "الصيانة مع فترة توقّف قصيرة" (LDTM) لتوسيع نطاق موارد وحدة المعالجة المركزية والذاكرة

المتطلبات

• المسار 1: Google Cloud Shell مع أدوات gcloud وkubectl وhelm المثبَّتة مسبقًا
• المسار 2: وحدة طرفية تتضمّن kubectl وhelm متصلة بمجموعة Kubernetes.
• للاطّلاع على المستندات المرجعية، يُرجى مراجعة دليل نشر AlloyDB Omni الرسمي.

2. الإعداد والمتطلبات

اختَر المسار 1 إذا كنت تستخدم حسابًا على Google Cloud لإنشاء مجموعة GKE Autopilot، أو المسار 2 إذا كنت تستخدم مجموعة Kubernetes الخاصة بك بدون حساب على Google Cloud.

المسار 1: إعداد مشروع Google Cloud ‏ (GKE Autopilot)

1. في وحدة تحكّم Google Cloud، اختَر مشروعًا على Google Cloud أو أنشِئ مشروعًا جديدًا.
2. تأكَّد من تفعيل الفوترة لمشروعك. كيفية التحقّق من حالة الفوترة
3. افتح Google Cloud Shell بالنقر على رمز تفعيل Cloud Shell في أعلى يسار Google Cloud Console، أو بالانتقال إلى shell.cloud.google.com. يوفّر 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}

5. فعِّل واجهات Google Cloud APIs المطلوبة لخدمتَي GKE وCloud Storage:

gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

المسار 2: إعداد مجموعة خاصة بك (بدون حساب على Google Cloud)

إذا لم يكن لديك حساب على Google Cloud وكنت تستخدم مجموعة Kubernetes الخاصة بك، تحقَّق من المتطلبات الأساسية التالية من وحدة التحكّم قبل المتابعة:

1. تأكَّد من أنّ kubectl وhelm يمكنهما الوصول إلى المجموعة وأنّ العُقد Ready:

kubectl get nodes
helm version

2. تأكَّد من أنّ المجموعة تتضمّن StorageClass تلقائيًا تم وضع علامة (default) عليه. يوفّر بيانا DBCluster وBackupPlan PersistentVolumeClaims ديناميكيًا باستخدام StorageClass التلقائي في المجموعة:

kubectl get storageclass

إذا لم يتم وضع علامة (default) على أي StorageClass، يُرجى تحديد أحدها كخيار تلقائي قبل المتابعة:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

3. تأكَّد من أنّ عُقد العامل تستوفي متطلبات المشغّل الخاصة بالأجهزة ونظام التشغيل:
   • نظام التشغيل والنواة: نواة Linux‏ 4.18 أو إصدار أحدث مع تفعيل cgroup v2 على عُقد x86-64/AMD64.
   • سعة المجموعة: يجب توفُّر 8 وحدات معالجة مركزية افتراضية على الأقل و24 غيبي بايت من الذاكرة القابلة للتخصيص على مستوى عُقد العامل لتشغيل نُسخ قاعدة البيانات العالية التوفّر (تمت زيادة السعة إلى وحدتَي معالجة مركزية افتراضيتين و8 غيبي بايت لكل منها في الخطوة 12)، والنسخة المستنسخة من PITR وPgBouncer وpgAdmin4 في الوقت نفسه.
   • الوصول إلى الشبكة: إمكانية الوصول إلى الإنترنت الصادر لسحب صور الحاويات من gcr.io/alloydb-omni وquay.io/jetstack وdocker.io.

3- توفير مجموعة Kubernetes أو الاتصال بها

هل تستخدم مجموعة Kubernetes الخاصة بك (المسار 2)؟ تخطَّ الخيار "أ" والخيار "ب" أدناه، وتأكَّد من أنّ عُقد المجموعة هي Ready ضمن التحقّق من إمكانية اتصال المجموعة، وانتقِل مباشرةً إلى الخطوة التالية.

إذا كنت تتّبع المسار 1 (حساب Google Cloud)، يوفّر GKE Autopilot وضع Kubernetes مُدارًا بالكامل ولا يتطلّب تدخّلاً يدويًا، حيث تدير Google البنية الأساسية للمجموعة، وتوفير العُقد، وتوسيع النطاق تلقائيًا. يمكنك إنشاء مجموعة GKE Autopilot باستخدام Google Cloud CLI أو Google Cloud Console.

الخيار "أ": إنشاء مجموعة GKE Autopilot عبر واجهة سطر الأوامر (المسار 1)

نفِّذ أمر gcloud التالي في Cloud Shell:

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

الخيار "ب": إنشاء مجموعة GKE Autopilot من خلال وحدة التحكّم (المسار 1)

1. افتح Kubernetes Engine في Google Cloud Console.
2. في مساحة الروابط على يمين الصفحة، انقر على المجموعات العنقودية.
3. انقر على إنشاء.
4. في قسم GKE Autopilot، انقر على ضبط.
5. حدِّد اسم المجموعة (على سبيل المثال، omni-autopilot-cluster) واختَر منطقتك المفضَّلة (us-central1).
6. انقر على إنشاء.

التحقّق من إمكانية اتصال المجموعة (المسار 1 والمسار 2)

إذا أنشأت عنقود GKE Autopilot في المسار 1، اضبط بيانات اعتماد kubectl:

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

بالنسبة إلى كل من المسار 1 والمسار 2، تحقَّق من الاتصال بمجموعة Kubernetes:

kubectl get nodes

4. تثبيت المتطلبات الأساسية لـ Operator وOperator

يتطلّب مشغّل AlloyDB Omni Kubernetes استخدام cert-manager لإدارة شهادات بروتوكول أمان طبقة النقل (TLS) الخاصة ببرنامج الويب هوك للتحقّق من صحة البيانات.

1. تثبيت 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

2. تثبيت AlloyDB Omni Operator

انشر عامل تشغيل AlloyDB Omni Kubernetes في مساحة الاسم alloydb-omni-system باستخدام Helm:

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

5- إنشاء مجموعة قواعد بيانات بمثيل واحد

في هذه الخطوة، ستنشئ مساحة اسم مخصّصة للتطبيق وتنشئ مثيلاً واحدًا من AlloyDB Omni DBCluster.

1. <thought إنشاء مساحة الاسم وسرّ بيانات اعتماد المشرف

أنشئ مساحة اسم 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

2. نشر مجموعة 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

3. التحقّق من جاهزية المجموعة

راقِب حالة المجموعة إلى أن تصل قيمة المتغيّر DBCLUSTERPHASE إلى DBClusterReady. قد تستغرق عملية الإعداد الأولية عدة دقائق: يجب أن ينشئ المشغّل وحدة التخزين الدائمة ويسحب صورة قاعدة البيانات، وقد يحتاج إلى إعداد عقدة جديدة أولاً في GKE Autopilot.

kubectl get dbcluster -n omni-demo -w

اضغط على "Ctrl+C" للخروج من وضع المشاهدة عندما يصل "DBCLUSTERPHASE" إلى "DBClusterReady".

مثال على الناتج:

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

6. الترقية إلى ميزة "مدى التوفّر العالي" (HA) وتفعيل ميزة "الاستعداد للقراءة فقط"

يوفّر AlloyDB Omni ميزة "التوفّر العالي" (HA) المضمّنة مع النسخ المتماثل للبث، والمراقبة التلقائية للحالة، وتجاوز الفشل تلقائيًا، وعرض النُسخ المتماثلة للقراءة فقط.

1. تفعيل ميزة "الإتاحة العالية" و"النسخة المتماثلة للقراءة فقط"

عدِّل مواصفات DBCluster لضبط مثيل احتياطي واحد وتفعيل التوجيه الاحتياطي للقراءة فقط:

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

2. التحقّق من تثبيت 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) طلبات البحث للقراءة على النُسخ الاحتياطية.

7. ضبط خطط الاحتفاظ بنسخة احتياطية تلقائيًا (على الجهاز وGCS)

يوفّر AlloyDB Omni نُسخًا احتياطية مادية وأرشفة WAL من خلال المورد المخصّص BackupPlan. يمكنك ضبط فترة الاحتفاظ بالنسخة الاحتياطية وجداول cron المبرمَجة وأهداف النسخ الاحتياطي (وحدات التخزين الثابتة المحلية أو Google Cloud Storage).

1. إنشاء خطة احتياطية محلية

أنشِئ 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

يُرجى الانتظار حتى يتم الإبلاغ عن Ready من قِبل PHASE وتحديد موعد NEXTBACKUPTIME.

2. إنشاء خطة احتياطية في GCS (المسار 1: Google Cloud فقط — اختياري)

هل تستخدم مجموعة Kubernetes الخاصة بك بدون حساب على Google Cloud (المسار 2)؟ تخطَّ 2. أنشئ خطة احتياطية في GCS وانتقِل مباشرةً إلى الخطوة التالية. تستخدم جميع تمارين النسخ الاحتياطي والاسترداد في نقطة زمنية معيّنة المتبقية في هذا الدرس التطبيقي حول الترميز backupplan-local من القسم السابق.

لتخزين النُسخ الاحتياطية خارجيًا في حزمة Google Cloud Storage، أنشئ حزمة GCS، واضبط مفتاح حساب خدمة سريًا، وطبِّق BackupPlan في السحابة الإلكترونية.

1. أنشئ حزمة Cloud Storage:

export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}

2. أنشِئ حساب خدمة يتضمّن أذونات Storage Object Admin (مشرف عناصر مساحة التخزين)، وأنشِئ مفتاحًا له:

تنبيه: يقرأ مشغّل AlloyDB Omni بيانات اعتماد Cloud Storage من مفتاح حساب خدمة تخزّنه في Kubernetes Secret. لا تتناول مستندات المشغّل طرقًا أخرى للمصادقة، مثل Workload Identity Federation لـ GKE. إذا كانت مؤسستك تفرض سياسة المؤسسة iam.disableServiceAccountKeyCreation، سيتعذّر تنفيذ الأمر keys create. في هذه الحالة، يمكنك تخطّي بقية خطوات إنشاء خطة احتياطية في GCS. تستخدم الخطوات المتبقية من هذا الدرس التطبيقي حول الترميز خطة النسخ الاحتياطي المحلية.

مفتاح حساب الخدمة هو بيانات اعتماد طويلة الأمد. تؤدي الخطوة التالية إلى حذف النسخة المحلية، وتؤدي خطوة التنظيف إلى حذف حساب الخدمة ومفاتيحه. لمزيد من المعلومات، يُرجى الاطّلاع على المقالة إنشاء خطة لتخزين النُسخ الاحتياطية في Cloud Storage.

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"

3. أنشئ الرمز السرّي في مساحة اسم Kubernetes:

kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json

4. طبِّق ملف بيان 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

يُرجى الانتظار حتى يتم الإبلاغ عن Ready من قِبل PHASE وتحديد موعد NEXTBACKUPTIME.

8. إدراج البيانات وبدء عملية الاحتفاظ بنسخة احتياطية واختبار الاستعادة

في هذه الخطوة، ستملأ البيانات الأولية في قاعدة البيانات الأساسية، وتُفعِّل نسخة احتياطية يدوية عند الطلب، وتضيف البيانات اللاحقة، وتستعيد البيانات من النسخة الاحتياطية لإثبات التراجع عن البيانات.

1. تعبئة البيانات الأولية

شغِّل مجموعة مؤقتة لعميل 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. هذه هي كلمة المرور التي تم ترميزها باستخدام Base64 في سر db-pw-adbo في الخطوة 5.

ملاحظة: تمرّر أوامر kubectl run pg-client المتبقية في هذا الدرس التطبيقي حول الترميز --env="PGPASSWORD=ChangeMe123" لكي تتم مصادقة psql بدون طلب تفاعلي. هذا لأغراض التوضيح فقط، لذا لا تضع كلمات مرور الإنتاج في سطر الأوامر.

2. بدء عملية الاحتفاظ بنسخة احتياطية عند الطلب

أنشِئ موردًا مخصّصًا يدويًا من النوع 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".

3. تغيير البيانات (إضافة سجلّات جديدة)

أدخِل سجلات إضافية بعد النسخة الاحتياطية:

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;
  "

تحتوي قاعدة البيانات الآن على 4 صفوف.

4. الاستعادة من النسخة الاحتياطية

يمكنك بدء عملية استعادة الحالة التي تم تسجيلها في 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

5. التحقّق من حالة البيانات التي تمت استعادتها

أدخِل طلب بحث في الجدول 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)، ما يثبت أنّه تمت استعادة قاعدة البيانات إلى حالة النسخة الاحتياطية نفسها.

9. الاستعادة في نقطة زمنية (PITR) إلى قاعدة بيانات مستنسخة

تتيح ميزة "الاسترداد في نقطة زمنية معيّنة" (PITR) استعادة قاعدة بيانات إلى أي ثانية عشوائية ضمن نافذة الاسترداد باستخدام النُسخ الاحتياطية الأساسية وسجلّات بث WAL، ما يؤدي إلى توفير البيانات المسترَدة في مجموعة جديدة من قواعد البيانات المستنسَخة.

بما أنّ المشغّل يؤرشف سجلّ Write-Ahead Log‏ (WAL) باستمرار، تتيح لك ميزة PITR استرداد البيانات بعد حدوث أخطاء بشرية أو أخطاء في التطبيق، مثل DELETE أو DROP TABLE غير مقصودَين في الساعة 2:15:00 بعد الظهر، وذلك من خلال استنساخ قاعدة البيانات إلى الثانية المحدّدة قبل حدوث الخطأ (2:14:59 بعد الظهر)، بدون لمس المجموعة الأصلية.

1. تسجيل الطابع الزمني الحالي وتبديل البيانات

استرداد الطابع الزمني الحالي للتوقيت العالمي المتفق عليه:

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;
  "

2. إجراء عملية استعادة البيانات في نقطة زمنية معيّنة

ملاحظة: ينشئ المشغّل DBCluster المستنسَخ في مساحة الاسم نفسها التي يتوفّر فيها العنقود المصدر، omni-demo. لا يمكن الاستنساخ في مساحة اسم مختلفة. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة استنساخ مجموعة من نقطة زمنية معيّنة.

طبِّق المورد المخصّص Restore الذي يضبط 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

3. التحقّق من قاعدة البيانات المستنسَخة

بعد اكتمال عملية الاستعادة، انتظِر حتى يصل DBCluster الجديد المستنسَخ إلى DBClusterReady (اضغط على Ctrl+C للخروج من وضع المشاهدة):

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

يمكنك الاستعلام عن قاعدة البيانات المستنسَخة adbo-cloned من خلال خدمة القراءة والكتابة 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 غير متوفّر في المجموعة المستنسَخة، ما يشير إلى دقة عملية الاسترداد إلى النقطة الزمنية المستهدَفة بالضبط.

10. نشر PgBouncer Connection Pooler

يقلّل تجميع الاتصالات من وقت استجابة الاتصال ومن استهلاك ذاكرة قاعدة البيانات. يدير المشغّل مثيلات PgBouncer بشكلٍ أصلي من خلال المورد المخصّص PgBouncer.

ينشئ PostgreSQL عملية منفصلة في نظام التشغيل لكل اتصال عميل، لذا يمكن أن تستنفد مئات الاتصالات المتزامنة من خدمات الويب أو الخدمات المصغّرة أو وكلاء الذكاء الاصطناعي ذاكرة قاعدة البيانات. يقع PgBouncer أمام قاعدة البيانات ويضاعف العديد من اتصالات العملاء قصيرة الأجل (ما يصل إلى max_client_conn) في مجموعة صغيرة من اتصالات خادم PostgreSQL طويلة الأجل (default_pool_size لكل زوج من المستخدمين/قاعدة البيانات، بحد أقصى max_db_connections).

1. نشر 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

2. التحقّق من حالة 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

3. الاتصال عبر 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 الأساسية.

11. نشر pgAdmin4 للوصول إلى قاعدة البيانات

يمكنك تشغيل pgAdmin4 مباشرةً داخل مجموعة Kubernetes لتوفير وحدة تحكّم إدارية مستندة إلى الويب لإجراء طلبات البحث في AlloyDB Omni وإدارتها وفحصها.

1. تثبيت 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="[e-mail]" \
  --set auth.password="AdminPassword123"

يسمّي هذا المخطط موارد Kubernetes باسم pgadmin4 (النشر والخدمة وPersistentVolumeClaim) ويصنّف مجموعات Pods الخاصة به باسم app=pgadmin4، بغض النظر عن اسم إصدار Helm (my-pgadmin).

تحقَّق من أنّ مجموعة pgAdmin4 قيد التشغيل:

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

2. إعادة توجيه المنفذ والوصول إلى واجهة مستخدم الويب

أعِد توجيه منفذ pgAdmin4 إلى بيئتك المحلية أو Cloud Shell:

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

يستمر تشغيل kubectl port-forward في المقدّمة طالما أنّك تستخدم واجهة المستخدم على الويب pgAdmin4. افتح وحدة طرفية ثانية (أو علامة تبويب جديدة في Cloud Shell) للأوامر الأخرى، واضغط على Ctrl+C في هذه الوحدة الطرفية عندما تكون مستعدًا للانتقال إلى الخطوة التالية.

افتح واجهة الويب pgAdmin4:

• المسار 1 (Google Cloud Shell): انقر على زر معاينة الويب في القائمة أعلى يسار الصفحة، واختَر تغيير المنفذ، وأدخِل 5050، ثم انقر على تغيير ومعاينة.
• المسار 2 (محطة العمل المحلية): افتح http://localhost:5050 في المتصفّح أثناء تنفيذ الأمر kubectl port-forward.

سجِّل الدخول باستخدام:

• البريد الإلكتروني: [e-mail]
• كلمة المرور: AdminPassword123

3. تسجيل 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. انقر على حفظ وتحقَّق من جلسة قاعدة البيانات النشطة والجداول.

12. توسيع نطاق وحدة المعالجة المركزية والذاكرة باستخدام ميزة "الصيانة مع فترة توقّف قصيرة" (LDTM)

عند زيادة موارد الحوسبة والذاكرة عموديًا في قاعدة بيانات إنتاج، تؤدي التحديثات التقليدية إلى انقطاعات في إعادة تشغيل قاعدة البيانات. يوفّر AlloyDB Omni ميزة الصيانة مع الحدّ الأدنى من وقت التوقف عن العمل (LDTM) لتطبيق التحديثات من خلال النُسخ المتماثلة مع الحدّ الأدنى من تعطُّل التطبيق.

1. تفعيل التعليقات التوضيحية في LDTM

أضِف تعليقًا توضيحيًا إلى DBCluster لتفعيل LDTM للتحديثات:

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

2. توسيع نطاق موارد وحدة المعالجة المركزية والذاكرة

عدِّل المراجع الأساسية من 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"
      }
    }
  }
}'

3. مراقبة مستوى تقدّم عملية توسيع نطاق 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}'

13. موارد إخلاء المساحة

لإخلاء سعة المجموعة وتجنُّب فرض رسوم غير ضرورية على حسابك على Google Cloud، عليك إزالة الموارد التي تم توفيرها خلال هذا الدرس التطبيقي حول الترميز.

إذا كنت تُجري عملية التنظيف في جلسة Terminal جديدة (المسار 1)، لن يتم ضبط متغيّرات البيئة من الخطوات السابقة. أعِد تصديرها بالقيم نفسها التي استخدمتها سابقًا:

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}

1. حذف أعباء عمل قواعد البيانات (المسار 1 والمسار 2)

ضَع علامة على كلا المجموعتَين على أنّهما محذوفتان لاجتياز عمليات التحقق من الردّ التلقائي على الويب، وانتظِر حتى يزيل المشغّل موارد 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 الخاصة بك (المسار 2) وأردت أيضًا إزالة عامل تشغيل 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

2. حذف حزمة GCS وحساب خدمة "إدارة الهوية وإمكانية الوصول" (المسار 1 فقط)

إذا أنشأت حزمة Google Cloud Storage وحساب الخدمة في المسار 1:

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

3. حذف مجموعة GKE (المسار 1 فقط)

إذا وفّرت مجموعة GKE Autopilot في المسار 1:

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

14. تهانينا

تهانينا! لقد أكملت الدرس التطبيقي حول الترميز AlloyDB Omni على Kubernetes.

المواضيع التي تناولناها

• توفير مجموعة GKE Autopilot (المسار 1) أو إعداد مجموعة Kubernetes حالية (المسار 2)
• تم نشر cert-manager ومشغّل AlloyDB Omni Kubernetes من خلال Helm.
• تم نشر مثيل واحد من AlloyDB Omni DBCluster.
• تمت ترقية المجموعة إلى "مدى التوفّر المرتفع" (HA) مع تفعيل ميزة "الاستعداد المتزامن" وتوجيه الاستعداد للقراءة فقط.
• تم إنشاء موارد BackupPlan مبرمَجة لكل من مساحة التخزين الثابتة المحلية وGoogle Cloud Storage.
• أجريتُ عمليات نسخ احتياطي عند الطلب وتحقّقتُ من عمليات استعادة قواعد البيانات.
• تم تنفيذ ميزة "الاسترداد في نقطة زمنية محدّدة" (PITR) في مجموعة عنقودية جديدة لقاعدة بيانات مستنسخة.
• تم نشر مجمّع اتصالات PgBouncer لاتصالات العملاء القابلة للتوسّع.
• تم نشر pgAdmin4 وربطه لإدارة قاعدة البيانات.
• تم تنفيذ عملية صيانة لتقليل وقت التوقّف عن العمل (LDTM) من أجل توسيع نطاق موارد الحوسبة والذاكرة بشكل ديناميكي.

الخطوات التالية

• استكشِف ميزة "التعافي من الكوارث" (DR) في AlloyDB Omni في بيئات متعددة المجموعات.
• مزيد من المعلومات حول إمكانات AlloyDB Omni AI وpgvector

15. استطلاع

كيف ستستخدم هذا البرنامج التعليمي؟

قراءته فقط قراءته وإكمال التمارين