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

בחירת גרסת התיעוד:

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

ההנחיות בדף הזה מניחות שאשכול מסד הנתונים של Kubernetes במקור נוצר ב-Google Kubernetes Engine, ודיסקי הגיבוי הם דיסקים קבועים של Compute Engine. בנוסף, ההנחה היא ששרת יחיד של AlloyDB Omni יעד מותקן במכונה וירטואלית (VM) של Compute Engine.

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

תהליך העבודה הבא מסביר את שלבי השכפול:

  1. מזהים את פרטי דיסק הגיבוי, כמו שם הנפח המתמיד ומטפל הדיסק המתמיד של Compute Engine, עבור דיסק הגיבוי של אשכול מסד הנתונים של המקור.
  2. מציבים את דיסק הגיבוי של אשכול מסד הנתונים של המקור בשרת היעד.
  3. משתמשים בפקודות של pgBackRest כדי לוודא שאפשר לגשת לגיבויים של המקור.
  4. משתמשים בפקודות pgBackRest כדי לשחזר את הגיבוי לאשכול מסד הנתונים של היעד.

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

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

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

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

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

  1. מתחברים לאשכול GKE שבו יצרתם את אשכול מסד הנתונים של מקור AlloyDB Omni:

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

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

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

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

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

      backupdisk-al-fe8c-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```

  2. משתמשים בשם דיסק הגיבוי מהשלב הקודם – לדוגמה, backupdisk-al-fe8c-dbcluster-sample-0, כדי למצוא את שם ה-PV הבסיסי:

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

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

    • ‫PVC_NAME: השם של ה-PVC של דיסק הגיבוי מהתגובה בשלב הקודם, לדוגמה backupdisk-al-fe8c-dbcluster-sample-0.

  3. מאתרים את המטפל הבסיסי בדיסק לאחסון מתמיד של Compute Engine:

      kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

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

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

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

      projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

  4. מייצאים את שם דיסק הגיבוי כמשתנה שמשמש בקטעים הבאים:

      export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

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

בהנחה ששרת היעד הוא שרת AlloyDB Omni שהותקן במכונה וירטואלית ב-Compute Engine, צריך לטעון את דיסק הגיבוי בשרת.

  1. מריצים את הפקודה gcloud compute instances attach-disk כדי לטעון את הדיסק:

      gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE

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

    • ‫GCE_INSTANCE_NAME: השם של המופע שבו השרת שלכם מותקן במכונה וירטואלית של Compute Engine.

    • ‫GCE_ZONE: האזור שבו קיימת המכונה הווירטואלית של Compute Engine.

  2. מטמיעים את דיסק הגיבוי בשרת היעד:

       lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

  3. מוסיפים bind mount בהתאמה אישית לקובץ dataplane.conf של AlloyDB Omni בספרייה /var/alloydb/config:

      PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

מידע נוסף על bind mounts ב-Docker זמין במאמר Bind mounts.

  1. מפעילים מחדש את שרת היעד:

Docker 

  docker restart CONTAINER_NAME

מחליפים את CONTAINER_NAME בשם של קונטיינר חדש של AlloyDB Omni – לדוגמה, my-omni-1.

Podman 

  podman restart CONTAINER_NAME

מחליפים את CONTAINER_NAME בשם של קונטיינר חדש של AlloyDB Omni – לדוגמה, my-omni-1.

עדכון קובץ התצורה pgBackRest

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

  1. בשרת היעד, עוברים לספרייה /mnt/disks/backupdisk:

      cd /mnt/disks/backupdisk

  2. כדי למנוע החלפה של הנתונים הקיימים, צריך לעדכן את הנתיב pg1-path לתיקייה זמנית בקובץ pgbackrest.conf. הספרייה data-restored נוצרת באופן אוטומטי כחלק מתהליך השחזור:

      sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

  3. מעדכנים את הנתיב repo1-path לספרייה זמנית בקובץ pgbackrest.conf:

      sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

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

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

Docker 

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Podman 

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --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 בשרת היעד. מידע נוסף על הפקודות האלה זמין במאמר RestoreCommand.

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

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

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

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

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

העתקת הנתונים לשרת היעד

אחרי שהפקודה לשחזור תושלם בהצלחה, תוכלו להעתיק את הנתונים מהספרייה הזמנית data-restored לספריית הנתונים הנוכחית של AlloyDB.

  1. בשרת היעד, מפסיקים את שירות מסד הנתונים:

    Docker 

    docker stop CONTAINER_NAME

    Podman 

    podman stop CONTAINER_NAME

  2. מומלץ לשנות את השם של ספריית הנתונים הנוכחית לשם אחר:

      mv ~/alloydb-data/data  ~/alloydb-data/data-old

  3. משנים את השם של הספרייה הזמנית data-restored לספריית הנתונים הנוכחית:

      mv ~/alloydb-data/data-restored ~/alloydb-data/data

  4. מעדכנים את הערך pg1-path בקובץ postgresql.auto.conf כדי לטעון את הנתונים ששוחזרו:

        vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

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

    Docker 

    docker start CONTAINER_NAME

    Podman 

    podman start CONTAINER_NAME

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

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