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

אתם יכולים להעביר את מסדי הנתונים של MySQL ל-Cloud SQL באמצעות קובצי גיבוי פיזיים של מסדי נתונים שנוצרו באמצעות הכלי Percona XtraBackup for 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 או 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, והנתונים כוללים טבלאות גדולות במיוחד, מומלץ לבצע קודם גיבוי הרצה (dry-run) לנפח אחסון מקומי. כך תוכלו לוודא שאף קובץ גיבוי לא חורג ממגבלת האחסון של 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 שזהה לגרסת מכונת המקור או חדשה יותר. מידע נוסף זמין במאמר Server version and backup version comparison במסמכי התיעוד של 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. משאירים את הערך שנוצר אוטומטית בשדה Connection profile ID.
    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).
        • האישור שבו המכונה משתמשת כדי לאמת את שרת מסד הנתונים של המקור (אישור הלקוח).
        • המפתח הפרטי שמשויך לאישור הלקוח (מפתח הלקוח).
    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, בוחרים באפשרות Migrate to an existing destination instance.

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

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

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

    המסוף

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

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

      מעבר אל Migration jobs

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

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

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

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

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

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

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

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

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

      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 בקטע הכנת נתוני המקור).
      5. לוחצים על Save.
    2. לוחצים על שמירה והמשך.

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

    1. בדף Define a destination, בתפריט הנפתח Type of destination instance בוחרים באפשרות New instance. מגדירים את כל ההגדרות הרלוונטיות:
      1. בשדה Destination Instance ID, מזינים מזהה למכונה של Cloud SQL או משתמשים במזהה שנוצר אוטומטית.

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

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

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

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

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

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

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

      5. בתפריט Region מוצג אותו אזור שבחרתם בדף Get started.

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

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

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

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

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

      לוחצים על הצגת הגדרות אופציונליות, ואז:

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

        כברירת מחדל, מכונות שנוצרות באמצעות 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 שכנות (peering) או עם מנהרת 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 שכנות (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, מאתרים את כתובת האימייל של חשבון השירות של המכונה. הכתובת הזו משתמשת בפורמט הבא: <project-identifier>@gcp-sa-cloud-sql.. אפשר לקרוא מידע נוסף במאמר הצגת פרטי המכונה במסמכי התיעוד של 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 .

      מעבר אל Migration jobs

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

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

    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, מאתרים את כתובת האימייל של חשבון השירות של המכונה. הכתובת הזו משתמשת בפורמט הבא: <project-identifier>@gcp-sa-cloud-sql.. אפשר לקרוא מידע נוסף במאמר הצגת פרטי המכונה במסמכי התיעוד של Cloud SQL.
      2. מוסיפים לחשבון השירות את התפקיד צפייה באובייקט אחסון (roles/storage.objectViewer) ב-IAM. במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים שבמסמכי התיעוד של 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.

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

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

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

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

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

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

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

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

      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 בקטע הכנת נתוני המקור).
      5. לוחצים על Save.
    2. לוחצים על שמירה והמשך.

    בחירת מכונת היעד של Cloud SQL

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

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

    בתפריט הנפתח 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.

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

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

    1. בדף Test and create migration job, לוחצים על Test job.

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

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

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

    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 שכנות (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. סיום ההעברה

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

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

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