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

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

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

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

  1. מגדירים את מסד הנתונים של המקור כדי לאפשר ל-Database Migration Service לשכפל את הנתונים.
  2. מגדירים את הקישוריות לרשת בין מסד הנתונים של המקור לבין Google Cloud.
  3. מכינים ומגדירים את אשכול היעד הקיים של AlloyDB ל-PostgreSQL.
  4. יוצרים את פרופיל החיבור של המקור ואת משימת ההעברה הרציפה.
  5. מתחילים את משימת ההעברה הרציפה ועוקבים אחריה.
  6. מקַדמים את משימת ההעברה ומעבירים את האפליקציה לשימוש במסדי הנתונים החדשים.

עלויות

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

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

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

  1. צריך לבדוק אם נתיב ההעברה הזה יכול לתמוך באופן מלא בתרחיש שלכם. אפשר לעיין בדפים הבאים:
    • מקורות ויעדים נתמכים בדף סקירה כללית של התרחיש מפרט את כל גרסאות המקור והיעד הנתמכות.
    • מגבלות ידועות – תיאור של גבולות תפעוליים, סוגי נתונים נתמכים ומגבלות ביצועים. ‫Database Migration Service ל-AlloyDB ל-PostgreSQL תומך בהעברות רציפות.
  2. חשבו באיזה אזור אתם רוצים ליצור את אשכול היעד. ‫Database Migration Service הוא מוצר אזורי לחלוטין, כלומר כל הישויות שקשורות להעברה (פרופילי חיבור למקור, משימות העברה ואשכולות יעד) חייבות להיות באזור Google Cloud אחד.
  3. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

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

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

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

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

כדי לקבל את ההרשאות שנדרשות לביצוע העברות הומוגניות של PostgreSQL ל-AlloyDB ל-PostgreSQL באמצעות Database Migration Service, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הנדרשים בפרויקט:

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

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

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

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

  • datamigration.*
  • alloydb.clusters.get
  • alloydb.clusters.list
  • alloydb.clusters.update
  • alloydb.instances.get
  • alloydb.instances.list
  • alloydb.instances.update
  • alloydb.operations.get
  • alloydb.users.list
  • alloydb.users.get
  • alloydb.users.create
  • alloydb.users.update

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

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

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

  1. בוחרים ומגדירים את שיטת הקישוריות לרשת המקור.
  2. מגדירים את המכונה של מסד הנתונים במקור. באופן כללי, התהליך כולל את השלבים הבאים:
    1. מתקינים את התוסף pglogical של PostgreSQL (גרסה 2.2.1 ואילך) במסד הנתונים של המקור ובכל מסדי הנתונים שרוצים להעביר.
    2. מגדירים את הפרמטרים של PostgreSQL: מגדירים את wal_level = logical ומוודאים שהערכים של max_replication_slots,‏ max_wal_senders ו-max_worker_processes מתאימים.
    3. נותנים הרשאות רפליקציה למשתמש ההעברה, ומגדירים את pg_hba.conf כך שיאפשר חיבורים נכנסים מאשכול היעד של AlloyDB ל-PostgreSQL.

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

  3. יוצרים את פרופיל החיבור של המקור.

הכנה והגדרה של אשכול היעד

כשמעבירים לאשכול קיים של AlloyDB ל-PostgreSQL (למשל אשכול שהוקצה מראש על ידי צוות אחר או שמנוהל באמצעות Terraform), צריך לוודא שהאשכול עומד בכל הדרישות המוקדמות של Database Migration Service לפני שיוצרים את משימת ההעברה:

  1. מוכנות האשכול ומצב הנתונים:
    • אשכול היעד צריך להיות במצב RUNNABLE וצריך להיות לו מכונה ראשית פעילה.
    • האשכול צריך להיות באותו אזור ב- Google Cloud שבו נמצאים משימת ההעברה ופרופילי החיבור.
    • אפשר לשייך את האשכול רק למשימת העברה פעילה אחת בכל פעם.
    • אשכול היעד חייב להכיל רק את מסדי הנתונים של המערכת שמוגדרים כברירת מחדל (postgres,‏ template0,‏ template1) בלי טבלאות של משתמשים.
  2. הגדרת דגל לניהול מסד נתונים: מפעילים את הדגל alloydb.enable_pglogical באשכול היעד של AlloyDB ל-PostgreSQL. הדגל הזה נדרש לפענוח ולהטמעה של שכפול לוגי. במאמר הגדרת דגלים של מסדי נתונים שבמסמכי התיעוד של AlloyDB ל-PostgreSQL מוסבר איך לעדכן דגלים.
  3. פרטי כניסה והרשאות של משתמש במסד הנתונים: ודאו שחשבון המשתמש עם הרשאת האדמין postgres (או חשבון ייעודי להעברה עם התפקיד alloydbsuperuser) קיים באשכול היעד. ‫Database Migration Service מתחבר ליעד עם הרשאות ניהול כדי לנהל את המנויים לשכפול ולסנכרן סכימות.
  4. דרישות הקישוריות לרשת: מוודאים שהרשת של אשכול היעד מוגדרת בצורה תקינה לתקשורת עם מסד הנתונים של המקור, בהתאם לשיטת הקישוריות שבחרתם:
    • ‫Private Service Connect: אם באשכול היעד מופעל Private Service Connect, ודאו שהאשכול מוגדר עם חיבורי הרשת המתאימים של Private Service Connect ועם ניתוב שמגיע לרשת המקור. מידע נוסף זמין במאמר הגדרת Private Service Connect במסמכי התיעוד של AlloyDB ל-PostgreSQL.
    • קישור בין רשתות שכנות (Peering) של ענן וירטואלי פרטי (גישה לשירותים פרטיים / כתובת IP פרטית): באשכול היעד צריך להגדיר גישה לשירותים פרטיים ברשת של הענן הווירטואלי הפרטי (VPC) שמקושרת או מנותבת למסד הנתונים של המקור (למשל באמצעות Cloud VPN או Cloud Interconnect). מידע נוסף זמין במאמר הגדרת גישה לשירותים פרטיים במסמכי התיעוד של AlloyDB ל-PostgreSQL.
    • רשימת היתרים של כתובות IP ציבוריות: אם מסד הנתונים של המקור נגיש דרך האינטרנט הציבורי, ודאו שחומת האש של המקור מאפשרת חיבורים נכנסים מכתובת ה-IP היוצאת של המכונה הראשית של AlloyDB ל-PostgreSQL ביעד.
    • מנהרת SSH הפוכה או מכונה וירטואלית של שרת proxy ל-TCP: אם מסד הנתונים של המקור נמצא מחוץ ל- Google Cloud בלי קישור פרטי ישיר, ודאו שהמכונה הווירטואלית של Compute Engine (יעד מבוצר או שרת proxy ל-TCP) פרוסה ברשת משנה שאפשר להגיע אליה דרך רשת ה-VPC של אשכול היעד. למידע נוסף, קראו את המאמר שיטות עבודה ברשת.
  5. הודעה על הורדה בדרגה של המכונה הראשית ונעילת כתיבה:
    • במהלך תהליך ההעברה, Database Migration Service מוריד בדרגה את המכונה הראשית הקיימת ביעד, כדי שהיא תפעל כמנוי רפליקציה חיצוני. כדי לאשר את ההורדה בדרגה, צריך להזין את המזהה של אשכול היעד כשמגדירים את משימת ההעברה במסוף Google Cloud .
    • הורדת המכונה הראשית בדרגה לא מעבירה את מסדי הנתונים למצב קריאה בלבד, אבל צריך להימנע מפעולות כתיבה בטבלאות או במסדי נתונים שמשתתפים בהעברה כדי למנוע התנגשויות ברפליקציה ושינויים בנתונים. מידע נוסף זמין במאמר מגבלות על העברות לאשכולות יעד קיימים.

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

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

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

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

סיום ההעברה

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

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

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

מידע נוסף על התכונות ויכולות הניהול של AlloyDB ל-PostgreSQL. סקירה כללית על AlloyDB ל-PostgreSQL