העברה של מסדי נתונים: מושגים ועקרונות (חלק 2)

Last reviewed 2025-04-29 UTC

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

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

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

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

מפרט סכימת היעד

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

חשוב לתת שם לסכימה. אפשרות אחת היא לתת את אותו שם לסכימת המקור ולסכימת היעד. עם זאת, למרות שהגישה הזו מפשטת את המעבר בין לקוחות, היא עלולה לבלבל משתמשים אם כלים מתחברים לסכימות של מסד הנתונים של המקור והיעד בו-זמנית – למשל, כדי להשוות נתונים. אם משתמשים בקובץ הגדרה כדי להפשיט את שם הסכימה, אז מתן שמות שונים לסכימות של מסד הנתונים של היעד מאלה של המקור מקל על ההבחנה בין הסכימות.

בהעברות של מסדי נתונים הטרוגניים, צריך ליצור סכימה לכל מסד נתונים של היעד. תהליך ההנדסה הזה יכול לכלול כמה איטרציות. לפני שמיישמים את ההעברה, יכול להיות שיהיה צורך לשנות עוד את הסכימות כדי להתאים אותן לתהליך ההעברה ולשינויים בנתונים.

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

העברה של שאילתות וסמנטיקה של ביצוע

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

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

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

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

תהליכי העברה

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

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

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

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

תהליכי חזרה למצב ראשוני

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

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

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

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

הכנת מעבר חזרה ממסדי נתונים של יעד למסדי נתונים של מקור דורשת מאמץ משמעותי. חשוב להחליט אם להטמיע ולבדוק תהליכי מעבר חזרה או להבין את ההשלכות של אי-ביצוע הפעולות האלה – כלומר, השבתה משמעותית.

ביצוע העברה של מסד נתונים

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

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

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

השלבים שמתוארים כאן מציגים גישה שאולי תצטרכו לשנות בהתאם לדרישות של תהליך העברת מסד הנתונים.

שלב 1: טעינה ראשונית

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

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

השלב הזה כולל את הפעולות הבאות:

  • לרשום את השעה במערכת מסד הנתונים רגע לפני שמתחילים בהעברת מסד הנתונים.
  • ביצוע תהליך מיגרציה של טעינה ראשונית ששולח שאילתות למערך הנתונים (מלא או חלקי) ממסדי הנתונים של המקור שצריך להעביר, והעברת מערך הנתונים. במודל של מסד נתונים רלציוני, תהליכי ההעברה של הטעינה הראשונית מבצעים שאילתות כמו SELECT * או שאילתות עם בחירה, הקרנה או שניהם. תהליך ההעברה מבצע שינוי בנתונים בהתאם להגדרות התהליך.

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

התוצאה של שלב הטעינה הראשונית היא העברה מלאה של מערך הנתונים הראשוני ממערכות מסדי הנתונים של המקור למערכות מסדי הנתונים של היעד. עם זאת, מסדי הנתונים של המקור והיעד עדיין לא מסונכרנים כי סביר להניח שהלקוחות שינו את מסדי הנתונים של המקור במהלך ההעברה. בשלב 2 מבצעים לכידה והעברה של השינויים האלה.

שלב 2: המשך ההעברה

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

השלב הזה כולל את הפעולות הבאות:

  • התחלת תהליכי ההעברה המתמשכים ממערכת מסד הנתונים הזמן שנרשם בשלב 1. תהליך ההעברה קורא את יומן העסקאות מאותו זמן ומחיל כל שינוי על מערכת מסד הנתונים של היעד.
  • ביצוע שינוי כלשהו בנתונים. תהליך ההעברה מבצע את השלב הזה בהתאם להגדרות שלכם.

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

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

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

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

שלב 3: ניקוז

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

השלב הזה כולל את הפעולות הבאות:

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

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

כדי לוודא שהריקון הושלם, אפשר לכתוב פריט נתונים מסוג 'הוספה אחרונה' במסד נתונים של מקור. כשהפריט הזה של נתוני 'ההוספה האחרונה' מופיע במסד הנתונים התואם של היעד, שלב הניקוז מסתיים.

שלב 4: מעבר

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

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

בסיום המעבר, הלקוחות פועלים באופן מלא ומתחילים לגשת למסדי נתונים של ייצור (מה שנקרא במסמך הזה מסדי נתונים של יעד עד לנקודה הזו).

שלב 5: מחיקה של מסד הנתונים של המקור

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

שלב 6: חזרה למצב הקודם

הטמעה של חלופה, במיוחד עבור לקוחות מסדי נתונים קריטיים, יכולה להיות אמצעי הגנה טוב מפני בעיות בהעברה. גיבוי הוא כמו העברה, אבל הפוכה. כלומר, עם חזרה למצב הקודם אתם מגדירים העברה ממסדי הנתונים של היעד בחזרה למסדי הנתונים של המקור. בהעברות של מסדי נתונים הטרוגניים, החזרה למצב הקודם היא מורכבת יותר. לכן מומלץ לבצע את המעבר רק אחרי בדיקה יסודית של תהליך העברת מסד הנתונים והאפליקציות שמחוברות למסד הנתונים של היעד, כדי לוודא שהם עומדים בהסכמי רמת השירות (SLA).

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

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

בגישה הזו, יש נסיבות מסוימות שדורשות תשומת לב מיוחדת:

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

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

שינויים דינמיים במהלך המיגרציה

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

שינויים בסכימה

אפשר לסווג מסדי נתונים למערכות שנדרשת בהן סכימה מוגדרת מראש, או למערכות ללא סכימה. באופן כללי, מערכות שדורשות סכימה מוגדרת מראש תומכות בפעולות של שינוי סכימה – לדוגמה, הוספה של מאפיינים או עמודות במערכת יחסית.

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

במערכות מסדי נתונים שלא נדרשת בהן סכימה מוגדרת מראש, אפשר לבצע שינויים בכל שלב. שינוי בסכימה לא יכול להתבצע רק על ידי משתמש מורשה, ובמקרים מסוימים הוא אפשרי באופן פרוגרמטי. במקרים כאלה, שינוי בסכימה יכול לקרות בכל שלב. פעולות שתלויות בסכימה עלולות להיכשל – לדוגמה, שאילתות או תהליכי העברת נתונים. כדי למנוע שינויים לא מבוקרים בסכימה במערכות מסדי נתונים כאלה, צריך להטמיע תהליך לניהול שינויים כהסכם וכלל מקובל, ולא באמצעות אכיפה על ידי המערכת.

שינויים בנתונים

באופן כללי, סכימות שולטות בערכי הנתונים האפשריים של מאפייני הנתונים השונים. במערכות ללא סכימה אין מגבלות על ערכי הנתונים.

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

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

שינויים בתהליך ההעברה

קשה ומורכב לנהל שינויים במהלך העברת נתונים של מסד נתונים, והדבר עלול לגרום לכשלים בהעברת הנתונים או לחוסר עקביות בנתונים. מומלץ לדחות את השינויים הנדרשים עד לסיום שלב הניקוז, שבו מערכות מסד הנתונים של המקור והיעד מסונכרנות. השינויים בשלב הזה מוגבלים למסדי הנתונים של היעד וללקוחות שלהם (אלא אם מיושם גם גיבוי).

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

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

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

צמצום הסיכון לכשל בהעברה

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

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

ככל שתקפידו לבצע בדיקות מציאותיות ומקיפות מראש, כך גדל הסיכוי שתמצאו בעיות פוטנציאליות שצריך לטפל בהן מראש.

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