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

כשמעבירים לאשכול יעד קיים של AlloyDB ל-PostgreSQL, ‏Database Migration Service מוריד את אשכול היעד בדרגה כדי להגדיר אותו כרפליקה חיצונית. הורדה בדרגה של אשכול לא מעבירה את AlloyDB ל-PostgreSQL למצב קריאה בלבד, אבל ביצוע פעולות מסוימות במהלך תהליך ההעברה עלול לגרום לשגיאות בהעברה. כשאתם מעבירים לאשכול יעד קיים, חשוב לזכור את השיקולים התפעוליים הבאים:
  • הורדה בדרגה של האשכול: השירות Database Migration Service מוריד בדרגה את אשכול היעד כדי להגדיר אותו כרפליקה של מסד הנתונים במקור.
  • הימנעו מפעולות כתיבה בנתונים שמועברים: אל תבצעו פעולות כתיבה (כמו INSERT,‏ UPDATE,‏ DELETE או שינויים בסכימת DDL) באשכול היעד בטבלאות או במסדי נתונים שנכללים בהעברה. פעולות כאלה עלולות לגרום להתנגשויות בשכפול עם נתונים שמגיעים מהמקור.
  • ניהול משתמשים במסד הנתונים: אתם יכולים ליצור ולנהל משתמשים במסד הנתונים בכל שלב באמצעות פקודות psql רגילות או באמצעות AlloyDB ל-PostgreSQL במסוף Google Cloud . מידע נוסף זמין במאמר ניהול משתמשים במסד נתונים במסמכי התיעוד של AlloyDB ל-PostgreSQL.

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

ב-Database Migration Service משתמשים במשימות העברה כדי להעביר נתונים ממסד הנתונים של המקור לאשכול היעד ב-AlloyDB ל-PostgreSQL. יצירת משימת העברה לאשכול יעד קיים כוללת:

  • הגדרת משימת ההעברה
  • הגדרת המקור ובחירת מסדי הנתונים להעברה
  • בחירת אשכול היעד הקיים של AlloyDB ל-PostgreSQL
  • הורדה בדרגה של האשכול הקיים כדי להגדיר אותו כרפליקה של מסד הנתונים של המקור
  • הגדרת הקישוריות בין מסדי הנתונים של המקור והיעד
  • בדיקת משימת ההעברה כדי לוודא שפרטי החיבור שסיפקתם תקינים

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

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

  1. מוודאים שסוג ההעברה הזה מתאים לתרחיש שלכם. לדוגמה, כשרוצים להעביר לאשכול שנוצר מחוץ ל-Database Migration Service, אשכול היעד של AlloyDB ל-PostgreSQL חייב להיות ריק או להכיל רק נתוני הגדרות של המערכת. לפרטים נוספים, ראו מגבלות ידועות.

  2. יוצרים את אשכול היעד של AlloyDB ל-PostgreSQL ואת המכונה הראשית שלו. מידע נוסף זמין במאמר יצירת אשכול והמכונה הראשית שלו במסמכי התיעוד של AlloyDB ל-PostgreSQL.

  3. מכינים את המכונה של מסד הנתונים במקור. אפשר לעיין בדפים הבאים:
    1. הגדרת מסד נתונים של מקור
    2. יצירת פרופיל החיבור של המקור
    3. הגדרת הקישוריות

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

המסוף

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

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

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

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

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

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

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

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

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

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

    3. ברשימה Source database engine, בוחרים באפשרות PostgreSQL.
    4. ברשימה Destination database engine, בוחרים באפשרות AlloyDB for PostgreSQL.
    5. בוחרים את האזור שבו שמרתם את משימת ההעברה.

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

    6. בוחרים באפשרות Continuous (תמונת מצב + שינויים שוטפים) כסוג העבודה של ההעברה. בהעברות הומוגניות ל-AlloyDB ל-PostgreSQL יש תמיכה רק בהעברות רציפות.
  4. לוחצים על שמירה והמשך.

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

בדף Define a source, מבצעים את הפעולות הבאות:

  1. בתפריט הנפתח Source connection profile, בוחרים את פרופיל החיבור של מסד הנתונים של המקור.
  2. בקטע Customize parallelism configurations, לוחצים על Show parallelism configurations.

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

    מהירות ההקבלה של ה-data dump קשורה לעומס שנוצר על מסד הנתונים של המקור:

    • אופטימלי (מומלץ): ביצועים מאוזנים עם עומס אופטימלי על מסד הנתונים של המקור. ‫Database Migration Service יוצר עד 2 מינויים לכל מסד נתונים (עד 2 בסך הכול בכל מסדי הנתונים, עם מינוי אחד לפחות לכל מסד נתונים שהועבר).
    • ‫Maximum: מספק את מהירויות ה-dump הגבוהות ביותר, אבל עלול לגרום לעומס מוגבר על מסד הנתונים של המקור. ‫Database Migration Service יוצר עד 4 מינויים לכל מסד נתונים (עד 4 בסך הכול בכל מסדי הנתונים, עם מינוי אחד לפחות לכל מסד נתונים שהועבר).
    • מינימלי: צורך את הכמות הנמוכה ביותר של משאבי מחשוב במסד הנתונים של המקור, אבל קצב העברת הנתונים של ה-dump עשוי להיות איטי יותר. ‫Database Migration Service יוצר מינוי אחד לכל מסד נתונים.

    אם בוחרים הגדרות מותאמות של מקביליות ב-data dump, חשוב להגדיל את הפרמטרים max_replication_slots,‏ max_wal_senders ו-max_worker_processes במסד הנתונים של המקור.

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

בחירת אשכול היעד של AlloyDB ל-PostgreSQL

  1. בתפריט Type of destination instance, בוחרים באפשרות Existing cluster.
  2. בקטע Select destination cluster, בוחרים את אשכול היעד של AlloyDB ל-PostgreSQL.

  3. בודקים את המידע בקטע Cluster details ולוחצים על Select and continue.

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

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

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

בתפריט הנפתח Connectivity method, בוחרים שיטת קישוריות לרשת. השיטה הזו מגדירה איך אשכול היעד של AlloyDB ל-PostgreSQL מתחבר למסד הנתונים של המקור. השיטות הנוכחיות לחיבור לרשת כוללות רשימת היתרים של כתובות IP, מנהרת SSH הפוכה, ממשקי Private Service Connect, קישור בין רשתות VPC שכנות ושרת proxy מסוג TCP דרך מכונה וירטואלית שמתארחת בענן.

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

אחרי שמציינים את המכונה, Google מספקת סקריפט שמבצע את השלבים להגדרת המנהרה בין מסדי הנתונים של המקור והיעד. מריצים את הסקריפט ב-Google Cloud CLI ממכונה שמחוברת גם למסד הנתונים של המקור וגם ל- Google Cloud.
שיטת הקישוריות של ממשקי Private Service Connect, ‫Database Migration Service יוצר באופן אוטומטי את החיבורים הנדרשים. שיטת הקישוריות הזו זמינה רק אם יש לכם אשכול יעד עם חיבור לרשת שמופעל בו Private Service Connect. מידע נוסף על Private Service Connect מופיע במאמר הגדרת Private Service Connect במסמכי התיעוד של AlloyDB ל-PostgreSQL.
שיטת הקישוריות לרשת VPC Peering, בוחרים את רשת ה-VPC שבה נמצא מסד הנתונים של המקור. אשכול AlloyDB ל-PostgreSQL מתחבר לרשת הזו באמצעות גישה לשירותים פרטיים.
שיטת הקישוריות של שרת proxy ל-TCP דרך VM שמתארח בענן, מזינים את הפרטים הנדרשים למכונה הווירטואלית החדשה של Compute Engine שתארח את שרת ה-proxy ל-TCP.

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

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

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

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

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

  1. ברשימה Databases to migrate, בוחרים אחת מהאפשרויות הבאות:
    • ‫All databases: בחירה בכל מסדי הנתונים שקיימים במקור.
    • מסדי נתונים ספציפיים: מאפשר לבחור מסדי נתונים ספציפיים מכל מסדי הנתונים שקיימים במקור.

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

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

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

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

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

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

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

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

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

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

  3. עוברים אל בדיקת משימת ההעברה.

Google Cloud CLI

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

  1. יוצרים את פרופיל החיבור של היעד.
    כדי ליצור את פרופיל החיבור של אשכול היעד הקיים, מריצים את הפקודה gcloud database-migration connection-profiles create (לוחצים על הקישור כדי להרחיב):

    gcloud database-migration connection-profiles create postgresql

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

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

    • ‫DEST_CONN_ID במזהה של פרופיל החיבור ליעד.
    • ‫REGION באזור שבו רוצים לשמור את פרופיל החיבור. האזור הזה צריך להיות זהה לאזור של אשכול היעד.
    • ‫DEST_CLUSTER עם המזהה של אשכול היעד של AlloyDB ל-PostgreSQL שיצרתם מראש.
    • ‫DEST_USER עם שם המשתמש של המשתמש להעברה במסד הנתונים של היעד.
    • ‫DEST_PASSWORD מחליפים בסיסמה של משתמש ההעברה במסד הנתונים של היעד.

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

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID \
  --region=REGION \
  --alloydb-cluster=DEST_CLUSTER \
  --username=DEST_USER \
  --password=DEST_PASSWORD \
  --role=DESTINATION \
  --no-async

    ‏Windows (PowerShell)

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID `
  --region=REGION `
  --alloydb-cluster=DEST_CLUSTER `
  --username=DEST_USER `
  --password=DEST_PASSWORD `
  --role=DESTINATION `
  --no-async

    Windows‏ (cmd.exe)

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID ^
  --region=REGION ^
  --alloydb-cluster=DEST_CLUSTER ^
  --username=DEST_USER ^
  --password=DEST_PASSWORD ^
  --role=DESTINATION ^
  --no-async

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

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

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

Created connection profile DEST_CONN_ID [OPERATION_ID]

  2. יוצרים את משימת ההעברה.
    הדוגמה הבאה מייצגת תרחיש מיגרציה שבו משתמשים בקישור דרך IP פרטית בין מסדי הנתונים של המקור והיעד. אם אתם משתמשים בסוג קישוריות אחר (לדוגמה, רשימת היתרים של כתובות IP, קישור VPC או מנהרת SSH הפוכה), הקפידו להוסיף את הדגלים הנדרשים, כמו --static-ip, --peer-vpc או --vm, --vm-ip, --vm-port ו---vpc. למידע נוסף, קראו את המאמרים הגדרת קישוריות ודוגמאות ל-Google Cloud CLI.
    מריצים את הפקודה הבאה (לוחצים על הקישור כדי להרחיב):

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

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

      לדוגמה: --databases-filter=my-business-database,my-other-database

      אפשר לערוך בהמשך את משימות ההעברה שנוצרו באמצעות הדגל --databases-filter, באמצעות הפקודה gcloud database-migration migration-jobs update.

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

    ‫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=CONTINUOUS

    ‏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=CONTINUOUS

    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=CONTINUOUS

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

    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. הורדה בדרגה של מסד הנתונים ביעד
    כדי להגדיר את אשכול היעד הקיים כרפליקה חיצונית, צריך להוריד אותו בדרגה ב-Database Migration Service לפני שמתחילים את משימת ההעברה. מריצים את הפקודה gcloud database-migration migration-jobs demote-destination (לוחצים על הקישור כדי להרחיב):

    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

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

  4. אופציונלי: מאמתים את משימת ההעברה.
    בשלב הזה, משימת ההעברה מוגדרת ומחוברת לאשכול היעד. אפשר לנהל אותו באמצעות הפעולות verify,‏ start,‏ stop,‏ restart ו-resume. מומלץ קודם לאמת את משימת ההעברה על ידי הרצת הפקודה gcloud database-migration migration-jobs verify (צריך ללחוץ על הקישור כדי להרחיב):

    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

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

  5. מתחילים את משימת ההעברה.
    מפעילים את משימת ההעברה באמצעות הפקודה gcloud database-migration migration-jobs start (לוחצים על הקישור כדי להרחיב):

    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

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

  6. קידום משימת ההעברה
    אחרי שההעברה מגיעה לשלב של סימון נתונים שהשתנו (CDC), אפשר לקדם את אשכול היעד מרפליקה לאשכול ראשי עצמאי. מריצים את הפקודה gcloud database-migration migration-jobs promote (לוחצים על הקישור כדי להרחיב):

    gcloud database-migration migration-jobs promote

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

    • ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.

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

    • REGION במזהה של האזור שבו נשמרת משימת ההעברה.

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

    ‫Linux,‏ macOS או Cloud Shell

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

    ‏Windows (PowerShell)

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

    Windows‏ (cmd.exe)

    gcloud database-migration migration-jobs ^
promote 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: promote
name: OPERATION_ID

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