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

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

מגבלות

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

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

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

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

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

  • חשוב להקפיד להעלות את קובצי הגיבוי לתיקייה ייעודית ב-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 או יוצרים אותו.

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

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (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 לחיבור בין מסדי הנתונים של המקור והיעד.

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

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

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

        כדי להשתמש באימות בצד השרת בלבד, צריך לספק את אישור ה-PEM בקידוד x509 של רשות האישורים (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 ייצור את מסד הנתונים של היעד, בוחרים באפשרות Migrate to a new destination instance.
  • אם רוצים להעביר למסד נתונים של יעד שנוצר מחוץ ל-Database Migration Service, בוחרים באפשרות העברה למופע יעד קיים.

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

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

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

    המסוף

    הגדרת משימת ההעברה

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

      מעבר אל Migration jobs

    2. לוחצים על Create migration job.

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

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

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

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

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

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

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

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

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

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

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

    מציינים מידע על פרופיל החיבור של המקור

    1. בדף Define a source, מבצעים את השלבים הבאים:
      1. בתפריט הנפתח Source connection profile, בוחרים את פרופיל החיבור של מסד הנתונים של המקור.
      2. בקטע Customize full dump configuration, לוחצים על Edit configuration.
      3. בחלונית Edit full dump configuration, בתפריט הנפתח Full dump method בוחרים באפשרות Physical based.
      4. בקטע Provide your folder (ציון התיקייה), לוחצים על Browse (עיון), ואז בוחרים את התיקייה שאליה העליתם את קובץ ה-dump המלא (שלב 3 בקטע Prepare your source data (הכנת נתוני המקור)).
      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, בוחרים באפשרות Public IP (כתובת IP ציבורית).

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

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

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

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

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

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

    4. מציינים את סוג האחסון של מכונת Cloud SQL. אתם יכולים לבחור כונן SSD או כונן קשיח (HDD).
    5. מציינים את נפח האחסון (ב-GB) של המכונה ב-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 הפוכה, צריך לבחור את המכונה הווירטואלית של Compute Engine שתארח את המנהרה.

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

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

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

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

    בדף Test and create migration job, מאמתים את ההגדרות של משימת ההעברה. בשלב הזה, בדיקת משימת ההעברה תיכשל כי לחשבון השירות שמשויך למכונה של יעד Cloud SQL אין את ההרשאות הנדרשות.

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

    • אם רוצים לבדוק את משימת ההעברה באמצעות מסוף Google Cloud אחרי שמקצים את ההרשאות לחשבון השירות של מכונת היעד, לוחצים על Save and exit. הפעולה הזו שומרת את עבודת ההעברה כטיוטה. אפשר לחזור למסך הזה מאוחר יותר, לבדוק את משימת ההעברה ולהפעיל אותה.
    • אם רוצים לבדוק את עבודת ההעברה באמצעות 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, ודאו שהאזור שלכם נתמך במהדורה הזו. מידע נוסף זמין במאמר בנושא תמיכה באזורים במהדורת 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. במאמר סוגי מכונות שבמסמכי התיעוד של Cloud SQL ל-MySQL מופיעה רשימה מלאה של סוגי המכונות הזמינים והמזהים שלהם לשימוש עם Google Cloud CLI.

        מופעים שנוצרו באמצעות Google Cloud CLI משתמשים כברירת מחדל במהדורת Cloud SQL ל-MySQL Enterprise Plus, שזמינים בה סוגים שונים של מכונות. אם רוצים להשתמש בסוג מכונה שזמין רק במהדורת Cloud SQL ל-MySQL Enterprise, משתמשים בדגל האופציונלי --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 שכנות (peering) או מנהרת SSH הפוכה, ודאו שאתם עומדים בדרישות הרשת הנוספות הבאות להפעלת קישוריות של כתובת IP פרטית, וכללו דגלים נוספים בפקודה.

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

        אם רוצים להשתמש בקישור דרך 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 כדי לציין את שם ה-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. מוסיפים לחשבון השירות את התפקיד צפייה באובייקט אחסון (roles/storage.objectViewer) ב-IAM. במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים שבמסמכי התיעוד של IAM מוסבר איך מנהלים את הגישה באמצעות ניהול זהויות והרשאות גישה.

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

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

    המסוף

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

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

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

      מעבר אל Migration jobs

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

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

    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 .

      מעבר אל Migration jobs

    2. לוחצים על Create migration job.

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

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

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

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

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

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

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

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

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

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

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

    מציינים מידע על פרופיל החיבור של המקור

    1. בדף Define a source, מבצעים את השלבים הבאים:
      1. בתפריט הנפתח Source connection profile, בוחרים את פרופיל החיבור של מסד הנתונים של המקור.
      2. בקטע Customize full dump configuration, לוחצים על Edit configuration.
      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. כדי להעביר למסד נתונים קיים ביעד, Database Migration Service מוריד את רמת הכיתוב של מופע היעד וממיר אותו לשכפול. כדי לאשר שאפשר לבצע את ההורדה בדרגה, מזינים את המזהה של מכונת היעד בחלון האישור.
    5. לוחצים על אישור והמשך.

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

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

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

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

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

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

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

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

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

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

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

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

    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 כדי לציין את שם ה-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. מדדים של משימות העברה

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

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

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

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

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

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