שיבוט של אשכול מסדי נתונים ב-Kubernetes באמצעות גיבוי מקומי

בחירת גרסה של מאמר העזרה:

במאמר הזה מוסבר איך לשכפל אשכול מסדי נתונים ב-Kubernetes באמצעות גיבוי מקומי של אשכול מסד נתונים של AlloyDB Omni.

ההנחות הבאות מבוססות על המסמך הזה:

  • אשכולות מסדי הנתונים של המקור והיעד נוצרים ב-Google Kubernetes Engine, והדיסקים של הגיבוי הם דיסקים קבועים של Compute Engine.
  • דיסקים קבועים ב-Compute Engine שמשמשים כדיסק גיבוי במסד הנתונים לא משמשים באשכולות אחרים של מסדי נתונים.

כשמשכפלים אשכול מסדי נתונים, פועלים לפי השלבים הבאים:

  1. מזהים את פרטי דיסק הגיבוי, כמו שם הנפח המתמשך ומטפל הדיסק אחסון מתמיד (persistent disk) של Compute Engine עבור דיסק הגיבוי של אשכול מסד הנתונים של המקור. מוודאים שהפעלתם את תכונת הגיבוי עבור אשכול מסד הנתונים של המקור, ושיש לכם גיבוי אחד לפחות שבוצע בהצלחה. אם התנאים האלה לא מתקיימים, צריך לפעול לפי ההוראות במאמר הפעלה ותזמון של גיבויים.
  2. יוצרים משאב PersistentVolume כדי להשתמש בדיסק גיבוי קיים באשכול מסד הנתונים של היעד כדי לגשת לדיסק הגיבוי של אשכול מסד הנתונים של המקור.
  3. יוצרים ומחילים את קובץ המניפסט של משאב DBCluster באשכול מסד הנתונים של היעד, כשהפרמטר livenessProbe מושבת ופרטי הדיסק של הגיבוי מתווספים.
  4. משתמשים בפקודות של pgBackRest כדי לוודא שאפשר לגשת לגיבויים של המקור.
  5. משתמשים בפקודות pgBackRest כדי לשחזר את הגיבוי לאשכול מסד הנתונים של היעד.

לפני שמתחילים

  • מוודאים שיש לכם גישה לדיסק הגיבוי שבו מאוחסן הגיבוי של אשכול מסד הנתונים של המקור.
  • צריכה להיות אפשרות לטעון את דיסק הגיבוי של אשכול מסד הנתונים של המקור באשכול מסד הנתונים של היעד. מידע נוסף זמין במאמר בנושא Persistent Volumes. אם קצה העורף של האחסון הבסיסי לא תומך בגישת ReadOnlyMany ‏ (ROX), צריך לוודא שאף פוד באשכול המקור לא משתמש בדיסק הגיבוי.
  • מכיוון שדיסק הגיבוי של המקור מחובר לאשכול מסד הנתונים של היעד, נעשה שימוש חוזר בקובץ pgBackRest.conf כמו שהוא.
  • מוודאים שאתם מחוברים למסד הנתונים כמשתמש postgres.

קבלת מידע על דיסק הגיבוי של המקור

כחלק מתהליך השחזור, צריך לקבוע את השם של התביעה על נפח אחסון מתמיד (PVC) של דיסק הגיבוי עבור אשכול מסד הנתונים של המקור. משתמשים ב-PVC ב-Kubernetes כדי לנהל אחסון מתמיד לאפליקציות.

פקודות הדוגמה הבאות עוזרות לאתר את השם הבסיסי של ה-PV ואת ה-handler של דיסק אחסון מתמיד (persistent disk) של Compute Engine. בדוגמה, כל דיסקי הגיבוי הם דיסקים קבועים של Compute Engine, שאפשר לגשת אליהם במכונות וירטואליות של Compute Engine באמצעות מזהה הדיסק.

  1. כדי למצוא את השם של ה-PVC, מתחברים לאשכול מסד הנתונים של היעד:

     kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backuprepodisk

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DB_CLUSTER_NAMESPACE: מרחב השמות של Kubernetes לתוכנית הגיבוי הזו. הוא חייב להיות זהה למרחב השמות של אשכול מסד הנתונים.

    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים הזה, לדוגמה my-db-cluster.

    זוהי דוגמה לתשובה.

        backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h

  2. משתמשים בשם ה-PVC של דיסק הגיבוי מהשלב הקודם – לדוגמה, backuprepodisk-my-db-cluster-br-0, כדי למצוא את שם ה-PV הבסיסי ואת המטפל בדיסק אחסון מתמיד (persistent disk) של Compute Engine:

      kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PVC_NAME: השם של ה-PVC של דיסק הגיבוי מהתגובה בשלב הקודם, לדוגמה backuprepodisk-my-db-cluster-br-0.

  3. מייצאים את ההגדרות על סמך שם ה-PV כמשתנים לשימוש בקטעים הבאים:

      export BACKUP_DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}")
  export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}")
  export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}")
  export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PV_NAME: השם של ה-PV של דיסק הגיבוי מהתגובה בשלב הקודם. לדוגמה, "backupDiskVolume".

יצירת משאב של נפח אחסון מתמיד

יוצרים משאב PersistentVolume באמצעות שם ה-handler של הדיסק.

  1. באשכול היעד של Kubernetes, יוצרים את קובץ המניפסט PersistentVolume:

        apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: PV_NAME
    spec:
      storageClassName: "${STORAGE_CLASS}"
      capacity:
        storage: "${BACKUP_DISK_SIZE}"
      accessModes:
        - ReadWriteOnce
      csi:
        driver: pd.csi.storage.gke.io
        volumeHandle: "${VOLUME_HANDLER}"
        fsType: "${FS_TYPE}"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PV_NAME: השם של משאב PersistentVolume שייווצר.

  2. החלת קובץ המניפסט:

      kubectl apply -f PV_FILENAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PV_FILENAME: השם של קובץ המניפסט PersistentVolume שנוצר בשלב הקודם.

יצירת אשכול מסד נתונים של יעד

יוצרים אשכול מסדי נתונים על ידי השבתה זמנית של הפרמטר livenessProbe. אחרי שהשחזור מסתיים, מגדירים מחדש את הפרמטר livenessProbe.

  1. יוצרים את קובץ המניפסט DBCluster:

      apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
  spec:
    databaseVersion: "15.7.0"
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DATA_DISK_SIZE
        - name: BackupDisk
          size: ${BACKUP_DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: PV_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים הזה, לדוגמה my-db-cluster.

    • ‫ENCODED_PASSWORD: הסיסמה להתחברות למסד הנתונים עבור תפקיד המשתמש שמוגדר כברירת מחדל postgres, בקידוד כמחרוזת base64. לדוגמה, Q2hhbmdlTWUxMjM= עבור ChangeMe123.

    • ‫CPU_COUNT: מספר המעבדים הזמינים לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה.

    • ‫MEMORY_SIZE: כמות הזיכרון לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה. מומלץ להגדיר את הערך הזה ל-8 גיגה-בייט לכל CPU. לדוגמה, אם הגדרתם את CPU_COUNT ל-2, מומלץ להגדיר את memory ל-16Gi.

    • ‫DATA_DISK_SIZE: גודל הדיסק לכל מופע של מסד נתונים, לדוגמה, 10Gi.

  2. החלת קובץ המניפסט:

      kubectl apply -f DBCLUSTER_FILENAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DBCLUSTER_FILENAME: השם של קובץ המניפסט DBCluster שנוצר בשלב הקודם.

משתמשים בפקודה kubectl describe כדי לוודא שמשאב אשכול מסד הנתונים נמצא בסטטוס READY.

אימות גיבויי המקור באשכול מסד הנתונים של היעד

מריצים פקודות pgBackRest כדי לוודא שיש גישה לגיבויים של אשכול מסד הנתונים של המקור באשכול מסד הנתונים של היעד.

  1. בצבר מסדי הנתונים של היעד, מאתרים את פרטי ה-Pod של צבר מסדי הנתונים:

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

    התשובה כוללת את השם של ה-pod של מסד הנתונים של האשכול.

  2. מתחברים ל-Pod של מסד הנתונים:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DATABASE_POD_NAME : השם של הפוד של אשכול מסד הנתונים מהשלב הקודם.

  3. מפסיקים את הפוד לפני העדכון של קובץ התצורה pgBackRest:

      supervisorctl.par stop postgres

  4. מעדכנים את קובץ התצורה pgBackRest:

      cp /backup/pgbackrest.conf /backup/pgbackrest.conf.bak
  rm /backup/pgbackrest.conf
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/backup/logs
  log-level-file=info
  EOF

  5. מאמתים את גיבויי המקור ב-Pod של אשכול מסד הנתונים:

    pgbackrest --config-path=/backup --stanza=db --repo=1 info

    זוהי דוגמה לתשובה:

      stanza: db
      status: ok
      cipher: none
      db (current)
          wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
          full backup: 20240213-231400F
              timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
              wal start/stop: 000000010000000000000003 / 000000010000000000000003
              database size: 38.7MB, database backup size: 38.7MB
              repo1: backup set size: 4.6MB, backup size: 4.6MB
          incr backup: 20240213-231400F_20240214-000001I
              timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
              wal start/stop: 00000001000000000000000D / 00000001000000000000000D
              database size: 38.7MB, database backup size: 488.3KB
              repo1: backup set size: 4.6MB, backup size: 84.2KB
              backup reference list: 20240213-231400F

חותמות הזמן בתשובה משמשות לשחזור הגיבוי המלא או לשחזור מנקודת זמן בחלון השחזור.

שחזור הגיבוי באשכול מסד הנתונים של היעד

אחרי שמזהים את הגיבוי או את נקודת הזמן שרוצים לשחזר, מריצים פקודות pgBackRest באשכול מסד הנתונים של היעד. מידע נוסף על הפקודות האלה זמין במאמר פקודת שחזור.

הנה כמה דוגמאות לפקודות שחזור של pgBackRest:

  • שחזור מגיבוי

    pgbackrest --config-path=/backup --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • שחזור מנקודה מסוימת בזמן

    pgbackrest --config-path=/backup --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

הפעלה מחדש של ה-pod

אחרי שהפקודה לשחזור מסתיימת בהצלחה, אפשר להתחיל את התהליך postgres.

supervisorctl.par start postgres

אחרי שתהליך postgres מתחיל, אפשר להתחבר למופע הראשי ולהריץ שאילתות כדי לוודא שהנתונים שוחזרו מהגיבוי. מידע נוסף זמין במאמר התחברות ל-AlloyDB Omni שפועל ב-Kubernetes.

הגדרת אשכול מסדי הנתונים

אחרי שמשכפלים אשכול מסדי נתונים, מגדירים את המפרטים של אשכול מסד הנתונים. חשוב להפעיל את הפרמטר livenessProbe באמצעות הפקודה הבאה:

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

המאמרים הבאים