תהליך ההעברה

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

ב-Database Migration Service אפשר לבצע העברות רציפות של מסדי נתונים הומוגניים סטנדרטיים של PostgreSQL ל-Cloud SQL. בהעברה רציפה, הנתונים הראשוניים נטענים מ-snapshot dump, ואז שינויי הנתונים המתמשכים משוכפלים באופן רציף מיומן הכתיבה מראש (WAL) של מסד הנתונים של המקור באמצעות פענוח לוגי והתוסף pglogical. כדי לבצע העברות רציפות בהפעלה מהירה, שירות Database Migration Service משתמש ב-pgnative.

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

העברות רציפות עוברות את השלבים הבאים:

העברות רגילות

  1. הגדרה ותזמור של הרפליקציה: כשיוצרים את משימת ההעברה, שירות Database Migration Service מגדיר את מכונת היעד של Cloud SQL ל-PostgreSQL כך שתפעל כרפליקה, ומגדיר מינויי רפליקציה באמצעות התוסף pglogical. כשמעבירים למכונה קיימת של Cloud SQL, ‏Database Migration Service מוריד את המכונה בדרגה כדי להגדיר אותה כרפליקה חיצונית (בלי להעביר את מסד הנתונים למצב קריאה בלבד).
  2. שלב תמונת המצב הראשונית: כשמתחילים את משימת ההעברה, Database Migration Service יוצר תמונת מצב עקבית של מסדי הנתונים שנבחרו במכונה של המקור. התהליך הזה נועל את הטבלה לזמן קצר (בדרך כלל פחות מ-10 שניות לכל טבלה) בזמן שהתמונה מאותחלת. מסד הנתונים של המקור ממשיך לקבל קריאות וכתיבות לאורך כל התהליך.
  3. שלב טעינת הנתונים: Database Migration Service מעביר בסטרימינג את נתוני תמונת המצב הראשונית ממסד הנתונים של המקור וטוען אותם למכונה של Cloud SQL ל-PostgreSQL ביעד.
  4. יצירת אילוצים ואינדקסים: אחרי שהנתונים נטענים בפעם הראשונה, נוצרים אילוצי טבלה (כולל מפתחות ראשיים ומפתחות זרים) ואינדקסים משניים במכונה של היעד. הפרדה בין טעינת הנתונים ליצירת האילוצים משפרת את מהירות הטמעת הנתונים.
  5. שלב סימון הנתונים שהשתנו (CDC): אחרי שהאילוצים מופעלים, Database Migration Service נכנס לשלב ה-CDC הרציף. במהלך ה-CDC, ‏Database Migration Service מתעד שינויים שוטפים ב-DML מזרם השכפול הלוגי של מסד הנתונים במקור באמצעות pglogical, ומחיל אותם על המכונה ביעד כמעט בזמן אמת.
  6. שלב המעבר החד למערכת אחרת (cutover) והקידום: כשמוכנים להעביר את תנועת הנתונים של האפליקציה למכונה ביעד, מפסיקים את פעולות הכתיבה במסד הנתונים במקור, מוודאים שהפיגור ברפליקציה מגיע לאפס ומתחילים את הקידום ב-Database Migration Service. במהלך הקידום, Database Migration Service מנתק את מכונת היעד מהמקור, מסיר את משבצות הרפליקציה והופך את היעד למכונה ראשית עצמאית לקריאה/כתיבה של Cloud SQL ל-PostgreSQL.

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

  1. הגדרה ותזמור של הרפליקציה: כשיוצרים את משימת ההעברה, Database Migration Service מגדיר באופן אוטומטי את הקישוריות לרשת באמצעות כתובות IP פרטיות, בעזרת ממשקי Private Service Connect (יוצר באופן אוטומטי הגדרות של קישוריות פרטית, קבצים מצורפים לרשת ורשתות משנה). הוא יוצר רפליקציה בין מסדי הנתונים של המקור והיעד באמצעות רפליקציה לוגית של PostgreSQL (עם pgnative), בלי שצריך להתקין את התוסף pglogical במקור או להוריד בדרגה את מכונת היעד. היעד יכול להיות מכונה פעילה שמשרתת תנועה למסדי נתונים אחרים.
  2. שלב תמונת המצב הראשונית: כשמתחילים את משימת ההעברה, Database Migration Service יוצר תמונת מצב עקבית של מסדי הנתונים שנבחרו (העברה של עד 50 מסדי נתונים לכל משימה) בשרת של מסד הנתונים במקור. מסד הנתונים של המקור ממשיך לקבל קריאות וכתיבות לאורך כל התהליך.
  3. שלב טעינת הנתונים: Database Migration Service מעביר בסטרימינג את נתוני תמונת המצב הראשונית ישירות למכונה של Cloud SQL ל-PostgreSQL ביעד, באמצעות קישוריות פרטית. הבעלות על אובייקטים של מסד נתונים ביעד מוקצית למשתמש ההעברה שנוצר על ידי Database Migration Service (כשמשתמשים במסוף Google Cloud ) או שצוין באמצעות Google Cloud CLI.
  4. יצירת אינדקסים ואילוצים: אחרי שהנתונים נטענים בפעם הראשונה, נוצרים אילוצים ואינדקסים משניים בטבלאות של מכונת היעד כדי לשמור על נאמנות לסכימה ולשפר את ביצועי ההטמעה.
  5. שלב סימון הנתונים שהשתנו (CDC): אחרי שהאילוצים מופעלים, Database Migration Service נכנס לשלב ה-CDC הרציף. במהלך ה-CDC, ‏Database Migration Service מעביר בסטרימינג שינויים שוטפים ב-DML מסטרימינג הרפליקציה הלוגית של pgnative PostgreSQL, ומחיל אותם על מכונת היעד כמעט בזמן אמת. בטבלאות בלי מפתחות ראשיים, אפשר לשכפל פעולות UPDATE ו-DELETE כשהזהות של הרפליקה של הטבלה מוגדרת ל-INDEX או ל-FULL.
  6. שלב המעבר החד למערכת אחרת (cutover) והקידום: כשמוכנים להעביר את תנועת הנתונים של האפליקציה למכונה ביעד, מפסיקים את פעולות הכתיבה למסד הנתונים במקור, מוודאים שהפיגור ברפליקציה מגיע לאפס ומתחילים את הקידום ב-Database Migration Service. במהלך הקידום, Database Migration Service משלים את הרפליקציה של ה-CDC, מסיים את משבצות הרפליקציה ומנתק את צינור עיבוד הנתונים של ההעברה, כך שמסדי הנתונים של Cloud SQL ל-PostgreSQL ביעד פועלים באופן מלא לחיבורי לקוחות.

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