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


בדף הזה מוסבר איך לבצע העברות מהירות ורציפות של נתונים הומוגניים מ-PostgreSQL ל-AlloyDB ל-PostgreSQL.

סקירה כללית

העברות מהירות הן תהליך העברה קל ורציף לתרחישים הומוגניים של PostgreSQL. כשמשתמשים בהעברות מהירות, Database Migration Service יכול להגדיר באופן אוטומטי את משאבי הרשת וההעברה העיקריים שצריך: חיבורי רשת, רשתות משנה, הגדרות של קישוריות פרטית עם ממשקי Private Service Connect, פרופילי חיבור ומשימות העברה רציפות.

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

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

  • העברה ממקורות שיש להם כתובת IP פרטית ברשת Google CloudVirtual Private Cloud (VPC), כמו מסדי נתונים בניהול עצמי ב-Compute Engine או מכונות של Cloud SQL ל-PostgreSQL שמופעלת בהן רשת פרטית.

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

  • העברות מהירות תומכות בקישוריות של ממשקי כתובות IP ציבוריות ו-Private Service Connect. אי אפשר להשתמש במנהרות SSH הפוכות בהעברות מהירות.

למידע נוסף על העברות מהירות, קראו את המאמר סקירה כללית על העברות מהירות במסמכי התיעוד הראשיים של Database Migration Service.

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

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

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

  3. מפעילים את ממשקי ה-API של Database Migration Service,‏ Compute Engine,‏ Network Connectivity Center ו-AlloyDB ל-PostgreSQL.

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

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

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

תפקידים והרשאות בפרויקט המקור

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

  • בחשבון המשתמש שמבצע את ההעברה:
  • לחשבון השירות של Database Migration Service בפרויקט היעד: Compute Network Viewer (roles/compute.networkViewer)

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

    service-DESTINATION_PROJECT_NUMBER@gcp-sa-datamigration.

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

ההרשאות הנדרשות (מקור)

כדי לבצע העברות הומוגניות בהפעלה מהירה באמצעות Database Migration Service, נדרשות ההרשאות הבאות:

בחשבון המשתמש שמבצע את ההעברה:

  • compute.networks.get
  • compute.networks.list
  • compute.networks.updatePolicy
  • compute.subnetworks.get
  • compute.subnetworks.list
  • compute.subnetworks.create
  • compute.subnetworks.use
  • compute.networkAttachments.create
  • compute.networkAttachments.get
  • compute.networkAttachments.list
  • compute.networkAttachments.update
  • compute.networkAttachments.use
  • compute.regionOperations.get
  • networkconnectivity.internalRanges.create
  • networkconnectivity.internalRanges.get
  • networkconnectivity.operations.get
  • resourcemanager.projects.getIamPolicy

בחשבון השירות של Database Migration Service בפרויקט היעד:

  • compute.networkAttachments.get

תפקידים והרשאות בפרויקט היעד

מקצים את התפקידים הבאים לחשבון המשתמש שמבצע את ההעברה בפרויקט ב- Google Cloud שבו נמצא מסד הנתונים היעד:

בנוסף, חשבון השירות של Database Migration Service בפרויקט היעד (service-DESTINATION_PROJECT_NUMBER@gcp-sa-datamigration.) צריך את התפקיד סוכן Database Migration Service (roles/datamigration.serviceAgent) בפרויקט היעד. התפקיד הזה מוקצה אוטומטית על ידי Google Cloud כשמפעילים את Database Migration Service API.

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

הרשאות נדרשות (יעד)

כדי לבצע העברות הומוגניות בהפעלה מהירה באמצעות Database Migration Service, נדרשות ההרשאות הבאות:

בחשבון המשתמש שמבצע את ההעברה:

  • datamigration.privateconnections.get
  • datamigration.privateconnections.list
  • datamigration.privateconnections.create
  • datamigration.migrationjobs.create
  • datamigration.migrationjobs.update
  • datamigration.migrationjobs.verify
  • datamigration.migrationjobs.start
  • datamigration.migrationjobs.get
  • datamigration.migrationjobs.fetchSourceObjects
  • datamigration.operations.get
  • datamigration.connectionprofiles.create
  • datamigration.connectionprofiles.get
  • datamigration.connectionprofiles.update
  • datamigration.locations.list
  • datamigration.locations.fetchStaticIps
  • alloydb.clusters.create
  • alloydb.clusters.get
  • alloydb.clusters.list
  • alloydb.clusters.update
  • alloydb.clusters.delete
  • alloydb.instances.create
  • alloydb.instances.get
  • alloydb.instances.list
  • alloydb.instances.update
  • alloydb.instances.delete
  • alloydb.operations.get
  • alloydb.users.list
  • alloydb.users.get
  • alloydb.users.create
  • alloydb.users.update
  • alloydb.users.delete
  • resourcemanager.projects.getIamPolicy

בחשבון השירות של Database Migration Service בפרויקט היעד:

  • alloydb.clusters.import
  • alloydb.instances.connect
  • alloydb.instances.executeSql

הגדרת מסד הנתונים של המקור

כדי להגדיר את מסד הנתונים של PostgreSQL כמקור:

  1. יוצרים חשבון משתמש ייעודי להעברה במכונה.
    • במקורות של Cloud SQL ל-PostgreSQL, קראו את המאמר יצירת משתמש במסמכי התיעוד של Cloud SQL.
    • למקורות אחרים, אפשר לעיין במסמכי התיעוד של ספק מסד הנתונים או במאמר יצירה וניהול של משתמשים במסמכי התיעוד של PostgreSQL.
  2. מקצים את ההרשאות הנדרשות לחשבון המשתמש הייעודי להעברה. מריצים את הפקודות הבאות לכל מסד נתונים שרוצים להעביר: 
    -- Grant the REPLICATION attribute
ALTER ROLE MIGRATION_USER REPLICATION;

-- Grant database-level permissions.
-- Repeat for each database you want to migrate.
GRANT CONNECT, CREATE ON DATABASE DATABASE_NAME TO MIGRATION_USER;

-- Grant schema-level usage.
-- Repeat for each schema in each database you want to migrate.
GRANT USAGE ON SCHEMA SCHEMA_NAME TO MIGRATION_USER;

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫MIGRATION_USER בשם של חשבון המשתמש להעברה.
    • ‫DATABASE_NAME בשם מסד הנתונים שרוצים להעביר.
    • ‫SCHEMA_NAME בשם הסכימה במסד הנתונים שרוצים להעביר.
  3. לחשבון המשתמש שמשמש להעברה צריכה להיות גישת בעלות לטבלאות שאתם מעבירים. כדי לתת את רמת הגישה הזו, מבצעים אחת מהפעולות הבאות:
    • רק למקורות שהם לא Cloud SQL ל-PostgreSQL: מקצים את התפקיד SUPERUSER ב-PostgreSQL לחשבון ההעברה.
    • בכל המקורות: מוסיפים את חשבון המשתמש להעברה לקבוצת המשתמשים שבבעלותה הטבלאות. מריצים את הפקודה הבאה: 
      -- Grant table ownership.
GRANT TABLE_OWNER_GROUP_NAME TO MIGRATION_USER;

      מחליפים את מה שכתוב בשדות הבאים:

      • TABLE_OWNER_GROUP_NAME בשם של קבוצת המשתמשים שבבעלותה כל טבלה שרוצים להעביר.
      • ‫MIGRATION_USER בשם של חשבון המשתמש להעברה.
  4. בטבלאות שאין בהן מפתחות ראשיים: Database Migration Service לא משכפל פעולות UPDATE או DELETE בטבלאות בלי מפתחות ראשיים במהלך שלב סימון הנתונים שהשתנו (CDC). אם רוצים לכלול פעולות כאלה ברפליקציה, צריך לשנות טבלאות ללא מפתחות ראשיים באמצעות REPLICA IDENTITY: 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY FULL;
ALTER TABLE TABLE_NAME REPLICA IDENTITY USING INDEX INDEX_NAME;

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫TABLE_NAME הוא שם הטבלה שאין בה מפתחות ראשיים.
    • ‫INDEX_NAME הוא האינדקס הייחודי שמאפשר לעקוב אחרי שורות מטבלאות בלי מפתחות ראשיים.
  5. קובעים את הגדרות הרפליקציה באמצעות דגלים לניהול מסד נתונים.

    מקורות בניהול עצמי

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

    1. מגדירים את הפרמטר wal_level לערך logical. מריצים את הפקודה הבאה: 
      ALTER SYSTEM SET wal_level = 'logical';
    2. מגדירים את הפרמטר wal_sender_timeout לערך 0. הערך הזה משבית את מנגנון הזמן הקצוב לתפוגה שמשמש לסיום חיבורי רפליקציה לא פעילים. מריצים את הפקודה הבאה: 
      ALTER SYSTEM SET wal_sender_timeout = 0;
    3. מגדירים את המספר המקסימלי של משבצות הרפליקציה באמצעות הפרמטר max_replication_slots. הפרמטר הזה צריך להיות מוגדר לפחות למספר מסדי הנתונים שאתם מעבירים בכל משימת העברה, בתוספת כמה רזרבות לסנכרון טבלאות.

      לדוגמה, אם אתם מעבירים 5 מסדי נתונים ויש 2 משימות העברה שנוצרו למכונה של המקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, בנוסף למספר משבצות השכפול שכבר השתמשתם בהן.

      כדי להגדיר את הפרמטר הזה, מריצים את הפקודה הבאה:

      ALTER SYSTEM SET max_replication_slots = NUMBER_OF_SLOTS;
       כאשר NUMBER_OF_SLOTS מייצג את המספר המקסימלי של משבצות שכפול.
    4. מגדירים את הפרמטר max_wal_senders לערך ששווה לפחות ל-max_replication_slots, בתוספת מספר השולחים שכבר נמצאים בשימוש במכונה.

      לדוגמה, אם הפרמטר max_replication_slots מוגדר לערך 10, ואתם כבר משתמשים ב-2 שולחים, מספר תהליכי השליחה של WAL שפועלים בו-זמנית יהיה 10 + 2 = 12.

      כדי להגדיר את הפרמטר הזה, מריצים את הפקודה הבאה:

      ALTER SYSTEM SET max_wal_senders = NUMBER_OF_SENDERS;
       כאשר NUMBER_OF_SENDERS מייצג את מספר התהליכים של שולח WAL שפועלים בו-זמנית.
    5. מגדירים את max_worker_processes לפחות למספר מסדי הנתונים שרוצים להעביר, בתוספת מספר ה-max_worker_processes שכבר נמצאים בשימוש במכונה. כדי להגדיר את הפרמטר הזה, מריצים את הפקודה הבאה: 
      ALTER SYSTEM SET max_worker_processes = NUMBER_OF_PROCESSES;
       כאשר NUMBER_OF_PROCESSES מייצג את מספר מסדי הנתונים שיועברו.

    מקורות של Cloud SQL ל-PostgreSQL

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

    1. מגדירים את הדגל cloudsql.logical_decoding לערך on. כדי שההגדרה תיכנס לתוקף, צריך להפעיל מחדש את המכונה.
    2. מגדירים את הפרמטר wal_sender_timeout בתור 0. הערך הזה משבית את מנגנון הזמן הקצוב לתפוגה שמשמש לסיום חיבורי רפליקציה לא פעילים.
    3. מגדירים את המספר המקסימלי של משבצות הרפליקציה באמצעות הפרמטר max_replication_slots. הערך של הפרמטר הזה צריך להיות לפחות מספר מסדי הנתונים שאתם מעבירים בכל משימת העברה, בתוספת כמה רזרבות לסנכרון טבלאות.

      לדוגמה, אם אתם מעבירים 5 מסדי נתונים ויש 2 משימות העברה שנוצרו למכונה של המקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, בנוסף למספר משבצות השכפול שכבר השתמשתם בהן.

    4. מגדירים את הפרמטר max_wal_senders לפחות לאותו ערך כמו max_replication_slots, בתוספת מספר השולחים שכבר נמצאים בשימוש במכונה.

      לדוגמה, אם הפרמטר max_replication_slots מוגדר לערך 10, ואתם כבר משתמשים ב-2 שולחים, מספר תהליכי השליחה של WAL שפועלים בו-זמנית יהיה 10 + 2 = 12.

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

יצירה והפעלה של העברה מהירה

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

המסוף

  1. נכנסים לדף Get started במסוף Google Cloud .

    עוברים לקטע "שנתחיל?"

  2. בתפריט Source engine, בוחרים באפשרות PostgreSQL.
  3. בתפריט Destination engine, בוחרים באפשרות AlloyDB ל-PostgreSQL.

    מופיע הקטע Introducing quick-start PostgreSQL migration.

  4. בקטע Introducing quick-start PostgreSQL migration, לוחצים על Start migration.

    נפתח הדף Migrate to AlloyDB ל-PostgreSQL.

  5. בקטע Configure migration, מבצעים את הפעולות הבאות:
    1. בתפריט Destination region, בוחרים את האזור של אשכול היעד ב-AlloyDB ל-PostgreSQL.
    2. בתיבה Migration prefix, מזינים מחרוזת שקל לקרוא, שתתווסף לשמות של כל ישויות ההעברה שנוצרו בשביל ההעברה המהירה: פרופילי חיבור, הגדרת חיבור מבודד, מחבר רשת ורשת המשנה שלו ומשימת העברה.
    3. בתפריט Connectivity type, בוחרים איך Database Migration Service יתחבר למסד הנתונים של המקור:
      • ‫Private IP: התחברות דרך רשת פרטית באמצעות ממשקי Private Service Connect. בתפריט Configuration type, בוחרים אחת מהאפשרויות הבאות:
        • ‫Existing connectivity configuration: בוחרים באפשרות הזו אם כבר יש לכם קובץ מצורף עם הרשת והגדרת קישוריות פרטית שמשתמשת בשיטת הממשקים של Private Service Connect. האפשרות הזו מתאימה במיוחד אם השתמשתם בעבר בהעברות מהירות ואתם רוצים להשתמש שוב באותם משאבי רשת.
        • הגדרת קישוריות חדשה: בוחרים באפשרות הזו כדי ליצור חיבור רשת חדש ואת רשת המשנה של חיבור הרשת ברשת ה-VPC של מסד הנתונים במקור. הגדרת הקישוריות הפרטית תיווצר באותו פרויקט שבו נמצא אשכול היעד.
      • כתובת IP ציבורית: התחברות דרך האינטרנט הציבורי באמצעות כתובת IP ציבורית סטטית ייעודית לתעבורה יוצאת. אם בפרויקט ובאזור היעד כבר קיימת הגדרה של קישוריות דרך IP ציבורי, השירות Database Migration Service משתמש בה שוב. אחרת, Database Migration Service ייצור הגדרה חדשה של קישור דרך IP ציבורי ויפיק כתובת IP יוצאת כשתמשיכו.
    4. לוחצים על Continue. אם מופיעה בקשה לאשר את יצירת משאבי הרשת, לוחצים על Configure & continue.
  6. בקטע Connect source מבצעים את הפעולות הבאות:
    1. אם בחרתם באפשרות Public IP בשלב הקודם, העתיקו את כתובת ה-IP היוצאת שמוצגת במסוף Google Cloud והוסיפו אותה ככלל חומת אש לתעבורה נכנסת או כרשומה ברשימת ההיתרים של כתובות ה-IP ברשת המקור (כמו pg_hba.conf או קבוצות אבטחה של ספק שירותי הענן), כדי לאפשר ל-Database Migration Service להתחבר.
    2. מזינים את שם המארח או את כתובת ה-IP של מסד הנתונים במקור. אם בחרתם באפשרות Private IP, הזינו את כתובת ה-IP הפרטית שאפשר להגיע אליה מרשת ה-VPC של המקור. אם בחרתם באפשרות Public IP, הזינו את כתובת ה-IP הציבורית של מסד הנתונים של המקור.
    3. מזינים את היציאה שמשמשת לגישה למארח. יציאת ברירת המחדל של PostgreSQL היא 5432.
    4. מזינים את שם המשתמש והסיסמה של החשבון הייעודי להעברה במסד הנתונים של המקור.
    5. בתפריט Encryption type, בוחרים אחת מהאפשרויות הבאות:
      • None: אם מסד הנתונים של המקור לא דורש חיבורים מוצפנים ב-SSL או ב-TLS.
      • חובה: אם מסד הנתונים של המקור דורש חיבורים מוצפנים ב-SSL או ב-TLS. באפשרות הזאת לא נדרש אימות של אישור.
    6. בתפריט Databases to migrate, לוחצים על Customize. משתמשים בחלונית הצדדית עם זיהוי מסדי נתונים מוטמעים כדי לבחור רק את מסדי הנתונים שרוצים להעביר ל-AlloyDB ל-PostgreSQL.
    7. לוחצים על Continue.
  7. בקטע Configure destination, אפשר ליצור אשכול יעד חדש או לבחור אשכול קיים:

    אשכולות חדשים

    כדי ליצור אשכול יעד חדש:

    1. בתפריט Destination instance type, בוחרים באפשרות New cluster.

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

    2. בשדה Password, מזינים סיסמה למשתמש עם הרשאת אדמין שמוגדר כברירת מחדל ב-postgres. ‫Database Migration Service מתחבר בתור המשתמש הזה כדי להעביר את הנתונים.

    אשכולות קיימים

    אתם יכולים להעביר מסדי נתונים לאשכול שכבר קיים. מוודאים שאשכול היעד מופעל ל-Private Service Connect, נמצא במצב RUNNABLE ולא אוכף mTLS עם מחברי AlloyDB. מבצעים את הפעולות הבאות:

    1. בתפריט Destination instance type, בוחרים באפשרות Existing cluster.
    2. בתפריט Existing cluster ID, בוחרים את מזהה האשכול.
  8. לוחצים על התחלת ההעברה.

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

gcloud

כדי ליצור ולהפעיל העברה מהירה באמצעות ה-CLI של gcloud:

  1. מגדירים את הקישוריות למסד הנתונים של המקור.
    בוחרים את הכרטיסייה בהתאם לכתובת ה-IP של מסד הנתונים של המקור – פרטית (Private Service Connect) או ציבורית:

    כתובת IP פרטית (Private Service Connect)

    כדי להתחבר באמצעות Private Service Connect, צריך להגדיר את החיבור הפרטי ואת מחבר הרשת:

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

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

        gcloud compute network-attachments create

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

        • ‫NETWORK_ATTACHMENT בשם של חיבור הרשת שרוצים ליצור.
        • ‫REGION עם האזור של מחבר הרשת.
        • ‫DEST_PROJECT_ID במזהה פרויקט היעד.
        • ‫SOURCE_PROJECT_ID במזהה הפרויקט שבו נמצאת רשת המקור.

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

        ‫Linux,‏ macOS או Cloud Shell

        gcloud compute network-attachments create NETWORK_ATTACHMENT \
  --region=REGION \
  --connection-preference=ACCEPT_MANUAL \
  --producer-accept-list=DEST_PROJECT_ID \
  --subnets=default \
  --project=SOURCE_PROJECT_ID

        ‏Windows (PowerShell)

        gcloud compute network-attachments create NETWORK_ATTACHMENT `
  --region=REGION `
  --connection-preference=ACCEPT_MANUAL `
  --producer-accept-list=DEST_PROJECT_ID `
  --subnets=default `
  --project=SOURCE_PROJECT_ID

        Windows‏ (cmd.exe)

        gcloud compute network-attachments create NETWORK_ATTACHMENT ^
  --region=REGION ^
  --connection-preference=ACCEPT_MANUAL ^
  --producer-accept-list=DEST_PROJECT_ID ^
  --subnets=default ^
  --project=SOURCE_PROJECT_ID
      • אם רוצים להשתמש מחדש במחבר רשת קיים, ממשיכים לשלב הבא.

    2. לאפשר לפרויקט של הדייר (tenant) ב-Database Migration Service לגשת למחבר הרשת: מחבר הרשת צריך לאפשר חיבורים מהפרויקט של הדייר ב-Database Migration Service. כך עושים את זה:

      1. כדי לאחזר את מזהה הפרויקט של הדייר (tenant) ב-Database Migration Service, מבצעים הרצה של יצירת חיבור פרטי (לחצו כדי להרחיב):

        gcloud database-migration private-connections create --validate-only

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

        • ‫PRIVATE_CONN בשם של משאב החיבור הפרטי.
        • ‫REGION עם האזור של החיבור הפרטי.
        • ‫NETWORK_ATTACHMENT_URI ב-URI של חיבור הרשת.

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

        ‫Linux,‏ macOS או Cloud Shell

        gcloud database-migration private-connections create PRIVATE_CONN \
  --region=REGION \
  --network-attachment=NETWORK_ATTACHMENT_URI \
  --display-name=PRIVATE_CONN \
  --format="value(metadata.metadata.tenant_project_id)" \
  --validate-only

        ‏Windows (PowerShell)

        gcloud database-migration private-connections create PRIVATE_CONN `
  --region=REGION `
  --network-attachment=NETWORK_ATTACHMENT_URI `
  --display-name=PRIVATE_CONN `
  --format="value(metadata.metadata.tenant_project_id)" `
  --validate-only

        Windows‏ (cmd.exe)

        gcloud database-migration private-connections create PRIVATE_CONN ^
  --region=REGION ^
  --network-attachment=NETWORK_ATTACHMENT_URI ^
  --display-name=PRIVATE_CONN ^
  --format="value(metadata.metadata.tenant_project_id)" ^
  --validate-only

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

      2. מאפשרים לפרויקט של הדייר ב-Database Migration Service ולפרויקט היעד להתחבר למחבר הרשת (לחצו כדי להרחיב):

        gcloud compute network-attachments update

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

        • ‫NETWORK_ATTACHMENT בשם של חיבור הרשת.
        • REGION עם האזור.
        • ‫DEST_PROJECT_ID במזהה פרויקט היעד.
        • ‫DMS_TENANT_ID במזהה הפרויקט של הדייר (tenant) ב-Database Migration Service שאחזרתם.
        • ‫SOURCE_PROJECT_ID במזהה הפרויקט שבו נמצאת רשת המקור.

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

        ‫Linux,‏ macOS או Cloud Shell

        gcloud compute network-attachments update NETWORK_ATTACHMENT \
  --region=REGION \
  --producer-accept-list=DEST_PROJECT_ID,DMS_TENANT_ID \
  --project=SOURCE_PROJECT_ID

        ‏Windows (PowerShell)

        gcloud compute network-attachments update NETWORK_ATTACHMENT `
  --region=REGION `
  --producer-accept-list=DEST_PROJECT_ID,DMS_TENANT_ID `
  --project=SOURCE_PROJECT_ID

        Windows‏ (cmd.exe)

        gcloud compute network-attachments update NETWORK_ATTACHMENT ^
  --region=REGION ^
  --producer-accept-list=DEST_PROJECT_ID,DMS_TENANT_ID ^
  --project=SOURCE_PROJECT_ID

    3. יוצרים את משאב הקישוריות הפרטית של Database Migration Service: מריצים את הפקודה הבאה (לוחצים כדי להרחיב):

      gcloud database-migration private-connections create

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

      • ‫PRIVATE_CONN בשם של משאב החיבור הפרטי.
      • ‫REGION עם האזור של החיבור הפרטי.
      • ‫NETWORK_ATTACHMENT_URI ב-URI של חיבור הרשת.

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

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration private-connections create PRIVATE_CONN \
  --region=REGION \
  --network-attachment=NETWORK_ATTACHMENT_URI \
  --display-name=PRIVATE_CONN

      ‏Windows (PowerShell)

      gcloud database-migration private-connections create PRIVATE_CONN `
  --region=REGION `
  --network-attachment=NETWORK_ATTACHMENT_URI `
  --display-name=PRIVATE_CONN

      Windows‏ (cmd.exe)

      gcloud database-migration private-connections create PRIVATE_CONN ^
  --region=REGION ^
  --network-attachment=NETWORK_ATTACHMENT_URI ^
  --display-name=PRIVATE_CONN

    כתובת IP ציבורית

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

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

      gcloud database-migration private-connections create

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

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

      • ‫CONNECTION_ID במזהה של החיבור הפרטי.
      • ‫REGION באזור שבו רוצים ליצור את החיבור הפרטי ( Google Cloud ).
      • ‫DISPLAY בשם תצוגה ידידותי לחיבור הפרטי.
      • אופציונלי: אפשר להחליף את הדגל --reserved-public-ip בדגל --reserved-public-ip-nat-ips-count כדי לשמור כמה כתובות IP ציבוריות ייעודיות שבהן Database Migration Service משתמש לחיבור. אפשר לשמור עד 10 כתובות IP.

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

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration private-connections create \
  CONNECTION_ID \
  --region=REGION \
  --display-name="DISPLAY" \
  --reserved-public-ip \
  --no-async

      ‏Windows (PowerShell)

      gcloud database-migration private-connections create `
  CONNECTION_ID `
  --region=REGION `
  --display-name="DISPLAY" `
  --reserved-public-ip `
  --no-async

      Windows‏ (cmd.exe)

      gcloud database-migration private-connections create ^
  CONNECTION_ID ^
  --region=REGION ^
  --display-name="DISPLAY" ^
  --reserved-public-ip ^
  --no-async

    2. אחזור כתובות ה-IP הציבוריות השמורות.
      מריצים את הפקודה הבאה (לוחצים כדי להרחיב):

      gcloud database-migration connection-profiles fetch-static-ips

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

      • ‫REGION באזור של החיבור הפרטי Google Cloud .

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

      ‫Linux,‏ macOS או Cloud Shell

      gcloud database-migration connection-profiles fetch-static-ips \
  REGION \
  --fetch-reserved-public-ips

      ‏Windows (PowerShell)

      gcloud database-migration connection-profiles fetch-static-ips `
  REGION `
  --fetch-reserved-public-ips

      Windows‏ (cmd.exe)

      gcloud database-migration connection-profiles fetch-static-ips ^
  REGION ^
  --fetch-reserved-public-ips

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

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

    gcloud database-migration connection-profiles create postgresql

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

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

    • ‫SOURCE_CONN_ID במזהה של פרופיל החיבור למקור.
    • ‫REGION באזור שבו רוצים לשמור את פרופיל החיבור.
    • ‫SOURCE_PRIVATE_IP בכתובת ה-IP הפרטית של מסד הנתונים במקור.
    • ‫SOURCE_PORT עם היציאה של מסד הנתונים של המקור (ברירת המחדל היא 5432).
    • ‫SOURCE_USER בשם המשתמש של המשתמש להעברה במסד הנתונים של המקור.
    • ‫SOURCE_PASSWORD בסיסמה של משתמש ההעברה במסד הנתונים של המקור.
    • ‫PRIVATE_CONN בשם של משאב החיבור הפרטי.

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

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration connection-profiles create postgresql \
  SOURCE_CONN_ID \
  --region=REGION \
  --role=SOURCE \
  --host=SOURCE_PRIVATE_IP \
  --port=SOURCE_PORT \
  --username=SOURCE_USER \
  --password=SOURCE_PASSWORD \
  --private-connection=PRIVATE_CONN \
  --no-async

    ‏Windows (PowerShell)

    gcloud database-migration connection-profiles create postgresql `
  SOURCE_CONN_ID `
  --region=REGION `
  --role=SOURCE `
  --host=SOURCE_PRIVATE_IP `
  --port=SOURCE_PORT `
  --username=SOURCE_USER `
  --password=SOURCE_PASSWORD `
  --private-connection=PRIVATE_CONN `
  --no-async

    Windows‏ (cmd.exe)

    gcloud database-migration connection-profiles create postgresql ^
  SOURCE_CONN_ID ^
  --region=REGION ^
  --role=SOURCE ^
  --host=SOURCE_PRIVATE_IP ^
  --port=SOURCE_PORT ^
  --username=SOURCE_USER ^
  --password=SOURCE_PASSWORD ^
  --private-connection=PRIVATE_CONN ^
  --no-async

  3. יוצרים את פרופיל החיבור של היעד.
    בוחרים את הכרטיסייה בהתאם לאשכול של AlloyDB ל-PostgreSQL שאליו רוצים להעביר את הנתונים – אשכול חדש או קיים:

    אשכולות חדשים

    כדי להשתמש באשכול יעד חדש להעברה מהירה, קודם צריך ליצור את האשכול ואת המכונה הראשית שלו באמצעות AlloyDB ל-PostgreSQL Google Cloud CLI, ואז ליצור את פרופיל החיבור ליעד. איך לעשות את זה?

    1. יצירת אשכול והמכונה הראשית שלו באמצעות AlloyDB ל-PostgreSQL Google Cloud CLI. חשוב להשתמש בדגל --enable-private-service-connect כדי להפעיל את אשכול היעד ל-Private Service Connect. העברות מהירות תומכות רק ביעדים שמופעל בהם Private Service Connect.
    2. יוצרים את פרופיל החיבור ליעד בשביל האשכול החדש. כדי לראות את פרטי הפקודה המלאים, מרחיבים את הקטע הבא.

      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 [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]

    אשכולות קיימים

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

    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 [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]

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

    gcloud database-migration migration-jobs create

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

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

    • ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
    • ‫REGION באזור שבו רוצים לשמור את משימת ההעברה.
    • ‫SOURCE_CONN_ID במזהה של פרופיל החיבור של המקור.
    • ‫DEST_CONN_ID במזהה של פרופיל החיבור ליעד.
    • ‫DATABASES_LIST ברשימה מופרדת בפסיקים של מסדי הנתונים שרוצים להעביר.

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

    ‫Linux,‏ macOS או Cloud Shell

    gcloud database-migration migration-jobs create \
  MIGRATION_JOB_ID \
  --region=REGION \
  --type=CONTINUOUS \
  --source=SOURCE_CONN_ID \
  --destination=DEST_CONN_ID \
  --use-postgres-native \
  --postgres-max-additional-subscriptions=10 \
  --databases-filter=DATABASES_LIST \
  --no-async

    ‏Windows (PowerShell)

    gcloud database-migration migration-jobs create `
  MIGRATION_JOB_ID `
  --region=REGION `
  --type=CONTINUOUS `
  --source=SOURCE_CONN_ID `
  --destination=DEST_CONN_ID `
  --use-postgres-native `
  --postgres-max-additional-subscriptions=10 `
  --databases-filter=DATABASES_LIST `
  --no-async

    Windows‏ (cmd.exe)

    gcloud database-migration migration-jobs create ^
  MIGRATION_JOB_ID ^
  --region=REGION ^
  --type=CONTINUOUS ^
  --source=SOURCE_CONN_ID ^
  --destination=DEST_CONN_ID ^
  --use-postgres-native ^
  --postgres-max-additional-subscriptions=10 ^
  --databases-filter=DATABASES_LIST ^
  --no-async

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

    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]

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

    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

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

סיום ההעברה

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

  1. עוצרים את כל פעולות הכתיבה במסד הנתונים של המקור. אפשר להעביר את מסד הנתונים של המקור למצב קריאה בלבד כדי לשמור על פונקציונליות השאילתות התפעוליות במהלך המעבר החד למערכת אחרת (cutover).
  2. קידום משימת ההעברה. בהעברות מסוג Quick Start, אפשר להמשיך לכתוב לאשכול היעד במהלך תהליך ההעברה. קידום משימת ההעברה רק מסיים את הרפליקציה, ולא משפיע על אשכול היעד.
  3. אופציונלי: בודקים את נתוני ההעברה כדי לוודא שהם מלאים ועקביים.

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