העברת מסדי נתונים באמצעות קובץ פיזי של Percona XtraBackup

אפשר להעביר את מסדי הנתונים של MySQL ל-Cloud SQL באמצעות קובצי גיבוי פיזיים של מסד הנתונים שנוצרו באמצעות כלי השירות Percona XtraBackup ל-MySQL. העברה באמצעות קובצי גיבוי פיזיים מאפשרת שחזור נתונים מהיר יותר בהשוואה להעברות שמתבצעות באמצעות קובצי גיבוי לוגיים. לכן הם בחירה מצוינת להעברת מסדי נתונים גדולים שמכילים כמה טרה-בייט של נתונים.

תהליך ההעברה הזה כולל את המשימות הבאות:

  1. גיבוי של מופע MySQL של המקור והכנת קובצי הגיבוי הפיזיים באמצעות כלי השירות Percona XtraBackup for MySQL.

  2. העלאת קובצי הגיבוי לקטגוריה של Cloud Storage.

  3. יצירה והפעלה של משימת ההעברה ב-Database Migration Service.

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

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

העברות אופליין

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

אפשר לבצע העברה לצורך בדיקה, שבה Database Migration Service לא מתחבר למופע המקור. במקום זאת, Database Migration Service קורא רק את קובצי הגיבוי שמעלים לקטגוריה של Cloud Storage ומשכפל את התוכן שלהם ליעד Cloud SQL ל-MySQL. לא מומלץ להשתמש בתהליך העברה שלא מסתמך על קישוריות לרשת בהעברות של סביבת ייצור, כי Database Migration Service לא יכול לבצע אימות נתונים מלא.

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

מגבלות

בקטע הזה מפורטות המגבלות של העברות שמשתמשות בקבצים פיזיים של Percona XtraBackup:

  • אין תמיכה בהעברה ל-MySQL 5.6 או ל-8.4 עם קובץ גיבוי פיזי. מגבלות ידועות

  • שיקולים לגבי גרסאות שונות:

    • אפשר להעביר נתונים רק בתוך אותה גרסה ראשית של מסד הנתונים, למשל מ-MySQL 8.0.30 ל-MySQL 8.0.35, או מ-MySQL 5.7.0 ל-MySQL 5.7.1.

    • אי אפשר לבצע מיגרציה מ-MySQL 5.7 ל-MySQL 8.0.

    • אין תמיכה בהעברה לגרסאות קודמות של מסד נתונים, בין אם מדובר בגרסה ראשית או משנית. לדוגמה, אי אפשר להעביר מ-MySQL 8.0 ל-5.7 או מ-MySQL 8.0.36 ל-8.0.16.

  • שיקולים שקשורים לארכיטקטורה: Cloud SQL תומך בארכיטקטורת ARM. אפשר להעביר מסדי נתונים רק בין מכונות מאותו סוג ארכיטקטורה. לדוגמה, אם מסד הנתונים שלכם מתארח במחשב ARM64, תצטרכו להעביר אותו למחשב ARM64.

  • גודל הדיסק של מסד הנתונים של היעד צריך להיות שווה לגודל מסד הנתונים של המקור או גדול ממנו. מידע נוסף זמין במאמר סוגי מכונות MySQL למהדורת Cloud SQL שלכם.

  • אין תמיכה בגיבויים שמכילים קבצים שגדולים מ-5TB.

    הגודל המקסימלי של קובץ להעלאה ל-Cloud Storage הוא 5TB. המגבלה הזו מתייחסת רק לגודל של קובצי הגיבוי, ולא לגודל הכולל של מסד הנתונים. יכול להיות שתוכלו לפעול לפי תרחיש ההעברה הזה גם אם הגודל הכולל של מסד הנתונים שלכם גדול מ-5TB. גודל קובצי הגיבוי נקבע (בין היתר) על ידי הדגל innodb_file_per_table:

    • אם הערך של innodb_file_per_table הוא OFF, אפשר לשמור כמה טבלאות בקובץ אחד. במקרה כזה, אם מסד הנתונים גדול מ-5TB, יכול להיות שהוא לא נתמך בתרחיש הזה.
    • כשמגדירים את innodb_file_per_table לערך ON, כל טבלה נשמרת בקובץ *.ibd נפרד. אם אין לכם טבלה אחת שגודלה גדול מ-5TB, קובצי הגיבוי שלכם אמורים להיות כשירים להעלאה ל-Cloud Storage.

    אם הגודל הכולל של מסד הנתונים שלכם גדול מ-5TB, והנתונים כוללים טבלאות גדולות במיוחד, מומלץ לבצע קודם גיבוי של הרצה יבשה לנפח מקומי. כך תוכלו לוודא שאף קובץ גיבוי לא חורג מהמגבלה של 5TB ב-Cloud Storage.

  • חובה להשתמש ב-Percona XtraBackup כדי לגבות את הנתונים לקטגוריה ב-Cloud Storage. אין תמיכה בכלי גיבוי אחרים.

  • חשוב להעלות את קובצי הגיבוי לתיקייה ייעודית ב-Cloud Storage שלא מכילה קבצים אחרים.

  • העברת מסד נתונים מקובץ פיזי של Percona XtraBackup נתמכת רק במסדי נתונים של MySQL במכונות וירטואליות מקומיות או בניהול עצמי. אין תמיכה בהעברה ממסדי נתונים של Amazon Aurora או MySQL ב-Amazon RDS.

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

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

  • צריך להגדיר את הפורמט של יומן הרישום הבינארי לערך ROW. אם מגדירים את יומן הרישום הבינארי לפורמט אחר, כמו STATEMENT או MIXED, יכול להיות שהשכפול ייכשל.

  • הפרמטר innodb_page_size במופע המקור צריך להיות מוגדר עם ערך ברירת המחדל 16384.

  • אי אפשר להעביר פלאגינים ממסד הנתונים החיצוני.

עלויות

השירות Database Migration Service מוצע ללא תשלום נוסף להעברות הומוגניות אל Cloud SQL. עם זאת, התמחור של Cloud SQL ו-Cloud Storage חל גם על חיובים ברשת וגם על ישויות של Cloud SQL ו-Cloud Storage שנוצרו למטרות מיגרציה.

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

  • Cloud Storage
  • Cloud SQL

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

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

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

  1. כדאי לחשוב באיזה אזור רוצים ליצור את מסד הנתונים של היעד. Database Migration Service הוא מוצר אזורי מלא, כלומר כל הישויות שקשורות למיגרציה (פרופילים של חיבורי מקור ויעד, משימות מיגרציה, מסדי נתונים של יעד, מאגרי אחסון) צריכות להישמר באזור אחד.

  2. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

    תפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

    כניסה לדף לבחירת הפרויקט

  3. מפעילים את ממשקי ה-API של Database Migration Service,‏ Compute Engine ו-Cloud SQL Admin.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לביצוע העברות הומוגניות של MySQL באמצעות קובצי גיבוי פיזיים, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

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

ההרשאות הנדרשות

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

  • חשבון המשתמש שמבצע את ההעברה:
    • datamigration.*
    • resourcemanager.projects.get
    • resourcemanager.projects.list
    • cloudsql.instances.create
    • cloudsql.instances.get
    • cloudsql.instances.list
    • compute.machineTypes.list
    • compute.machineTypes.get
    • compute.projects.get
    • storage.buckets.create
    • storage.buckets.list

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

שלב 1. בדיקת דרישות החיבור לרשת

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

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

שלב 2. הכנת נתוני המקור

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

  1. מתקינים את הגרסה הנכונה של כלי השירות Percona XtraBackup במופע המקור. חובה להשתמש בגרסה של Percona XtraBackup שזהה לגרסה של מופע המקור או חדשה ממנה. מידע נוסף זמין במאמר השוואה בין גרסת השרת לגרסת הגיבוי במסמכי העזרה של Percona XtraBackup.
  2. מייצאים ומכינים את קובץ הגיבוי הפיזי של מופע המקור באמצעות Percona XtraBackup. למידע מלא על השימוש ב-Percona XtraBackup, אפשר לעיין ב מסמכי העזרה של הכלי. אפשר גם להרחיב את הקטע הבא כדי לראות דוגמה לשלבים מומלצים.

    דוגמה לשלבים מומלצים ליצירה ולהכנה של קובצי גיבוי פיזיים באמצעות Percona XtraBackup

    לפני שמשתמשים בנתוני הפקודה, צריך להחליף את הנתונים הבאים:

    • ‫TARGET_DIR בנתיב שבו רוצים לשמור את קובץ הגיבוי של הפלט.
    • ‫USERNAME עם משתמש שיש לו הרשאת BACKUP_ADMIN במופע המקור.
    • PASSWORD עם הסיסמה של חשבון USERNAME.
    1. מבצעים גיבוי פיזי מלא של מופע המקור. מריצים את הפקודה הבאה: 
        xtrabackup --backup \
    --target-dir=TARGET_DIR \
    --user=USERNAME \
    --password=PASSWORD
    2. כשקובץ הגיבוי מוכן, משתמשים בפקודה --prepare כדי לוודא שהקובץ עקבי. מריצים את הפקודה הבאה: 
        xtrabackup --prepare --target-dir=TARGET_DIR
  3. יוצרים את קטגוריית האחסון כדי לאחסן את קובצי הגיבוי. חשוב לוודא שאתם משתמשים באותו אזור שבו אתם מתכוונים ליצור את מופע היעד של Cloud SQL ל-MySQL.

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

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

    המסוף

    כדי ליצור פרופיל של חיבור למקור:

    1. עוברים לדף Connection profiles (פרופילי חיבור) במסוף Google Cloud .
    2. לוחצים על יצירת פרופיל.
    3. בדף Create a connection profile, בתפריט הנפתח המנוע של מסד הנתונים, בוחרים באפשרות MySQL.
    4. בשדה Connection profile name (שם פרופיל החיבור), מזינים שם שקל לקרוא אותו בשביל פרופיל החיבור. הערך הזה מוצג ברשימת פרופילי החיבור.
    5. משאירים את מזהה פרופיל החיבור שנוצר אוטומטית.
    6. מזינים שם מארח או כתובת IP.

      • אם מסד הנתונים של המקור מתארח ב- Google Cloud, או אם נעשה שימוש במנהרת SSH הפוכה כדי לחבר את מסד הנתונים של היעד למסד הנתונים של המקור, צריך לציין את כתובת ה-IP הפרטית (הפנימית) של מסד הנתונים של המקור. כתובת זו תהיה נגישה ליעד Cloud SQL. מידע נוסף זמין במאמר הגדרת קישוריות באמצעות VPC Peering.

        לשיטות קישוריות אחרות, כמו רשימת כתובות IP להיתר, צריך לספק את כתובת ה-IP הציבורית.

    7. מזינים את היציאה שמשמשת לגישה למארח. יציאת ברירת המחדל של MySQL היא 3306.
    8. מזינים שם משתמש וסיסמה למסד הנתונים של היעד. לחשבון המשתמש צריכות להיות ההרשאות הנדרשות כדי לגשת לנתונים שלכם. למידע נוסף, ראו הגדרת מסד נתוני המקור.
    9. בקטע Connection profile region בדף, בוחרים את האזור שבו רוצים לשמור את פרופיל החיבור.

    10. אופציונלי: אם החיבור מתבצע דרך רשת ציבורית (באמצעות רשימות היתרים של כתובות IP), מומלץ להשתמש בהצפנת SSL/TLS לחיבור בין מסדי הנתונים של המקור והיעד.

      יש שלוש אפשרויות להגדרת SSL/TLS שניתן לבחור מביניהן בקטע Secure your connection בדף:

      1. ללא: מופע היעד של Cloud SQL מתחבר למסד הנתונים של המקור ללא הצפנה.

      2. אימות רק של השרת: כשמופע היעד של Cloud SQL מתחבר למסד הנתונים של המקור, המופע מאמת את המקור כדי לוודא שהוא מתחבר למארח הנכון בצורה מאובטחת. כך נמנעות התקפות מסוג 'אדם בתווך'. באימות רק של השרת, המקור לא מאמת את המופע.

        כדי להשתמש באימות רק של השרת, צריך לספק את אישור X.509 בקידוד PEM של רשות האישורים (CA) שחתמה על האישור של השרת החיצוני.

      3. אימות שרת-לקוח: כשמופע היעד מתחבר למקור, המופע מאמת את המקור והמקור מאמת את המופע.

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

        כדי להשתמש באימות שרת-לקוח, צריך לספק את הפריטים הבאים כשיוצרים את פרופיל החיבור ליעד:

        • אישור ה-CA שחתם על האישור של שרת מסד הנתונים של המקור (אישור CA).
        • האישור שבו המופע משתמש כדי לבצע אימות מול שרת מסד הנתונים של המקור (אישור הלקוח).
        • המפתח הפרטי שמשויך לאישור הלקוח (מפתח הלקוח).
    11. לוחצים על יצירה. פרופיל החיבור נוצר.

    gcloud

    בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. כלומר, יכול להיות שיעבור זמן מה עד שהפקודות יושלמו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.

    לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

    • CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל החיבור.
    • ‫REGION עם המזהה של האזור שבו רוצים לשמור את פרופיל החיבור.
    • ‫HOST_IP_ADDRESS עם כתובת ה-IP שבה Database Migration Service יכול להגיע למופע של מסד הנתונים של המקור. הערך הזה יכול להשתנות בהתאם ל שיטת הקישוריות שבה אתם משתמשים להעברה.
    • ‫PORT_NUMBER עם מספר היציאה שדרכה מסד הנתונים של המקור מקבל חיבורים נכנסים. יציאת ברירת המחדל של MySQL היא 3306.
    • ‫USERNAME עם השם של חשבון המשתמש במסד הנתונים שרוצים ש-Database Migration Service יתחבר אליו כמופע של מסד נתונים של מקור.
    • ‫PASSWORD מחליפים בסיסמה של חשבון המשתמש במסד הנתונים.
    • (אופציונלי) CONNECTION_PROFILE_NAME עם שם קריא לפרופיל הקישור. הערך הזה מוצג במסוף Google Cloud .

    מריצים את הפקודה הבאה:

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --host=HOST_IP_ADDRESS \
  --port=PORT_NUMBER \
  --username=USERNAME \
  --password=PASSWORD \
  --display-name=CONNECTION_PROFILE_NAME

    ‏Windows (PowerShell)

    gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --host=HOST_IP_ADDRESS `
  --port=PORT_NUMBER `
  --username=USERNAME `
  --password=PASSWORD `
  --display-name=CONNECTION_PROFILE_NAME

    Windows‏ (cmd.exe)

    gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --host=HOST_IP_ADDRESS ^
  --port=PORT_NUMBER ^
  --username=USERNAME ^
  --password=PASSWORD ^
  --display-name=CONNECTION_PROFILE_NAME

    אמורים לקבל תגובה שדומה לזו:

    Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

שלב 3. הגדרת עבודת ההעברה והרצתה

כשמבצעים העברה באמצעות Percona XtraBackup, אפשר ליצור את מופע היעד של Cloud SQL בעצמכם, או להשתמש בשירות Database Migration Service כדי ליצור אותו. מידע נוסף זמין במאמר סקירה כללית על יצירת משימות העברה.

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

  • אם רוצים ש-Database Migration Service ייצור את מסד הנתונים של היעד, בוחרים באפשרות העברה למופע יעד חדש.
  • אם רוצים להעביר למסד נתונים של יעד שנוצר מחוץ ל-Database Migration Service, בוחרים באפשרות העברה למופע יעד קיים.

  • כשמעבירים למופע יעד חדש, Database Migration Service יוצר עבורכם את מופע היעד של Cloud SQL ל-MySQL במהלך תהליך יצירת משימת ההעברה.

    שלב 3א. יצירת משימת העברה למופע יעד חדש

    כדי ליצור משימת העברה למופע יעד חדש, פועלים לפי השלבים הבאים:

    המסוף

    הגדרת הגדרות לעבודת ההעברה

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

      אל 'משימות העברה'

    2. לוחצים על יצירת משימת העברה.

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

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

    3. בדף תחילת העבודה, מזינים את הפרטים הבאים:
      1. שם משימת ההעברה

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

      2. מזהה משימת ההעברה

        זהו מזהה שניתן לקריאה על ידי מכונה של עבודת ההעברה. משתמשים בערך הזה כדי לעבוד עם משימות העברה באמצעות פקודות או API של Google Cloud CLI של Database Migration Service.

      3. ברשימה מנוע מסד הנתונים של המקור, בוחרים באפשרות MySQL.

        השדה Destination database engine (המנוע של מסד הנתונים של היעד) מאוכלס באופן אוטומטי ואי אפשר לשנות אותו.

      4. בוחרים את האזור שבו שומרים את משימת ההעברה.

        Database Migration Service הוא מוצר אזורי לחלוטין, כלומר כל הישויות שקשורות למיגרציה (פרופילים של חיבור למקור וליעד, משימות מיגרציה, מסדי נתונים של היעד) צריכות להישמר באזור אחד. בוחרים את האזור בהתאם למיקום של השירותים שזקוקים לנתונים שלכם, כמו מכונות וירטואליות של Compute Engine או אפליקציות של App Engine, ושירותים אחרים. אחרי שבוחרים את אזור היעד, אי אפשר לשנות את הבחירה הזו.

    4. לוחצים על שמירה והמשך.

    ציון מידע על פרופיל החיבור למקור

    1. בדף Define a source, מבצעים את השלבים הבאים:
      1. בתפריט הנפתח פרופיל חיבור למקור, בוחרים את פרופיל החיבור למסד הנתונים של המקור.
      2. בקטע התאמה אישית של הגדרת הגיבוי המלא, לוחצים על עריכת ההגדרה.
      3. בחלונית Edit full dump configuration, בתפריט הנפתח Full dump method, בוחרים באפשרות Physical based.
      4. בקטע Provide your folder (ציון התיקייה), לוחצים על Browse (עיון), ואז בוחרים את התיקייה שאליה העליתם את קובץ ה-dump המלא (שלב 3 בקטע הכנת נתוני המקור).
      5. לוחצים על Save.
    2. לוחצים על שמירה והמשך.

    הגדרה ויצירה של מכונת היעד ב-Cloud SQL

    1. בדף הגדרת יעד, בתפריט הנפתח סוג היעד של מופע, בוחרים באפשרות מופע חדש. מגדירים את כל ההגדרות הרלוונטיות:
      1. בשדה Destination Instance ID (מזהה מופע היעד), מציינים מזהה למופע Cloud SQL או משתמשים במזהה שנוצר אוטומטית.

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

      2. בשדה סיסמה, מזינים סיסמה אלפאנומרית למכונת היעד של Cloud SQL. זו הסיסמה לחשבון האדמין של root במופע.

        אפשר להזין את הסיסמה באופן ידני או ללחוץ על יצירה כדי ש-Database Migration Service ייצור סיסמה בשבילכם באופן אוטומטי.

      3. בתפריט הנפתח Database version (גרסת מסד הנתונים), בוחרים את גרסת מסד הנתונים של מופע היעד.

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

      4. בוחרים את מהדורת Cloud SQL ל-MySQL עבור מכונת היעד. יש שתי אפשרויות: Cloud SQL ל-MySQL Enterprise Edition ו- Cloud SQL ל-MySQL Enterprise Plus Edition.

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

      5. בתפריט אזור מוצג אותו אזור שבחרתם בדף תחילת העבודה.

        אם אתם מגדירים את המופע לזמינות גבוהה, בוחרים באפשרות Multiple zones (Highly available). אפשר לבחור גם את האזור הראשי וגם את האזור המשני. התנאים הבאים חלים כשמשתמשים באזור המשני במהלך יצירת מופע:

        • כברירת מחדל, האזורים מוגדרים לAny עבור האזור הראשי ולAny (different from primary) עבור האזור המשני.
        • אם מציינים גם את האזור הראשי וגם את האזור המשני, הם צריכים להיות אזורים שונים.
      6. בקטע Connections, בוחרים אם להוסיף כתובת IP ציבורית או פרטית למופע היעד. אפשר להגדיר את המופע כך שיכלול את שני סוגי כתובות ה-IP, אבל נדרש לפחות סוג אחד לצורך ההעברה. בוחרים אחת מהאפשרויות הבאות:
        • אם רוצים לבצע העברה באמצעות קישור בין רשתות VPC שכנות (peering) או מנהרת SSH הפוכה, בוחרים באפשרות כתובת IP פרטית.

          • כדי להפעיל קישוריות פרטית של כתובות IP, צריך לוודא שאתם עומדים בכל דרישות הרשת הנוספות.

            כדי לראות את הדרישות המלאות לגבי כתובות IP פרטיות, אפשר להרחיב את הקטע הזה.
          • בוחרים את רשת ה-VPC המשויכת ליצירת שותפות. אם אתם מתכננים להתחבר למקור ההעברה באמצעות VPC Peering, צריך לבחור את ה-VPC שבו נמצא המופע.
          • אם אף פעם לא הוגדרה רשת של שירות מנוהל עבור ה-VPC שנבחר, אפשר לבחור טווח כתובות IP וללחוץ על Connect (קישור), או להשתמש בטווח כתובות IP שנבחר באופן אוטומטי וללחוץ על Allocate & Connect (הקצאה וקישור).
        • אם רוצים לבצע העברה דרך האינטרנט באמצעות רשימת היתרים של כתובות IP, בוחרים באפשרות כתובת IP ציבורית.

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

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

    2. בוחרים את סוג המכונה למופע Cloud SQL.

      מידע נוסף מופיע בקטע מגבלות.

    3. ב-Cloud SQL ל-MySQL Enterprise Plus edition: מסמנים את התיבה Enable data cache אם רוצים להשתמש בתכונת מטמון הנתונים במסד הנתונים של היעד.

      מטמון נתונים הוא תכונה אופציונלית שזמינה במכונות של Cloud SQL ל-MySQL במהדורת Enterprise Plus. התכונה מוסיפה כונן מקומי מהיר מסוג SSD למסד הנתונים של היעד. השימוש בתכונה הזו עלול להוסיף עלויות ל-Cloud SQL. מידע נוסף על מטמון נתונים זמין במאמר סקירה כללית על מטמון נתונים במאמרי העזרה של Cloud SQL.

    4. מציינים את סוג האחסון של מכונת Cloud SQL. אפשר לבחור כונן SSD או כונן HDD.
    5. מציינים את קיבולת האחסון (בגיגה-בייט) של מכונת Cloud SQL.

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

    6. (אופציונלי) מגדירים אפשרויות להצפנת נתונים או תוויות של משאבים עבור מופע היעד.

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

      לוחצים על Show optional configurations (הצגת הגדרות אופציונליות), ואז:

      1. מציינים אם רוצים לנהל את ההצפנה של הנתונים שמועברים מהמקור ליעד. כברירת מחדל, הנתונים שלכם מוצפנים באמצעות מפתח שמנוהל על ידי Google Cloud. אם רוצים לנהל את ההצפנה, אפשר להשתמש במפתח הצפנה בניהול הלקוח (CMEK). כדי לעשות את זה:

        1. מסמנים את תיבת הסימון Use a customer-managed encryption key (CMEK) (שימוש במפתח הצפנה בניהול הלקוח).
        2. בתפריט Select a customer-managed key (בחירת מפתח בניהול הלקוח), בוחרים את מפתח ה-CMEK.

        אם המפתח לא מופיע, לוחצים על Enter key resource name (הזנת שם משאב של מפתח) כדי לספק את שם המשאב של המפתח שרוצים להשתמש בו. דוגמה לשם משאב מרכזי: projects/my-project-name/locations/my-location/keyRings/my-keyring/cryptoKeys/my-key.

      2. מוסיפים את כל הדגלים שצריך להחיל על שרת מסד הנתונים. אם אפשר, מוודאים שהדגלים של מסד הנתונים במכונת היעד של Cloud SQL זהים לאלה של מסד הנתונים המקורי. MySQL
      3. מוסיפים תוויות שספציפיות למכונה של Cloud SQL.

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

    7. לוחצים על יצירת יעד והמשך. ‫Database Migration Service יוצר עכשיו את מכונת היעד של Cloud SQL. התהליך הזה יכול להימשך כמה דקות.

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

    בתפריט הנפתח Connectivity method (שיטת קישוריות), בוחרים שיטת קישוריות לרשת. השיטה הזו מגדירה איך מכונת Cloud SQL שנוצרה תתחבר למסד הנתונים של המקור. שיטות הקישוריות הנוכחיות לרשת כוללות רשימת היתרים של IP, מנהור SSH הפוך וקישור בין רשתות VPC שכנות (peering).

    אם רוצים להשתמש ב...ואז...
    שיטת הקישוריות לרשת של רשימת היתרים לכתובות IP, צריך לציין את כתובת ה-IP היוצאת של מופע היעד. אם מכונת Cloud SQL שיצרתם היא מכונה עם זמינות גבוהה, צריך לכלול את כתובות ה-IP היוצאות של המכונה הראשית ושל המכונה המשנית.
    שיטת הקישוריות לרשת של מנהרת SSH הפוכה, צריך לבחור את המכונה הווירטואלית (VM) של Compute Engine שתארח את המנהרה.

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

    מריצים את הפקודות ממכונה שיש לה קישוריות גם למסד הנתונים של המקור וגם ל- Google Cloud.
    שיטת הקישור בין רשתות VPC שכנות (peering) צריך לבחור את רשת ה-VPC שבה נמצאת מסד הנתונים של המקור. המופע של Cloud SQL יעודכן כדי להתחבר לרשת הזו.

    אחרי שבוחרים ומגדירים את קישוריות הרשת, לוחצים על הגדרה והמשך.

    יצירת משימת ההעברה

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

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

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

    gcloud

    1. יוצרים את פרופיל החיבור של היעד.
      כשמבצעים מיגרציה למופע יעד חדש באמצעות Google Cloud CLI, יוצרים את מופע היעד ואת פרופיל החיבור בפעולה אחת.
      מריצים את הפקודה הבאה (כדי להרחיב את הפקודה, לוחצים על הקישור):

      gcloud database-migration connection-profiles create cloudsql

      בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. כלומר, יכול להיות שיעבור זמן מה עד שהפקודות יושלמו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל החיבור.
      • ‫DATABASE_VERSION עם גרסת MySQL שבה רוצים להשתמש במופע היעד. גרסאות של מסד נתונים מצוינות כמחרוזות שכוללות גם את הגרסה הראשית וגם את הגרסה המשנית. לדוגמה: MYSQL_8_0, MYSQL_8_0_32, MYSQL_8_0_36.

        רשימה של כל הגרסאות האפשריות של MySQL זמינה ב מאמרי העזרה בנושא האפשרות ‎--database-version.

      • (אופציונלי) EDITION כברירת מחדל, מופעים חדשים שיוצרים באמצעות Google Cloud CLI משתמשים ב-Cloud SQL ל-MySQL במהדורת Enterprise Plus. אם אתם מתכננים להשתמש ב-Cloud SQL ל-MySQL Enterprise Plus Edition, אתם צריכים לוודא שהאזור שלכם נתמך במהדורה הזו. מידע נוסף זמין במאמר בנושא תמיכה באזורים במהדורת Cloud SQL ל-MySQL Enterprise Plus.

        אפשר לשנות את המהדורה באמצעות הדגל --edition עם אחד מהערכים הבאים:

        • ‫enterprise-plus למהדורת Cloud SQL ל-MySQL Enterprise Plus
        • ‫enterprise למהדורת Cloud SQL ל-MySQL Enterprise
      • ‫TIER עם השם של סוג המכונה ב-Cloud SQL שרוצים להשתמש בו. סוגי המכונות מצוינים כמחרוזות שפועלות לפי המוסכמות של Cloud SQL, לדוגמה: ‫db-n1-standard-1, db-perf-optimized-N-2. רשימה מלאה של סוגי המכונות הזמינים והמזהים שלהם לשימוש ב-Google Cloud CLI מופיעה במאמר סוגי מכונות במסמכי Cloud SQL ל-MySQL.

        במכונות שנוצרות באמצעות Google Cloud CLI נעשה כברירת מחדל שימוש במהדורת Cloud SQL ל-MySQL Enterprise Plus, שזמינים בה סוגים שונים של מכונות. אם רוצים להשתמש בסוג מכונה שזמין רק במהדורת Enterprise של Cloud SQL ל-MySQL, צריך להשתמש בדגל האופציונלי --edition=enterprise כדי לציין את המהדורה.

      • ‫REGION עם המזהה של האזור שבו רוצים לשמור את פרופיל החיבור.

        כברירת מחדל, מכונות חדשות שיוצרים באמצעות Google Cloud CLI משתמשות במהדורת Cloud SQL ל-MySQL Enterprise Plus. אם אתם מתכננים להשתמש ב-Cloud SQL ל-MySQL במהדורת Enterprise Plus, אתם צריכים לוודא שהאזור שלכם נתמך במהדורה הזו. מידע נוסף זמין במאמר בנושא תמיכה באזורים במהדורת Cloud SQL ל-MySQL Enterprise Plus. אפשר לשנות את המהדורה באמצעות הדגל האופציונלי --edition.

      • (אופציונלי) CONNECTION_PROFILE_NAME עם שם קריא לפרופיל הקישור. הערך הזה מוצג במסוף Google Cloud .
      • הגדרת רשת

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

        אם רוצים להשתמש בקישוריות של כתובת IP ציבורית, לא צריך להשתמש בדגלים נוספים. אם רוצים להשתמש בקישוריות של כתובות IP פרטיות עם VPC Network Peering או עם מנהרת SSH הפוכה, צריך לוודא שאתם עומדים בדרישות הרשת הנוספות הבאות להפעלת קישוריות של כתובות IP פרטיות, ולכלול דגלים נוספים בפקודה.

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

        • ‫Service Networking API מופעל. אפשר להפעיל את Service Networking API באמצעות מסוף Google Cloud .
        • יש לכם את הרשאת ה-IAM‏ servicenetworking.services.addPeering.
        • הגדרתם גישה לשירותים פרטיים בפרויקט, ולכן אתם צריכים את תפקיד ה-IAM‏ compute.networkAdmin.
        • יש בפרויקט לפחות רשת VPC אחת שלא נוצרה בשיטה הקודמת, או רשת VPC משותפת.
        • אם אתם משתמשים ב רשת VPC משותפת, אתם צריכים גם לבצע את הפעולות הבאות:
          • מפעילים את Service Networking API בפרויקט המארח.
          • מוסיפים את המשתמש לפרויקט המארח.
          • מקצים למשתמש את תפקיד ה-IAM‏ compute.networkAdmin בפרויקט המארח.

        אם רוצים להשתמש בקישוריות של כתובות IP פרטיות (עם קישור בין רשתות VPC שכנות או עם מנהרת SSH הפוכה במכונת Compute Engine וירטואלית), צריך לכלול את הדגלים הנוספים הבאים:

        • --no-enable-ip-v4: (אופציונלי) כדי לא להקצות כתובת IP ציבורית למופע היעד. יכול להיות שגם כתובת IP ציבורית וגם כתובת IP פרטית יוקצו למכונת היעד, אבל אם אתם משתמשים בקישוריות של כתובות IP פרטיות, יכול להיות שלא תרצו כתובת IP ציבורית.
        • --private-network: כדי להקצות כתובת IP פרטית למופע היעד, מציינים את השם של הענן הווירטואלי הפרטי (VPC) שבו רוצים להקצות כתובת IP פרטית.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --display-name=CONNECTION_PROFILE_NAME

      ‏Windows (PowerShell)

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --database-version=DATABASE_VERSION `
  --tier=TIER `
  --display-name=CONNECTION_PROFILE_NAME

      Windows‏ (cmd.exe)

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --database-version=DATABASE_VERSION ^
  --tier=TIER ^
  --display-name=CONNECTION_PROFILE_NAME

      אמורים לקבל תגובה שדומה לזו:

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
    2. משלימים את ההגדרה של תצורת הרשת.

      בהתאם לקישוריות הרשת שבה רוצים להשתמש, יכול להיות שיהיו שלבים נוספים שצריך לבצע לפני שיוצרים את משימת ההעברה.

    3. יוצרים את עבודת ההעברה.
      מריצים את הפקודה הבאה (כדי להרחיב את הקישור, לוחצים עליו):

      gcloud database-migration migration-jobs create

      בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. כלומר, יכול להיות שיעבור זמן מה עד שהפקודות יושלמו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • ‫MIGRATION_JOB_ID מחליפים במזהה שניתן לקריאה על ידי מכונה של משימת ההעברה. משתמשים בערך הזה כדי לעבוד עם משימות העברה באמצעות פקודות Google Cloud CLI או API של Database Migration Service.
      • ‫REGION עם מזהה האזור שבו רוצים לשמור את עבודת ההעברה.
      • ‫MIGRATION_JOB_NAME עם שם קריא של עבודת המיגרציה. הערך הזה מוצג ב-Database Migration Service במסוף Google Cloud .
      • ‫SOURCE_CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל חיבור המקור.
      • ‫DESTINATION_CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל החיבור ליעד.
      • ‫MIGRATION_JOB_TYPE בסוג של עבודת ההעברה. הערכים המותרים הם ONE_TIME או CONTINUOUS. מידע נוסף זמין במאמר סוגי העברה.
      • ‫PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES עם הנתיב לקובצי הגיבוי הפיזיים שמאוחסנים בתיקייה בקטגוריה של Cloud Storage. צריך להשתמש בפורמט הבא: gs://<bucket_name>/<path_to_backup_file_folder>.
      • הגדרת רשת

        אם אתם משתמשים בקישוריות של כתובות IP פרטיות עם VPC Network Peering או עם מנהרת SSH הפוכה, מוסיפים את הפלגים הבאים לפקודה:

        קישוריות של כתובות IP פרטיות באמצעות קישור בין רשתות VPC שכנות (peering)
        משתמשים בדגל --peer-vpc כדי לציין את שם הרשת שרוצים ליצור איתה שותפות.
        מנהרת SSH הפוכה במכונה וירטואלית ב-Compute Engine
        משתמשים בדגלים הבאים כדי לספק פרטים על הרשת ל-Compute Engine: --vm-ip, --vm-port, --vpc. אפשר גם להשתמש בדגל האופציונלי --vm כדי לציין את שם המכונה הווירטואלית.

        דוגמאות נוספות לשימוש מופיעות במאמר דוגמאות ל-Google Cloud CLI.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      ‏Windows (PowerShell)

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows‏ (cmd.exe)

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      אמורים לקבל תגובה שדומה לזו:

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    שלב 3ב. מתן ההרשאות הנדרשות לחשבון השירות של מופע Cloud SQL

    כשיוצרים את משימת ההעברה למופע חדש, Database Migration Service יוצר גם את מופע היעד ב-Cloud SQL. כדי להפעיל את ההעברה, צריך להקצות הרשאות ל-Cloud Storage עבור חשבון השירות של המופע.

    כדי לתת את ההרשאות ל-Cloud Storage לחשבון השירות שמשויך למופע היעד:

    1. אפשר למצוא את כתובת האימייל בחשבון השירות של מכונת Cloud SQL בדף הפרטים של מכונת Cloud SQL. הכתובת הזו משתמשת בפורמט הבא: <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com. מידע נוסף זמין במאמר הצגת פרטי מכונה במסמכי Cloud SQL.
    2. מוסיפים לחשבון השירות את תפקיד ה-IAM‏ Storage Object Viewer (roles/storage.objectViewer). במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים במסמכי העזרה של IAM מוסבר איך לנהל את הגישה באמצעות ניהול זהויות והרשאות גישה.

    שלב 3c. (אופציונלי) בדיקה של משימת ההעברה

    לפני שמריצים את משימת ההעברה, אפשר לבצע פעולת בדיקה כדי לוודא ש-Database Migration Service יכול להגיע לכל ישויות המקור והיעד הנדרשות. באמצעות ה-CLI של gcloud, אפשר לבדוק משימות העברה שנוצרו, אבל עדיין לא התחילו.

    המסוף

    במסוף Google Cloud , אפשר לבדוק רק משימות העברה בטיוטה שיוצרים באשף ליצירת משימות העברה. אם לא שמרתם את המשימה כטיוטה, אבל יצרתם אותה באופן מלא באשף, תוכלו לבצע את הבדיקה רק באמצעות Google Cloud CLI.

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

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

      אל 'משימות העברה'

    2. בכרטיסייה טיוטות, לוחצים על השם המוצג של משימת ההעברה שרוצים לסיים ליצור.

      ייפתח אשף ליצירת משימת העברה.

    3. בדף Test and create migration job (בדיקה ויצירה של משימת העברה), לוחצים על Test job (בדיקת המשימה). שירות Database Migration Service בודק עכשיו אם למופע היעד יש את כל ההרשאות הנדרשות, ואם הוא יכול להתחבר למסד הנתונים של המקור.
    4. כשהבדיקה מסתיימת, לוחצים על יצירה.

      עכשיו נוצרת משימת ההעברה והיא מוכנה להפעלה.

    gcloud

    לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

    • ‫MIGRATION_JOB_ID מחליפים במזהה של עבודת ההעברה.

      אם אתם לא יודעים מה המזהה, אתם יכולים להשתמש בפקודה gcloud database-migration migration-jobs list כדי להציג רשימה של כל משימות ההעברה באזור מסוים ולראות את המזהים שלהן.

    • ‫REGION עם המזהה של האזור שבו נשמר פרופיל החיבור.

    מריצים את הפקודה הבאה:

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

    ‏Windows (PowerShell)

    gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

    Windows‏ (cmd.exe)

    gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

    תוצאה

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

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

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

    שלב 3ד. התחלת משימת ההעברה

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

    כדי להתחיל בהעברת נתונים, מבצעים את השלבים הבאים:

    המסוף

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

      אל 'משימות העברה'

    2. בכרטיסייה משימות, לוחצים על השם המוצג של משימת ההעברה שרוצים להפעיל.

      ייפתח דף הפרטים של עבודת ההעברה.

    3. לוחצים על התחלה.
    4. בתיבת הדו-שיח, לוחצים על התחלה.

    gcloud

    לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

    • ‫MIGRATION_JOB_ID מחליפים במזהה של עבודת ההעברה.

      אם אתם לא יודעים מה המזהה, אתם יכולים להשתמש בפקודה gcloud database-migration migration-jobs list כדי להציג רשימה של כל משימות ההעברה באזור מסוים ולראות את המזהים שלהן.

    • ‫REGION עם המזהה של האזור שבו נשמר פרופיל החיבור.

    מריצים את הפקודה הבאה:

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

    ‏Windows (PowerShell)

    gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

    Windows‏ (cmd.exe)

    gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

    תוצאה

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

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

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


  • כדי להעביר למופע יעד קיים, צריך קודם ליצור ולהגדיר את מופע היעד.

    שלב 3א. הכנת מופע היעד

    כדי להגדיר את מכונת היעד של Cloud SQL, מבצעים את השלבים הבאים:

    1. יוצרים את מכונת היעד של Cloud SQL ל-MySQL. חשוב לוודא שאתם משתמשים במשאבי מחשוב וזיכרון מספיקים כדי לענות על צורכי ההעברה. מידע נוסף זמין במאמר בנושא יצירת מכונה במסמכי התיעוד של Cloud SQL.

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

    2. נותנים את ההרשאות של Cloud Storage לחשבון השירות שמשויך למופע היעד. החשבון הזה נוצר אחרי שיוצרים את מופע היעד.
      1. בדף הפרטים של מכונת Cloud SQL, מוצאים את כתובת האימייל של חשבון השירות של מכונת Cloud SQL. הכתובת הזו משתמשת בפורמט הבא: <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com. מידע נוסף זמין במאמר הצגת פרטי מכונה במסמכי Cloud SQL.
      2. מוסיפים לחשבון השירות את תפקיד ה-IAM‏ Storage Object Viewer (roles/storage.objectViewer). במאמר איך מנהלים את הגישה לפרויקטים, לתיקיות ולארגונים במסמכי העזרה של IAM מוסבר איך לנהל את הגישה באמצעות ניהול זהויות והרשאות גישה.
    3. יוצרים פרופיל חיבור ליעד עבור מכונת Cloud SQL.

      המסוף

      לא צריך ליצור את פרופיל החיבור ליעד. כשיוצרים משימת העברה במסוף Google Cloud , משתמשים במזהה של מופע היעד, והשירות Database Migration Service מנהל את פרופיל החיבור בשבילכם.

      ממשיכים לקטע יצירה והפעלה של משימת העברה.

      gcloud

      בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. כלומר, יכול להיות שיעבור זמן מה עד שהפקודות יושלמו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל החיבור.
      • ‫REGION עם המזהה של האזור שבו רוצים לשמור את פרופיל החיבור.
      • ‫DESTINATION_INSTANCE_ID במזהה המכונה של מכונת היעד.
      • (אופציונלי) CONNECTION_PROFILE_NAME עם שם קריא לפרופיל הקישור. הערך הזה מוצג במסוף Google Cloud .

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --cloudsql-instance=DESTINATION_INSTANCE_ID \
  --region=REGION \
  --display-name=CONNECTION_PROFILE_NAME

      ‏Windows (PowerShell)

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --cloudsql-instance=DESTINATION_INSTANCE_ID `
  --region=REGION `
  --display-name=CONNECTION_PROFILE_NAME

      Windows‏ (cmd.exe)

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --cloudsql-instance=DESTINATION_INSTANCE_ID ^
  --region=REGION ^
  --display-name=CONNECTION_PROFILE_NAME

      אמורים לקבל תגובה שדומה לזו:

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

    שלב 3ב. יצירה והרצה של משימת ההעברה

    המסוף

    הגדרת הגדרות לעבודת ההעברה

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

      אל 'משימות העברה'

    2. לוחצים על יצירת משימת העברה.

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

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

    3. בדף תחילת העבודה, מזינים את הפרטים הבאים:
      1. שם משימת ההעברה

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

      2. מזהה משימת ההעברה

        זהו מזהה שניתן לקריאה על ידי מכונה של עבודת ההעברה. משתמשים בערך הזה כדי לעבוד עם משימות העברה באמצעות פקודות או API של Google Cloud CLI של Database Migration Service.

      3. ברשימה מנוע מסד הנתונים של המקור, בוחרים באפשרות MySQL.

        השדה Destination database engine (המנוע של מסד הנתונים של היעד) מאוכלס באופן אוטומטי ואי אפשר לשנות אותו.

      4. בוחרים את האזור שבו שומרים את משימת ההעברה.

        Database Migration Service הוא מוצר אזורי לחלוטין, כלומר כל הישויות שקשורות למיגרציה (פרופילים של חיבור למקור וליעד, משימות מיגרציה, מסדי נתונים של היעד) צריכות להישמר באזור אחד. בוחרים את האזור בהתאם למיקום של השירותים שזקוקים לנתונים שלכם, כמו מכונות וירטואליות של Compute Engine או אפליקציות של App Engine, ושירותים אחרים. אחרי שבוחרים את אזור היעד, אי אפשר לשנות את הבחירה הזו.

    4. לוחצים על שמירה והמשך.

    ציון מידע על פרופיל החיבור למקור

    1. בדף Define a source, מבצעים את השלבים הבאים:
      1. בתפריט הנפתח פרופיל חיבור למקור, בוחרים את פרופיל החיבור למסד הנתונים של המקור.
      2. בקטע התאמה אישית של הגדרת הגיבוי המלא, לוחצים על עריכת ההגדרה.
      3. בחלונית Edit full dump configuration, בתפריט הנפתח Full dump method, בוחרים באפשרות Physical based.
      4. בקטע Provide your folder (ציון התיקייה), לוחצים על Browse (עיון), ואז בוחרים את התיקייה שאליה העליתם את קובץ ה-dump המלא (שלב 4 בקטע Prepare your source data (הכנת נתוני המקור)).
      5. לוחצים על Save.
    2. לוחצים על שמירה והמשך.

    בחירת מופע היעד ב-Cloud SQL

    1. בתפריט Type of destination instance (סוג מופע היעד), בוחרים באפשרות Existing instance (מופע קיים).
    2. בקטע Select destination instance, בוחרים את מכונת היעד.
    3. בודקים את המידע בקטע פרטי המופע ולוחצים על בחירה והמשך.
    4. כדי להעביר למסד נתונים קיים ביעד, שירות העברת מסדי נתונים מוריד את רמת המופע של היעד וממיר אותו לשכפול. כדי לציין שאפשר לבצע את ההורדה בבטחה, בחלון האישור מזינים את מזהה מופע היעד.
    5. לוחצים על אישור והמשך.

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

    בתפריט הנפתח Connectivity method (שיטת קישוריות), בוחרים שיטת קישוריות לרשת. השיטה הזו מגדירה איך מכונת Cloud SQL שנוצרה תתחבר למסד הנתונים של המקור. שיטות הקישוריות הנוכחיות לרשת כוללות רשימת היתרים של IP, מנהור SSH הפוך וקישור בין רשתות VPC שכנות (peering).

    אם רוצים להשתמש ב...ואז...
    שיטת הקישוריות לרשת של רשימת היתרים לכתובות IP, צריך לציין את כתובת ה-IP היוצאת של מופע היעד. אם מכונת Cloud SQL שיצרתם היא מכונה עם זמינות גבוהה, צריך לכלול את כתובות ה-IP היוצאות של המכונה הראשית ושל המכונה המשנית.
    שיטת הקישוריות לרשת של מנהרת SSH הפוכה, צריך לבחור את המכונה הווירטואלית (VM) של Compute Engine שתארח את המנהרה.

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

    מריצים את הפקודות ממכונה שיש לה קישוריות גם למסד הנתונים של המקור וגם ל- Google Cloud.
    שיטת הקישור בין רשתות VPC שכנות (peering) צריך לבחור את רשת ה-VPC שבה נמצאת מסד הנתונים של המקור. המופע של Cloud SQL יעודכן כדי להתחבר לרשת הזו.

    אחרי שבוחרים ומגדירים את קישוריות הרשת, לוחצים על הגדרה והמשך.

    בדיקה, יצירה והפעלה של עבודת ההעברה

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

    1. בדף Test and create migration job (בדיקה ויצירה של משימת העברה), לוחצים על Test job (בדיקת המשימה).

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

    2. כשבדיקת משימת ההעברה מסתיימת, לוחצים על יצירה והתחלת המשימה.

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

    gcloud

    כדי להגדיר את ההעברה ולהפעיל אותה:

    1. יוצרים את עבודת ההעברה.
      מריצים את הפקודה הבאה (כדי להרחיב את הקישור, לוחצים עליו):

      gcloud database-migration migration-jobs create

      בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. כלומר, יכול להיות שיעבור זמן מה עד שהפקודות יושלמו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • ‫MIGRATION_JOB_ID מחליפים במזהה שניתן לקריאה על ידי מכונה של משימת ההעברה. משתמשים בערך הזה כדי לעבוד עם משימות העברה באמצעות פקודות Google Cloud CLI או API של Database Migration Service.
      • ‫REGION עם מזהה האזור שבו רוצים לשמור את עבודת ההעברה.
      • ‫MIGRATION_JOB_NAME עם שם קריא של עבודת המיגרציה. הערך הזה מוצג ב-Database Migration Service במסוף Google Cloud .
      • ‫SOURCE_CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל חיבור המקור.
      • ‫DESTINATION_CONNECTION_PROFILE_ID עם מזהה שניתן לקריאה על ידי מכונה של פרופיל החיבור ליעד.
      • ‫MIGRATION_JOB_TYPE בסוג של עבודת ההעברה. הערכים המותרים הם ONE_TIME או CONTINUOUS. מידע נוסף זמין במאמר סוגי העברה.
      • ‫PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES עם הנתיב לקובצי הגיבוי הפיזיים שמאוחסנים בתיקייה בקטגוריה של Cloud Storage. צריך להשתמש בפורמט הבא: gs://<bucket_name>/<path_to_backup_file_folder>.
      • הגדרת רשת

        אם אתם משתמשים בקישוריות של כתובות IP פרטיות עם VPC Network Peering או עם מנהרת SSH הפוכה, מוסיפים את הפלגים הבאים לפקודה:

        קישוריות של כתובות IP פרטיות באמצעות קישור בין רשתות VPC שכנות (peering)
        משתמשים בדגל --peer-vpc כדי לציין את שם הרשת שרוצים ליצור איתה שותפות.
        מנהרת SSH הפוכה במכונה וירטואלית ב-Compute Engine
        משתמשים בדגלים הבאים כדי לספק פרטים על הרשת ל-Compute Engine: --vm-ip, --vm-port, --vpc. אפשר גם להשתמש בדגל האופציונלי --vm כדי לציין את שם המכונה הווירטואלית.

        דוגמאות נוספות לשימוש מופיעות במאמר דוגמאות ל-Google Cloud CLI.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      ‏Windows (PowerShell)

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows‏ (cmd.exe)

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      אמורים לקבל תגובה שדומה לזו:

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    2. מבטלים את הקידום של מכונת היעד ב-Cloud SQL.
      מריצים את הפקודה הבאה (כדי להרחיב את הקישור, לוחצים עליו):

      gcloud database-migration migration-jobs demote-destination

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • ‫MIGRATION_JOB_ID מחליפים במזהה של עבודת ההעברה.

        אם אתם לא יודעים מה המזהה, אתם יכולים להשתמש בפקודה gcloud database-migration migration-jobs list כדי להציג רשימה של כל משימות ההעברה באזור מסוים ולראות את המזהים שלהן.

      • ‫REGION עם המזהה של האזור שבו נשמר פרופיל החיבור.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration migration-jobs \
demote-destination MIGRATION_JOB_ID \
  --region=REGION

      ‏Windows (PowerShell)

      gcloud database-migration migration-jobs `
demote-destination MIGRATION_JOB_ID `
  --region=REGION

      Windows‏ (cmd.exe)

      gcloud database-migration migration-jobs ^
demote-destination MIGRATION_JOB_ID ^
  --region=REGION

      תוצאה

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

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: demote-destination
name: OPERATION_ID

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

    3. (אופציונלי) ביצוע בדיקה של עבודת העברה
      אתם יכולים להריץ בדיקה כדי לוודא ש-Database Migration Service יכול להגיע לכל ישויות המקור והיעד הנדרשות. מריצים את הפקודה הבאה (כדי להרחיב את הקישור, לוחצים עליו):

      gcloud database-migration migration-jobs verify

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • ‫MIGRATION_JOB_ID מחליפים במזהה של עבודת ההעברה.

        אם אתם לא יודעים מה המזהה, אתם יכולים להשתמש בפקודה gcloud database-migration migration-jobs list כדי להציג רשימה של כל משימות ההעברה באזור מסוים ולראות את המזהים שלהן.

      • ‫REGION עם המזהה של האזור שבו נשמר פרופיל החיבור.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

      ‏Windows (PowerShell)

      gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

      Windows‏ (cmd.exe)

      gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

      תוצאה

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

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

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

    4. מתחילים את משימת ההעברה.
      מריצים את הפקודה הבאה (כדי להרחיב את הקישור, לוחצים עליו):

      gcloud database-migration migration-jobs start

      לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

      • ‫MIGRATION_JOB_ID מחליפים במזהה של עבודת ההעברה.

        אם אתם לא יודעים מה המזהה, אתם יכולים להשתמש בפקודה gcloud database-migration migration-jobs list כדי להציג רשימה של כל משימות ההעברה באזור מסוים ולראות את המזהים שלהן.

      • ‫REGION עם המזהה של האזור שבו נשמר פרופיל החיבור.

      מריצים את הפקודה הבאה:

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

      ‏Windows (PowerShell)

      gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

      Windows‏ (cmd.exe)

      gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

      תוצאה

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

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

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

      כשמתחילים את משימת ההעברה, מכונת היעד של Cloud SQL עוברת למצב קריאה בלבד, שבו היא מנוהלת באופן מלא על ידי Database Migration Service. אחרי שהנתונים יועברו במלואם, תוכלו לקדם אותו למופע עצמאי.

      הערה: אפשר לעקוב אחרי התקדמות ההעברה וגם אחרי תקינות יעד המיגרציה באמצעות תכונות הניטור של Database Migration Service. ראו [מדדים של משימת העברה](/database-migration/docs/mysql/migration-job-metrics).

שלב 4. (אופציונלי) הפסקת ההעברה

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

שלב 5. סיום ההעברה

כשמשימת ההעברה מסתיימת בהצלחה, צריך לסיים את משימת ההעברה באחד מהשלבים הבאים:

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

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