Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

טייס אוטומטי רגילה

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

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

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

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

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

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

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

אפשר לשנות את StorageClass של PersistentVolumeClaims (PVCs) מדיסק אחסון מתמיד (Persistent Disk) ל-Hyperdisk באופן דינמי במהלך השחזור.
צריך לעדכן את מניפסטים של Kubernetes, כמו Deployments, כדי לטרגט את סוגי המכונות החדשים מסוג 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 תואמים.

דיאגרמת ארכיטקטורה שמראה העברה של נתוני MySQL מ-Persistent Disk ל-Hyperdisk באמצעות Backup for GKE. — **איור 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.

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.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. 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.

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.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

צריך לוודא שיש לכם בפרויקט את התפקיד או התפקידים הבאים: 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

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

הפעלת Cloud Shell

יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. הסשן יופעל תוך כמה שניות.
מגדירים את פרויקט ברירת המחדל:
```
  gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט.

הגדרת הסביבה

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

מגדירים את משתני הסביבה של הפרויקט, שמות האשכולות והאזור:
```
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.

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

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

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

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

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

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"

יוצרים מאגר צמתים עם 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

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

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

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

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

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

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

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

addonsConfig:
  gkeBackupAgentConfig:
    enabled: true

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

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

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

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

פורסים את עומסי העבודה של 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

פריסת 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

מתחברים ל-Pod של הלקוח:
```
kubectl exec -it mysql-client -- bash
```

בתוך ה-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 ./

מייבאים את מערך הנתונים 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;

בודקים את נתוני Sakila המיובאים:

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

יוצאים מ-MySQL:

exit

מייבאים את מערך הנתונים World למסד הנתונים mysql-b:

mysql -u root -h mysql-b.namespace-b -p
# Enter password: migration

SOURCE /world-db/world.sql;

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

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

יוצאים מהמעטפת של ה-Pod של הלקוח:
```
exit
```

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

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

יצירת תוכנית גיבוי:
```
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 דקות (יום אחד), הגיבויים מתוזמנים להפעלה מדי יום.

יצירת גיבוי:

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.

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

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

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

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

יוצרים את אשכול 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"

יוצרים מאגר צמתים עם סוגי מכונות 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

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

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

החלת ה-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"

בודקים את כללי השינוי בקובץ 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: שינוי של storageClassName ל-balanced-storage (Hyperdisk).
שינוי הפריסה: עדכון של node affinity כדי לתזמן Pods בצמתים של n4-standard-4.

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

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

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

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

אימות ההעברה

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

בודקים אם ה-Pods פועלים:
```
kubectl get pods -A
```

מתחברים ל-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

מאמתים את מסד הנתונים 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';

מאמתים את מסד הנתונים 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 בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

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

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

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

# 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

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

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

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

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

מטרות

עלויות

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

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

מתן התפקידים

הגדרת Cloud Shell

הגדרת הסביבה

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

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

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

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

אימות ההעברה

הסרת המשאבים

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

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