העברת נתוני MySQL מ-Persistent Disk ל-Hyperdisk באמצעות Backup for GKE

Autopilot Standard

במדריך הזה נסביר איך להעביר אפליקציות עם שמירת מצב (stateful) ב-GKE מסוגי מכונות מדור ישן יותר, כמו N2, עם אמצעי אחסון מצורפים של Persistent Disk, לסוגי מכונות מדור חדש יותר, כמו N4, עם אמצעי אחסון מצורפים של Hyperdisk, באמצעות גיבוי ל-GKE. מידע נוסף על סוגי מכונות שתומכות ב-Hyperdisk זמין במאמרי העזרה של Compute Engine.

כדי להדגים את ההעברה, במדריך הזה נעשה שימוש במסד הנתונים Sakila ובמסד הנתונים World כדי לספק מערכי נתונים לדוגמה. ‫Sakila הוא מסד נתונים לדוגמה שסופק על ידי MySQL ומייצג חנות בדיונית להשכרת DVD. מסד הנתונים World מכיל נתונים על מדינות וערים. במדריך נעשה שימוש בשני מערכי נתונים שונים במרחבי שמות נפרדים כדי לדמות סביבה מורכבת של דיירים רבים.

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

למה כדאי לעבור ל-Hyperdisk?

‫Hyperdisk הוא אחסון בלוקים (block storage) בעל ביצועים גבוהים של Google, שמציע IOPS וקצב העברת נתונים גבוהים משמעותית בהשוואה ל-Persistent Disk. השיפור הזה בביצועים הוא קריטי לאפליקציות עם מצב (stateful) שדורשות הרבה פעולות קלט/פלט, כמו מסדי נתונים של MySQL. עם זאת, יש תמיכה ב-Hyperdisk רק בדורות חדשים יותר של מכונות, כמו N4. כדי לבצע מיגרציה ל-Hyperdisk, צריך להעביר את עומסי העבודה למאגר צמתים או לאשכול חדש.

למה כדאי להשתמש בגיבוי ל-GKE?

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

• לשנות את StorageClass של PersistentVolumeClaims (PVCs)‎ מ-Persistent Disk ל-Hyperdisk באופן דינמי במהלך השחזור.
• מעדכנים את המניפסטים של Kubernetes, כמו פריסות, כדי לטרגט את סוגי המכונות החדשים של N4 שנדרשים ל-Hyperdisk.

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

ארכיטקטורת פריסה

בתרשים הבא מוצג תהליך השימוש ב-Backup for GKE להעברת עומסי עבודה של MySQL עם שמירת מצב מ-Persistent Disk בסוגי מכונות N2 ל-Hyperdisk בסוגי מכונות N4.

• אשכול מקור: שתי פריסות של MySQL נמצאות במרחבי שמות נפרדים, namespace-a ו-namespace-b, במאגר צמתים מסדרת מכונות N2. בפריסות האלה נעשה שימוש בדיסק מתמיד שמבוסס על SSD לאחסון נתונים.
• אסטרטגיית גיבוי: מפעילים את הסוכן Backup for GKE באשכול ויוצרים תוכנית גיבוי כדי לתעד את מרחבי השמות, נתוני הנפח והסודות. לאחר מכן, אתם מבצעים גיבוי ידני כדי ליצור נקודת שחזור בזמן.
• טרנספורמציה ושחזור: מגדירים תוכנית שחזור באמצעות כללי טרנספורמציה כדי להתאים את המשאבים לסביבת היעד. הכללים האלה מבצעים את הפעולות הבאות:
  • מחליפים את StorageClass מ-premium-rwo (PD) לסוג אחסון Hyperdisk בשם balanced-storage.
  • משנים את כללי הזיקה של ה-Pod כדי לוודא שעומסי העבודה ששוחזרו מתוזמנים במאגר צמתים חדש של N4.
• סביבת היעד: אתם מקצים אשכול GKE חדש עם סוגי מכונות N4. תהליך השחזור יוצר מחדש את הדיסקים כנפחי Hyperdisk מהגיבוי, ומפריס את מופעי MySQL בצמתי N4 תואמים.

איור 1: העברת נתוני MySQL מ-Persistent Disk ל-Hyperdisk באמצעות Backup for GKE.

מטרות

במדריך הזה תלמדו איך:

• הכנת אפליקציות עם שמירת מצב (stateful) ב-GKE לגיבוי.
• מפעילים את התוסף Backup for GKE.
• יוצרים תוכנית גיבוי ומגבים את אשכול המקור.
• יוצרים תוכנית שחזור שמשתמשת בכללי המרה כדי להעביר את האחסון ל-Hyperdisk.
• משחזרים את עומס העבודה לאשכול חדש ומאמתים את הנתונים.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• GKE
• Compute Engine (Persistent Disk and Hyperdisk)
• Backup for GKE

בעזרת מחשבון העלויות אתם יכולים להעריך את העלויות בהתאם לשימוש הצפוי.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Backup for GKE, and IAM APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine, GKE, Backup for GKE, and IAM APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

1. צריך לוודא שיש לכם בפרויקט את התפקיד או התפקידים הבאים: roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer

   בדיקת התפקידים

   1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
   2. בוחרים את הפרויקט.

   3. בעמודה Principal, מחפשים את כל השורות שמזהות אתכם או קבוצה שאתם נכללים בה. כדי לדעת באילו קבוצות אתם נכללים, פנו לאדמין.

   4. בודקים את העמודה Role בכל השורות שבהן מצוין או מופיע השם שלכם, כדי לראות אם רשימת התפקידים כוללת את התפקידים הנדרשים.

   מתן התפקידים

   1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
   2. בוחרים את הפרויקט.
   3. לוחצים על Grant access.

   4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל מזהה המשתמש הוא כתובת האימייל של חשבון Google.

      ‫
   5. לוחצים על Select a role ומחפשים את התפקיד.
   6. כדי לתת עוד תפקידים, לוחצים על Add another role ומוסיפים אותם.
   7. לוחצים על Save.

הגדרת Cloud Shell

1. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

   יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. הסשן יופעל תוך כמה שניות.

2. מגדירים את פרויקט ברירת המחדל:

     gcloud config set project PROJECT_ID
   

   מחליפים את PROJECT_ID במזהה הפרויקט.

הגדרת הסביבה

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

1. מגדירים את משתני הסביבה של הפרויקט, שמות האשכולות והאזור:

   export PROJECT_ID=PROJECT_ID
   export KUBERNETES_CLUSTER_PREFIX=backup-gke-migration
   export TARGET_CLUSTER_PREFIX=restore-gke-migration
   export ZONE=us-central1-a
   

   מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

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

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd kubernetes-engine-samples/databases/backup-migration
   

יצירת אשכול GKE של המקור

יוצרים אשכול אזורי עם מאגר צמתים שמשתמש בסוגי מכונות N2 ובאמצעי אחסון מצורפים של Persistent Disk.

1. יוצרים את האשכול:

   gcloud container clusters create ${KUBERNETES_CLUSTER_PREFIX}-cluster \
     --location ${ZONE} \
     --node-locations ${ZONE} \
     --shielded-secure-boot \
     --shielded-integrity-monitoring \
     --machine-type "e2-micro" \
     --num-nodes "1"
   

2. יוצרים מאגר צמתים עם סוגי מכונות של n2-standard-4 לעומס העבודה במקור:

   gcloud container node-pools create regular-pool \
     --cluster ${KUBERNETES_CLUSTER_PREFIX}-cluster \
     --machine-type n2-standard-4 \
     --zone ${ZONE} \
     --num-nodes 1
   

3. מפעילים את התוסף Backup for GKE באשכול המקור:

   gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
     --project=${PROJECT_ID}  \
     --location=${ZONE} \
     --update-addons=BackupRestore=ENABLED
   

4. מקבלים את פרטי הכניסה לאשכול:

   gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --zone ${ZONE}
   

5. מוודאים שהסוכן של Backup for GKE מופעל:

   gcloud container clusters describe ${KUBERNETES_CLUSTER_PREFIX}-cluster \
     --project=${PROJECT_ID}  \
     --location=${ZONE}
   

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

   addonsConfig:
     gkeBackupAgentConfig:
       enabled: true
   

פריסת MySQL עם נתונים לדוגמה

פורסים שני מסדי נתונים של MySQL במרחבי שמות נפרדים כדי לדמות סביבת ייצור.

1. יוצרים את מרחבי השמות namespace-a ו-namespace-b:

   kubectl create namespace namespace-a
   kubectl create namespace namespace-b
   

2. פורסים את עומסי העבודה של MySQL ב-namespace-a וב-namespace-b:

   • פורסים את הקובץ mysql-a-deployment.yaml:

     kubectl apply -f manifests/02-mysql/mysql-a-deployment.yaml -n namespace-a
     

     קובץ המניפסט הבא יוצר Pod של MySQL ב-namespace-a עם דיסקים של אחסון מתמיד (persistent disks) מסוג SSD שהוקצו באופן דינמי בצמתים של regular-pool. סיסמת הבסיס מוגדרת ל-migration:

     apiVersion: v1
     kind: Service
     metadata:
       name: mysql-a
       labels:
         app: mysql
     spec:
       ports:
         - port: 3306
       selector:
         app: mysql
       clusterIP: None
     ---
     apiVersion: v1
     kind: PersistentVolumeClaim
     metadata:
       name: mysql-a-pv-claim
       labels:
         app: mysql
     spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: 30Gi
       storageClassName: premium-rwo
     ---
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: existing-mysql-a
       labels:
         app: mysql
     spec:
       selector:
         matchLabels:
           app: mysql
       strategy:
         type: Recreate
       template:
         metadata:
           labels:
             app: mysql
         spec:
           containers:
           - image: mysql:8.0
             name: mysql
             env:
             - name: MYSQL_ROOT_PASSWORD
               value: migration
             - name: MYSQL_DATABASE
               value: mysql
             - name: MYSQL_USER
               value: app
             - name: MYSQL_PASSWORD
               value: migration
             ports:
             - containerPort: 3306
               name: mysql-a
             volumeMounts:
             - name: mysql-persistent-storage
               mountPath: /var/lib/mysql
           affinity: 
             nodeAffinity:
               preferredDuringSchedulingIgnoredDuringExecution:
               - weight: 1
                 preference:
                   matchExpressions:
                   - key: "node.kubernetes.io/instance-type"
                     operator: In  
                     values:
                     - "n2-standard-4"
           volumes:
           - name: mysql-persistent-storage
             persistentVolumeClaim:
               claimName: mysql-a-pv-claim

   • פורסים את הקובץ mysql-b-deployment.yaml:

     kubectl apply -f manifests/02-mysql/mysql-b-deployment.yaml -n namespace-b
     

     קובץ המניפסט הבא יוצר Pod של MySQL ב-namespace-b עם דיסקים של אחסון מתמיד (persistent disks) מסוג SSD שהוקצו באופן דינמי בצמתים של regular-pool. סיסמת הבסיס מוגדרת ל-migration:

     apiVersion: v1
     kind: Service
     metadata:
       name: mysql-b
       labels:
         app: mysql
     spec:
       ports:
         - port: 3306
       selector:
         app: mysql
       clusterIP: None
     ---
     apiVersion: v1
     kind: PersistentVolumeClaim
     metadata:
       name: mysql-b-pv-claim
       labels:
         app: mysql
     spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: 30Gi
       storageClassName: premium-rwo
     ---
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: existing-mysql-b
       labels:
         app: mysql
     spec:
       selector:
         matchLabels:
           app: mysql
       strategy:
         type: Recreate
       template:
         metadata:
           labels:
             app: mysql
         spec:
           containers:
           - image: mysql:8.0
             name: mysql
             env:
             - name: MYSQL_ROOT_PASSWORD
               value: migration
             - name: MYSQL_DATABASE
               value: mysql
             - name: MYSQL_USER
               value: app
             - name: MYSQL_PASSWORD
               value: migration
             ports:
             - containerPort: 3306
               name: mysql-b
             volumeMounts:
             - name: mysql-persistent-storage
               mountPath: /var/lib/mysql
           affinity: 
             nodeAffinity:
               preferredDuringSchedulingIgnoredDuringExecution:
               - weight: 1
                 preference:
                   matchExpressions:
                   - key: "node.kubernetes.io/instance-type"
                     operator: In
                     values:
                     - "n2-standard-4"
           volumes:
           - name: mysql-persistent-storage
             persistentVolumeClaim:
               claimName: mysql-b-pv-claim

3. פורסים Pod של לקוח MySQL כדי להעלות מערכי נתונים לדוגמה:

   kubectl apply -f manifests/02-mysql/mysql-client.yaml
   kubectl wait pods mysql-client --for condition=Ready --timeout=300s
   

   קובץ המניפסט הבא פורס Pod של לקוח MySQL:

   apiVersion: v1
   kind: Pod
   metadata:
     name: mysql-client
   spec:
     containers:
     - name: main
       image: mysql:8.0
       command: ["sleep", "360000"]
       resources:
         requests:
           memory: 1Gi
           cpu: 500m
         limits:
           memory: 1Gi
           cpu: "1"
       env:
       - name: MYSQL_ROOT_PASSWORD
         value: migration

4. מתחברים ל-Pod של הלקוח:

   kubectl exec -it mysql-client -- bash
   

5. בתוך ה-Pod, מורידים את מערכי הנתונים לדוגמה Sakila ו-World:

   curl --output dataset.tgz "https://downloads.mysql.com/docs/sakila-db.tar.gz"
   tar -xvzf dataset.tgz -C ./
   
   curl --output world-db.tar.gz "https://downloads.mysql.com/docs/world-db.tar.gz"
   tar xvzf world-db.tar.gz -C ./
   

6. מייבאים את קבוצת הנתונים Sakila למסד הנתונים mysql-a:

   mysql -u root -h mysql-a.namespace-a -p
   # Enter password: migration
   
   SOURCE /sakila-db/sakila-schema.sql;
   SOURCE /sakila-db/sakila-data.sql;
   

7. מאמתים את נתוני Sakila שיובאו:

   USE sakila;
   SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'sakila';
   

   יוצאים מ-MySQL:

   exit
   

8. מייבאים את קבוצת הנתונים World למסד הנתונים mysql-b:

   mysql -u root -h mysql-b.namespace-b -p
   # Enter password: migration
   
   SOURCE /world-db/world.sql;
   

9. בודקים את הנתונים של העולם שיובאו:

   USE world;
   SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'world';
   

   הפלט אמור להיראות כך:

   +-----------------+------------+
   | table_name      | table_rows |
   +-----------------+------------+
   | city            |       4079 |
   | country         |        239 |
   | countrylanguage |        984 |
   +-----------------+------------+
   

   יוצאים מ-MySQL:

   exit
   

10. יוצאים מה-shell של ה-Pod של הלקוח:

    exit
    

גיבוי של אשכול GKE

לגבות את כל האשכול, כולל סודות ונפחים.

1. יצירת תוכנית גיבוי:

   gcloud beta container backup-restore backup-plans create main-plan \
     --project=${PROJECT_ID} \
     --location=us-central1 \
     --cluster=projects/${PROJECT_ID}/locations/${ZONE}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster \
     --selected-namespaces=namespace-a,namespace-b,default \
     --include-secrets \
     --include-volume-data \
     --target-rpo-minutes=1440 \
     --backup-retain-days=7 \
     --backup-delete-lock-days=3 \
     --locked
   

   • ‫--selected-namespaces: מגבה מרחבי שמות ספציפיים כדי למנוע התנגשויות עם משאבי המערכת.
   • ‫--include-volume-data: עוזר לוודא שנתוני ה-Persistent Disk מגובים.
   • ‫--target-rpo-minutes: הגדרה של יעד להתאוששות מאסון (RPO) בהתאם ללוח הזמנים של הגיבוי. ‫RPO הוא חלון הזמן המקסימלי שבו יכול להיות שנתונים יאבדו, והוא קובע את תדירות הגיבוי. אם בוחרים בגיבוי כל 1440 דקות (יום אחד), הגיבויים מתוזמנים להפעלה מדי יום.

2. כדי ליצור גיבוי:

   gcloud beta container backup-restore backups create first-backup \
       --project=${PROJECT_ID} \
       --location=us-central1 \
       --backup-plan=main-plan \
       --wait-for-completion
   

   מחכים עד שמופיע הפלט Backup state: SUCCEEDED.

3. מוודאים שהגיבוי נוצר:

   gcloud beta container backup-restore backups list \
       --project=${PROJECT_ID} \
       --location=us-central1 \
       --backup-plan=main-plan
   

שחזור עם טרנספורמציה של Hyperdisk

משחזרים את הגיבוי לאשכול חדש. השחזור משנה את האחסון מ-Persistent Disk ל-Hyperdisk ומעביר את עומסי העבודה לצמתי N4.

1. יוצרים את אשכול GKE היעד בצומת N4:

   gcloud container clusters create ${TARGET_CLUSTER_PREFIX}-cluster \
     --location ${ZONE} \
     --node-locations ${ZONE} \
     --shielded-secure-boot \
     --shielded-integrity-monitoring \
     --machine-type "e2-micro" \
     --num-nodes "1"
   

2. יוצרים מאגר צמתים עם סוגי מכונות מסוג n4-standard-4, שנדרשים ל-Hyperdisk:

   gcloud container node-pools create hyperdisk-pool \
     --cluster ${TARGET_CLUSTER_PREFIX}-cluster \
     --machine-type n4-standard-4 \
     --zone ${ZONE} \
     --num-nodes 1
   

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

   gcloud container clusters get-credentials ${TARGET_CLUSTER_PREFIX}-cluster --zone ${ZONE}
   

4. החלת Hyperdisk StorageClass בשם balanced-storage:

   kubectl apply -f manifests/01-storage-class/storage-class-hdb.yaml
   

   המניפסט הבא מגדיר Hyperdisk StorageClass:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: balanced-storage
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
     provisioned-throughput-on-create: "250Mi"
     provisioned-iops-on-create: "7000"

5. בודקים את כללי הטרנספורמציה בקובץ manifests/03-transformation-rule/volume.yaml. בקובץ הזה מוגדר איך משנים את המשאבים במהלך השחזור:

   transformationRules:
   - description: Change the StorageClass on PVCs from premium-rwo to balanced-storage
     resourceFilter:
       namespaces: ["namespace-a","namespace-b"]
       groupKinds:
       - resourceGroup: ""
         resourceKind: PersistentVolumeClaim
     fieldActions:
     - op: REPLACE
       path: "/spec/storageClassName"
       value: "balanced-storage"
   - description: Change node type from n2-standard-4 to n4-standard-4
     resourceFilter:
       namespaces: ["namespace-a","namespace-b"]
       jsonPath: ".metadata[?(@.name == 'existing-mysql')]"
       groupKinds:
       - resourceGroup: apps
         resourceKind: Deployment
     fieldActions:
     - op: REPLACE
       path: "/spec/template/spec/affinity/nodeAffinity/preferredDuringSchedulingIgnoredDuringExecution/0/preference/matchExpressions/0/values/0"
       value: "n4-standard-4"

   • ‫PVC transformation: משנה את storageClassName ל-balanced-storage (Hyperdisk).
   • טרנספורמציה של פריסה: מעדכנת את ההעדפה של הצומת כדי לתזמן את ה-Pods בצמתים של n4-standard-4.

6. יוצרים תוכנית שחזור באמצעות כללי הטרנספורמציה הבאים:

   gcloud beta container backup-restore restore-plans create main-restore \
     --project=${PROJECT_ID} \
     --location=us-central1 \
     --backup-plan=projects/${PROJECT_ID}/locations/us-central1/backupPlans/main-plan \
     --cluster=projects/${PROJECT_ID}/locations/${ZONE}/clusters/${TARGET_CLUSTER_PREFIX}-cluster \
     --namespaced-resource-restore-mode=merge-replace-on-conflict \
     --all-namespaces \
     --cluster-resource-conflict-policy=use-existing-version  \
     --cluster-resource-scope-selected-group-kinds=cluster-resource-scope-all-group-kinds \
     --volume-data-restore-policy=restore-volume-data-from-backup \
     --transformation-rules-file=manifests/03-transformation-rule/volume.yaml
   

7. מבצעים את השחזור:

   gcloud beta container backup-restore restores create first-restore \
      --project=${PROJECT_ID} \
      --location=us-central1 \
      --restore-plan=main-restore \
      --backup=projects/${PROJECT_ID}/locations/us-central1/backupPlans/main-plan/backups/first-backup
   

אימות ההעברה

מוודאים שהאפליקציות פועלות באשכול החדש ושהנתונים תקינים.

1. בודקים אם ה-Pods פועלים:

   kubectl get pods -A
   

2. מתחברים ל-Pod של לקוח MySQL באשכול החדש:

   # Verify that the client Pod is running
   kubectl apply -f manifests/02-mysql/mysql-client.yaml
   kubectl wait pods mysql-client --for condition=Ready --timeout=300s
   kubectl exec -it mysql-client -- bash
   

3. מאמתים את מסד הנתונים Sakila ששוחזר ב-namespace-a:

   mysql -u root -h mysql-a.namespace-a -p
   # Password: migration
   
   USE sakila;
   SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'sakila';
   

4. מאמתים את מסד הנתונים World ששוחזר ב-namespace-b:

   mysql -u root -h mysql-b.namespace-b -p
   # Password: migration
   
   USE world;
   SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'world';
   

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים הנפרדים.

1. מוחקים את אשכולות GKE:

   gcloud container clusters delete ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${ZONE} --quiet
   gcloud container clusters delete ${TARGET_CLUSTER_PREFIX}-cluster --location ${ZONE} --quiet
   

2. מחיקת הגיבוי ותוכניות השחזור:

   # Delete the restore plan
   gcloud beta container backup-restore restore-plans delete main-restore \
       --project=${PROJECT_ID} \
       --location=us-central1 \
       --quiet
   
   # Delete the Backup
   gcloud beta container backup-restore backups delete first-backup \
       --project=${PROJECT_ID} \
       --location=us-central1 \
       --backup-plan=main-plan \
       --quiet
   
   # Delete the backup plan
   gcloud beta container backup-restore backup-plans delete main-plan \
       --project=${PROJECT_ID} \
       --location=us-central1 \
       --quiet
   

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

• מידע נוסף על Backup for GKE
• מידע נוסף על Hyperdisk Storage Pool