מידע על העברות של קבוצות זמינות מבוזרות (DAG)

בנוסף לתהליך הרגיל של העברת נתונים באמצעות גיבוי ושחזור של Cloud Storage, ב-Database Migration Service אפשר להעביר מסדי נתונים של SQL Server בניהול עצמי ל-Cloud SQL ל-SQL Server באמצעות קבוצות זמינות מבוזרות (DAG) של SQL Server.

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

בדף הזה מפורטים הנושאים הבאים:

מתי כדאי להשתמש בהעברות של DAG

בטבלה הבאה מוצגת השוואה בין העברות רגילות של גיבוי ושחזור לבין העברות של קבוצות זמינות מבוזרות (DAG), כדי לעזור לכם לבחור את הגישה הכי טובה לעומס העבודה שלכם:

תכונה או דרישה העברות רגילות של גיבוי ושחזור (מדריך להעברת נתונים רגילה) העברות של קבוצות זמינות מבוזרות (DAG) (מדריך להעברת נתונים (מיגרציה) של DAG)
מקורות נתמכים ‫SQL Server בניהול עצמי, Amazon RDS ו-Cloud SQL ל-SQL Server. שרת SQL בניהול עצמי (מהדורת Enterprise) עם קבוצות זמינות של Always On.
מנגנון העברת הנתונים קבצים של גיבוי מלא (.bak), גיבוי דיפרנציאלי אופציונלי (.diff) ויומן טרנזקציות (.trn) שמוכנים ב-Cloud Storage. סטרימינג ישיר ברשת דרך נקודת קצה של שיקוף מסד נתונים של SQL Server (DBM) (לא נדרשים קובצי גיבוי או קטגוריות של Cloud Storage).
חיבור לרשת לא נדרשת קישוריות בין המקור ליעד. נדרש קישוריות דו-כיוונית של כתובת IP פרטית ביציאה של מסד הנתונים של SQL Server (ברירת המחדל היא 1433) וביציאה של שיקוף מסד הנתונים (ברירת המחדל היא 5022).
גישה למסד הנתונים של היעד במהלך ההעברה מסדי הנתונים נשארים במצב RESTORING (לא נגישים לשאילתות) עד לקידום. אפשר לגשת למסדי נתונים במצב קריאה בלבד במהלך שלב הרפליקציה הרציפה (CDC).
מעבר חזרה למצב קודם אחרי קידום לא נתמך (קידום חד-כיווני). רפליקציה הפוכה מובנית (שלב FAILBACK) מ-Cloud SQL ל-SQL Server בחזרה למכונה של SQL Server במקור אחרי הקידום, עם תמיכה במעבר לגיבוי בעת כשל (failback) ללא אובדן נתונים.

איך פועלת ההעברה של DAG

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

ערוצי תקשורת ברשת

ב-Database Migration Service נעשה שימוש בשני ערוצי תקשורת של רשת פרטית בין מכונת המקור של SQL Server לבין מכונת היעד של Cloud SQL ל-SQL Server:

  1. שרת מקושר של SQL Server (יציאת מסד נתונים, ברירת המחדל היא 1433): שירות Database Migration Service משתמש בשרת מקושר שמוגדר במכונה של Cloud SQL ל-SQL Server ביעד, כדי להריץ שאילתות ניהול ותזמור במכונה של SQL Server במקור.
  2. נקודת קצה (DBM) של שיקוף מסד נתונים (ברירת המחדל היא 5022): קבוצת הזמינות של המקור וקבוצת הזמינות של היעד ב-Cloud SQL ל-SQL Server מחליפות נתונים של טעינה מלאה ראשונית ושינויים שוטפים במסד הנתונים, שמאומתים באמצעות אישורים, ישירות דרך היציאה DBM.

שלבים במחזור החיים של ההעברה

משימת העברה של DAG עוברת ארבעה שלבים במחזור החיים:

  1. טעינה מלאה ראשונית (FULL_DUMP): כשמתחילים את משימת ההעברה, Database Migration Service מגדיר את קבוצת הזמינות המבוזרת להעביר בסטרימינג את העותק המלא הראשוני של כל מסדי הנתונים בקבוצת הזמינות של המקור דרך הרשת למכונה של Cloud SQL ל-SQL Server ביעד.
  2. רפליקציה רציפה (CDC): אחרי שכל מסד נתונים מסיים את הטעינה המלאה הראשונית, הוא עובר לשלב CDC. שינויים שמתבצעים במסדי הנתונים של המקור משוכפלים באופן רציף בנקודת הקצה של DBM, ואפשר להתחבר למכונה של Cloud SQL ל-SQL Server ביעד כדי להריץ שאילתות אימות לקריאה בלבד במסדי הנתונים שמשוכפלים.
  3. קידום ורפליקציה הפוכה (FAILBACK): כשמקַדמים את משימת ההעברה (promote בלי הדגל --failback), שירות Database Migration Service מסנכרן את שתי קבוצות הזמינות, מחליף את התפקידים שלהן כך שמכונת Cloud SQL ל-SQL Server ביעד הופכת ל-Primary לקריאה/כתיבה, ומכונת SQL Server המקורית הופכת ל-Secondary. בנוסף, השירות מעביר את שלב משימת ההעברה ל-FAILBACK (PHASE_FAILBACK בתגובה מה-API של Google Cloud CLI ו-API). בשלב FAILBACK, משימת ההעברה נשארת במצב Running ומשכפלת כתיבות חדשות מ-Cloud SQL ל-SQL Server בחזרה למכונה של SQL Server במקור.
  4. מעבר, עצירה או השלמה של החזרה למצב תקין (Stop ו-Delete):
    • אם אתם צריכים לבטל את המעבר החד למערכת אחרת (cutover) במהלך השלב FAILBACK, אתם יכולים להריץ את הפקודה promote עם הדגל --failback (failback = true ב-API) כדי לבצע מעבר חזרה (failback) ללא אובדן נתונים, שמשחזר את המכונה המקורית של SQL Server כמכונה הראשית, מוריד בדרגה את Cloud SQL ל-SQL Server בחזרה למכונה המשנית ומחזיר את משימת ההעברה לשלב CDC.
    • אפשר להריץ את stop כדי לעצור את הרפליקציה של הנתונים לפרק זמן קצר ומוגדר (העדכונים ממשיכים להצטבר ביומני הטרנזקציות בזמן שהרפליקציה נעצרת). במצב Stopped, אפשר להריץ את resume כדי להמשיך את שכפול הנתונים, או להריץ את delete כדי להשלים את ההעברה ולבצע את הניקוי הנדרש.
    • אחרי שמוודאים שהמעבר ל-Cloud SQL ל-SQL Server הוא קבוע, מוחקים (delete) את משימת ההעברה (ישירות או מהמצב Stopped). מחיקת משימת ההעברה משלימה את ההעברה, מסירה את קבוצת הזמינות המבוזרת ואת האישורים בשני המופעים, ומאפשרת להפעיל תכונות של Cloud SQL ל-SQL Server שנחסמות במהלך ההעברה, כמו שחזור מערכת מנקודה מסוימת בזמן (PITR) ועותקי קריאה.

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

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

  • מסדי נתונים של מקור: SQL Server Enterprise Edition בניהול עצמי (גרסאות 2017,‏ 2019,‏ 2022 ו-2025) עם התכונה Always On availability groups מופעלת (ב-Windows או ב-Linux).
  • מסדי נתונים של היעד: Cloud SQL ל-SQL Server מהדורת Enterprise (גרסאות 2017,‏ 2019,‏ 2022 ו-2025).

מגבלות ידועות בהעברות של DAG

לפני שמגדירים העברת DAG, חשוב להביא בחשבון את המגבלות הבאות:

  • אפשר ליצור פרופילי חיבור של DAG וליצור, לאמת, להתחיל, לקדם או למחוק משימות העברה של DAG רק באמצעות Google Cloud CLI או Database Migration Service API. אפשר לעקוב אחרי ההתקדמות של משימת ההעברה של DAG, הסטטוס של כל מסד נתונים והמדדים במסוף Google Cloud .
  • גם מכונת המקור של SQL Server וגם מכונת היעד של Cloud SQL ל-SQL Server צריכות להריץ את Enterprise Edition. מקורות ב-Amazon RDS וב-Cloud SQL ל-SQL Server לא נתמכים במיגרציות של DAG.
  • כל משימת העברה של DAG מעבירה את כל מסדי הנתונים שנמצאים בקבוצת זמינות אחת במקור (עד למגבלה של 100 מסדי נתונים לכל קבוצת זמינות מבוזרת). מסדי נתונים של המערכת (master,‏ model,‏ msdb,‏ tempdb) ומסד הנתונים של Database Migration Service‏ (gcp_dms_db) לא מועברים.
  • כל מסדי הנתונים בקבוצת הזמינות של המקור צריכים לאחסן את קובצי הנתונים שלהם (.mdf ו-.ndf) בספריית הנתונים שמוגדרת כברירת מחדל ב-SQL Server.
  • דרישות לגבי בעלות על מסד נתונים:
    • מסדי נתונים של מקור לא יכולים להיות בבעלות של פרטי הכניסה sa. לפני שמתחילים את משימת ההעברה, צריך לשנות את הבעלים של מסד הנתונים מ-sa להתחברות אחרת ל-SQL או למשתמש אחר ב-Windows.
    • אם מסד נתונים של מקור נמצא בבעלות של משתמש ב-Windows Active Directory, צריך לשנות את הבעלים של מסד הנתונים של המקור להתחברות ל-SQL לפני ההעברה, או לשלב את מכונת היעד של Cloud SQL ל-SQL Server עם Active Directory כדי ש-Database Migration Service יוכל ליצור באופן אוטומטי את ההתחברות התואמת ל-Windows במכונת היעד כשמשימת ההעברה מתחילה.
    • לבעלי מסדי נתונים עם אימות SQL, ‏Database Migration Service יוצר באופן אוטומטי פרטי כניסה תואמים במכונה של Cloud SQL ל-SQL Server ביעד, עם הקידומת gcp_dms_, מזהה באורך 6 תווים ושם הבעלים במקור (לדוגמה, gcp_dms_a1b2c3_myowner) כדי שיהיה הבעלים של מסד הנתונים שהועבר.
  • אין תמיכה בקישוריות IP ציבורית. אתם צריכים להגדיר קישוריות של כתובת IP פרטית בין מכונת המקור של SQL Server לבין מכונת היעד של Cloud SQL ל-SQL Server, באמצעות גישה לשירותים פרטיים או Private Service Connect.
  • הגבלות על Cloud SQL ל-SQL Server כיעד, בזמן שקיימת משימת העברה של DAG: מהרגע שמתחילים משימת העברה של DAG ועד שמוחקים אותה (כולל כשהמשימה נמצאת בשלב FAILBACK שאחרי הקידום):
    • צריך להשבית את האפשרות שחזור מערכת מנקודה מסוימת בזמן (PITR) במכונה של Cloud SQL ל-SQL Server ביעד.
    • אין תמיכה ברפליקות לקריאה בלבד ובמאגרי קריאה במכונה של Cloud SQL ל-SQL Server ביעד.
    • במכונה של Cloud SQL ל-SQL Server ביעד אין תמיכה בתחזוקה מתוכננת עם זמן השבתה כמעט אפסי.
    • אל תשנו ידנית את הדגל לניהול מסד הנתונים cloud sql enable dag support במכונה של Cloud SQL ל-SQL Server ביעד. Database Migration Service מפעיל את הדגל הזה באופן אוטומטי כשמשימת ההעברה מתחילה, ואתם יכולים להסיר אותו אחרי שאתם מוחקים את משימת ההעברה.
  • הוספה או הסרה של מסדי נתונים במהלך ההעברה:
    • אתם יכולים להוסיף או להסיר מסדי נתונים באופן דינמי בקבוצת הזמינות של המקור, בזמן שמשימת ההעברה נמצאת בשלב CDC. ‫Database Migration Service מזהה באופן אוטומטי מסדי נתונים חדשים שנוספו, מאמת אותם ומבצע את הטעינה המלאה הראשונית שלהם למכונה של Cloud SQL ל-SQL Server ביעד.
    • כשמסירים מסד נתונים מקבוצת הזמינות במקור, הרפליקציה של מסד הנתונים הזה נפסקת, הוא מוסר מהאובייקטים במעקב של משימת ההעברה, ומסד הנתונים נשאר במצב RESTORING במכונה של Cloud SQL ל-SQL Server ביעד (הוא לא משוחזר כשמקדמים את המשימה).
    • אי אפשר להוסיף מסדי נתונים חדשים ישירות למכונה של Cloud SQL ל-SQL Server ביעד במהלך שלב FAILBACK שאחרי הקידום (קבוצת הזמינות ביעד לא מתעדכנת במסדי נתונים חדשים שנוצרו ב-Cloud SQL).
  • אזהרות לגבי עצירה, המשך והפעלה מחדש של משימות העברת DAG:
    • כשעוצרים (stop) משימת העברה של DAG, שכפול הנתונים נעצר, וכתוצאה מכך עדכונים מצטברים ביומני העסקאות בזמן שהשכפול נעצר. עצרו את משימת ההעברה של DAG רק לפרק זמן קצר ומוגדר, כדי שהדיסקים של יומן הטרנזקציות לא יתמלאו. מהמצב Stopped, אתם יכולים להריץ את resume כדי להמשיך את שכפול הנתונים, או להריץ את delete כדי להשלים את ההעברה ולבצע את הניקוי הנדרש.
    • אם מפעילים מחדש (restart) משימת העברה של DAG שנכשלה או נעצרה, מסדי הנתונים שהועברו נמחקים במכונה של Cloud SQL ל-SQL Server ביעד, והטעינה המלאה הראשונית (FULL_DUMP) מופעלת מחדש ברשת.

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