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

Last reviewed 2025-04-29 UTC

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

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

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

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

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

במסמך הזה מתוארת העברת מסד נתונים מנקודת מבט ארכיטקטונית:

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

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

ארכיטקטורה

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

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

שירות להעברת מסדי נתונים פועל בתוך Google Cloud ומקבל גישה למסד הנתונים של המקור ולמסד הנתונים של היעד. מוצגים שני תרחישים: (א) מראה העברה ממסד נתונים של מקור במרכז נתונים מקומי או בענן מרוחק למסד נתונים מנוהל כמו Spanner; (ב) מראה העברה למסד נתונים ב-Compute Engine.

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

הסברים על המונחים

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

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

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

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

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

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

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

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

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

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

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

שכפול לעומת העברה

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

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

במסמך הזה נדון רק בהעברת מסדי נתונים.

העברה חלקית לעומת העברה מלאה

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

העברה הטרוגנית לעומת העברה הומוגנית

העברת מסד נתונים הומוגנית היא העברה בין מסד הנתונים של המקור למסד הנתונים של היעד באותה טכנולוגיית מסד נתונים. לדוגמה, העברה ממסד נתונים של MySQL למסד נתונים של MySQL, או ממסד נתונים של Oracle®‎ למסד נתונים של Oracle. מיגרציות הומוגניות כוללות גם מיגרציות בין מערכת מסד נתונים באירוח עצמי, כמו PostgreSQL, לבין גרסה מנוהלת שלה, כמו Cloud SQL ל-PostgreSQL או AlloyDB ל-PostgreSQL.

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

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

העברה בין טכנולוגיות שונות של מסדי נתונים לא בהכרח כוללת מודלים שונים של נתונים. לדוגמה, Oracle,‏ MySQL,‏ PostgreSQL ו-Spanner תומכים במודל הנתונים הרלציוני. עם זאת, מסדי נתונים מרובי-מודלים כמו Oracle,‏ MySQL או PostgreSQL תומכים במודלים שונים של נתונים. אפשר להעביר נתונים שמאוחסנים כמסמכי JSON במסד נתונים מרובה-מודלים אל MongoDB בלי לבצע טרנספורמציה, או עם טרנספורמציה מינימלית, כי מודל הנתונים זהה במסד הנתונים של המקור ובמסד הנתונים של היעד.

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

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

זמן השבתה במהלך ההעברה: אפס לעומת מינימלי לעומת משמעותי

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

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

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

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

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

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

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

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

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

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

אבל מיפוי ישיר הוא לא האפשרות היחידה. דוגמאות לקרדינליות אחרות:

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

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

עקביות ההעברה

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

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

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

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

העברה פעילה-פסיבית לעומת העברה פעילה-פעילה

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

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

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

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

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

ארכיטקטורת פריסה

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

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

ארכיטקטורת העברה שכוללת מרכזי נתונים בענן ובארגון.

‫DB1 ו-DB2 הם שני מסדי נתונים של מקורות, ו-DB3 ו-Spanner הם מסדי הנתונים של היעד. במיגרציה הזו של מסד הנתונים מעורבים שני עננים ושני מרכזי נתונים מקומיים. החיצים מייצגים את יחסי ההפעלה: השירות להעברת מסדי נתונים מפעיל ממשקים של כל מסדי הנתונים של המקור והיעד.

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

יש שלוש גישות בסיסיות להעברת מסד נתונים, שמוסברות בקטע הזה:

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

מערכת להעברת מסדי נתונים היא הליבה של העברת מסדי נתונים. המערכת מבצעת את חילוץ הנתונים ממסדי הנתונים של המקור, מעבירה את הנתונים למסדי הנתונים של היעד, ויכולה גם לשנות את הנתונים במהלך ההעברה. בחלק הזה נדון בתכונות הבסיסיות של מערכת להעברת מסדי נתונים באופן כללי. דוגמאות למערכות להעברת מסדי נתונים כוללות את Database Migration Service,‏ Striim,‏ Debezium,‏ tcVision ו-Cloud Data Fusion.

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

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

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

חילוץ נתונים והוספה

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

‫CDC שמבוסס על יומן טרנזקציות

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

‫CDC היא הגישה המועדפת לתיעוד שינויים במערכת לניהול מסדי נתונים. ה-CDC מוטמע במסד הנתונים עצמו, וההשפעה שלו על עומס המערכת היא הכי נמוכה.

שאילתות דיפרנציאליות

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

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

למידע על וריאציות של שאילתות דיפרנציאליות, אפשר לעיין במאמר בנושא סימון נתונים שהשתנו (CDC).

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

מתאם וסוכן

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

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

שינוי נתונים

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

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

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

התאמת נתונים

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

  • טרנספורמציה של סוגי נתונים. לפעמים סוגי הנתונים במסד הנתונים של המקור ובמסד הנתונים של היעד לא זהים. במקרים כאלה, טרנספורמציה של סוגי נתונים ממירה את ערך המקור לערך היעד על סמך כללי טרנספורמציה של סוגים. לדוגמה, יכול להיות שחותמת זמן מהמקור תומר למחרוזת ביעד.
  • שינוי מבנה הנתונים. שינוי מבנה הנתונים משנה את המבנה באותו מודל מסד נתונים או בין מודלים שונים של מסדי נתונים. לדוגמה, במערכת יחסית, יכול להיות שטבלת מקור אחת תפוצל לשתי טבלאות יעד, או ששילוב של כמה טבלאות מקור יבוטל ויומר לטבלת יעד אחת באמצעות הצטרפות. יחס של 1:n במסד הנתונים של המקור יכול להפוך ליחס הורה-צאצא ב-Spanner. יכול להיות שמסמכים ממערכת מסד נתונים של מסמכי מקור יפורקו לקבוצה של שורות יחסיות במערכת יעד.
  • טרנספורמציה של ערכי נתונים.טרנספורמציה של ערכי נתונים היא נפרדת מטרנספורמציה של סוגי נתונים. טרנספורמציה של ערכי נתונים משנה את הערך בלי לשנות את סוג הנתונים. לדוגמה, אזור זמן מקומי מומר לזמן אוניברסלי מתואם (UTC). או מיקוד קצר (חמש ספרות) שמיוצג כמחרוזת מומר למיקוד ארוך (חמש ספרות ואחריהן מקף ו-4 ספרות, שנקרא גם ZIP+4).
העשרת נתונים ומתאם

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

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

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

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

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

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

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

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

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

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

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

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

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

יש כמה דרכים לשמור על הסטטוס:

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

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

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

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

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

אימות של השלמות והעקביות

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

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

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

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

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

יש שני סוגים של שכפול נתונים: לוגי ופיזי.

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

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

דוגמאות: שכפול MySQL, שכפול PostgreSQL (ראו גם pglogical) או שכפול Microsoft SQL Server.

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

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

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

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

אבני הבניין ליצירת תכונות להעברה כוללות את הרכיבים הבאים:

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

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

שיקולים נוספים לגבי מיגרציה של מסד נתונים

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

טיפול בשגיאות

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

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

מדרגיות

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

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

זמינות גבוהה ותוכנית התאוששות מאסון (DR)

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

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

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

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

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

טעויות נפוצות

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

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

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

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