תהליך ההעברה

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

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