במסמך הזה מוסברים המושגים, העקרונות, המינוח והארכיטקטורה של העברת מסדי נתונים עם זמן השבתה כמעט אפסי לאדריכלי ענן שמעבירים מסדי נתונים אל 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) מוסבר על גישות נוספות.
אלה רק כמה מהאפשרויות האפשריות לבניית העברה של מסד נתונים בהתאמה אישית. פתרון מותאם אישית מספק את הגמישות והשליטה הכי גדולות בהטמעה, אבל הוא גם דורש תחזוקה שוטפת כדי לטפל בבאגים, במגבלות על יכולת ההרחבה ובבעיות אחרות שעלולות לצוץ במהלך העברת מסד נתונים.
שיקולים נוספים לגבי מיגרציה של מסד נתונים
בקטעים הבאים נדון בקצרה בהיבטים לא פונקציונליים שחשובים בהקשר של העברת מסדי נתונים. ההיבטים האלה כוללים טיפול בשגיאות, יכולת הרחבה, זמינות גבוהה והתאוששות מאסון.
טיפול בשגיאות
תקלות במהלך העברת מסד הנתונים לא יכולות לגרום לאובדן נתונים או לעיבוד של שינויים במסד הנתונים שלא לפי הסדר. תקינות הנתונים חייבת להישמר בלי קשר לגורם לכישלון (למשל באג במערכת, שיבוש ברשת, קריסת VM או כשל באזור).
אובדן נתונים מתרחש כשמערכת העברה מאחזרת את הנתונים ממסדי הנתונים של המקור ולא מאחסנת אותם במסדי הנתונים של היעד בגלל שגיאה כלשהי. כשנתונים אובדים, מסדי הנתונים של היעד לא תואמים למסדי הנתונים של המקור, ולכן הם לא עקביים ולא מלאים. תכונת האימות של השלמות והעקביות מסמנת את המצב הזה (אימות של השלמות והעקביות).
מדרגיות
במיגרציה של מסד נתונים, הזמן שנדרש למיגרציה הוא מדד חשוב. בהעברה ללא השבתה (במובן של השבתה מינימלית), העברת הנתונים מתבצעת בזמן שמסדי הנתונים של המקור ממשיכים להשתנות. כדי להעביר את הנתונים בפרק זמן סביר, קצב העברת הנתונים צריך להיות מהיר משמעותית מקצב העדכונים של מערכות מסדי הנתונים של המקור, במיוחד אם מערכת מסד הנתונים של המקור גדולה. ככל שקצב ההעברה גבוה יותר, כך אפשר להשלים את העברת מסד הנתונים מהר יותר.
אם מערכות מסד הנתונים של המקור מושבתות ולא מתבצעים בהן שינויים, יכול להיות שההעברה תהיה מהירה יותר כי לא צריך לשלב שינויים. במסד נתונים הומוגני, הזמן שנדרש להעברה עשוי להיות קצר מאוד כי אפשר להשתמש בתכונות של גיבוי ושחזור או ייצוא וייבוא, והעברת הקבצים ניתנת להרחבה.
זמינות גבוהה ותוכנית התאוששות מאסון (DR)
באופן כללי, מסדי הנתונים של המקור והיעד מוגדרים לזמינות גבוהה. למסד נתונים ראשי יש עותק לקריאה תואם שמועלה להיות מסד הנתונים הראשי כשמתרחשת תקלה.
אם אזור נכשל, מסדי הנתונים של המקור או היעד עוברים לאזור אחר כדי להיות זמינים באופן רציף. אם מתרחשת כשל באזור במהלך העברה של מסד נתונים, המערכת להעברת נתונים מושפעת כי לא ניתן לגשת לכמה ממסדי הנתונים של המקור או היעד שהיא ניגשת אליהם. מערכת ההעברה צריכה להתחבר מחדש למסדי הנתונים הראשיים החדשים שודרגו ופועלים אחרי כשל. אחרי שמערכת העברת מסד הנתונים מתחברת מחדש, היא צריכה לשחזר את ההעברה עצמה כדי להבטיח את השלמות והעקביות של הנתונים במסדי הנתונים של היעד. מערכת ההעברה צריכה לקבוע את ההעברה העקבית האחרונה כדי לדעת מאיפה להמשיך.
אם מערכת העברת מסד הנתונים עצמה נכשלת (לדוגמה, אם האזור שבו היא פועלת הופך ללא נגיש), צריך לשחזר אותה. אחת מהגישות לשחזור היא הפעלה מחדש קרה. בגישה הזו, מערכת העברת מסד הנתונים מותקנת באזור תפעולי ומופעלת מחדש. הבעיה הכי גדולה שצריך לטפל בה היא שהמערכת להעברת נתונים צריכה להיות מסוגלת לקבוע את העברת הנתונים העקבית האחרונה לפני הכשל, ולהמשיך מאותה נקודה כדי להבטיח שהנתונים במסדי הנתונים של היעד יהיו מלאים ועקביים.
אם מערכת העברת מסד הנתונים מופעלת לזמינות גבוהה, היא יכולה לבצע מעבר לגיבוי ולחדש את העיבוד לאחר מכן. אם חשוב לכם לצמצם את זמן ההשבתה של מערכת העברת מסד הנתונים, אתם צריכים לבחור מסד נתונים ולהטמיע זמינות גבוהה.
במונחים של שחזור העברת מסד הנתונים, התאוששות מאסון דומה מאוד לזמינות גבוהה. במקום להתחבר מחדש למסדי נתונים ראשיים חדשים שהועלו בדרגה באזור אחר, מערכת העברת מסדי הנתונים צריכה להתחבר מחדש למסדי נתונים באזור אחר (אזור יתירות כשל). העיקרון הזה נכון גם לגבי מערכת העברת מסדי הנתונים עצמה. אם האזור שבו פועלת מערכת העברת מסד הנתונים הופך ללא נגיש, מערכת העברת מסד הנתונים חייבת לעבור לאזור אחר ולהמשיך מהעברת הנתונים העקבית האחרונה.
טעויות נפוצות
יש כמה מלכודות שעלולות לגרום לחוסר עקביות בנתונים במסדי הנתונים של היעד. אלה כמה דוגמאות נפוצות לטעויות שכדאי להימנע מהן:
- הפרה של תנאי ההזמנה. אם המערכת להעברת נתונים ניתנת להרחבה באמצעות הרחבת היקף הפעולה, אז כמה תהליכים של העברת נתונים פועלים בו-זמנית (במקביל). השינויים במערכת מסד נתונים של מקור מסודרים לפי עסקאות שאושרו. אם השינויים נלקחים מיומן העסקאות, צריך לשמור על הסדר שלהם לאורך כל ההעברה. העברת נתונים מקבילה יכולה לשנות את הסדר בגלל מהירויות שונות בין התהליכים הבסיסיים. חשוב לוודא שהנתונים מוזנים למסדי הנתונים של היעד באותו סדר שבו הם מתקבלים ממסדי הנתונים של המקור.
- הפרת עקביות. בשילוב עם שאילתות דיפרנציאליות, מסדי הנתונים של המקור כוללים מאפייני נתונים נוספים שמכילים, לדוגמה, חותמות זמן של ביצוע פעולות. במסדי הנתונים של היעד לא יהיו חותמות זמן של ביצוע פעולות, כי חותמות הזמן האלה מיועדות רק לניהול שינויים במסדי הנתונים של המקור. חשוב לוודא שההוספות למסדי הנתונים של היעד עקביות מבחינת חותמת הזמן, כלומר כל השינויים עם אותה חותמת זמן צריכים להיות באותה טרנזקציית הוספה, עדכון או upsert. אחרת, יכול להיות שמסד הנתונים של היעד יהיה במצב לא עקבי (זמנית) אם חלק מהשינויים יוכנסו וחלק אחרים עם אותה חותמת זמן לא יוכנסו. המצב הזמני הזה של חוסר עקביות לא משנה אם לא ניגשים למסדי הנתונים של היעד לצורך עיבוד. עם זאת, אם משתמשים בהם לבדיקה, חשוב מאוד לשמור על עקביות. היבט נוסף הוא יצירת ערכי חותמת הזמן במסד הנתונים של המקור והקשר שלהם לזמן השמירה של העסקה שבה הם מוגדרים. בגלל התלות בהתחייבות לעסקה, יכול להיות שעסקה עם חותמת זמן מוקדמת יותר תהיה גלויה אחרי עסקה עם חותמת זמן מאוחרת יותר. אם השאילתה לחישוב ההפרש מופעלת בין שתי העסקאות, היא לא תראה את העסקה עם חותמת הזמן המוקדמת יותר, וכתוצאה מכך תהיה אי-התאמה במסד הנתונים של היעד.
- נתונים חסרים או כפולים. כשמתרחש מעבר לגיבוי, נדרש שחזור זהיר אם חלק מהנתונים לא משוכפלים בין העותק הראשי לבין העותק לגיבוי. לדוגמה, מסד נתונים של מקור עובר יתירות כשל, ולא כל הנתונים משוכפלים לרפליקת יתירות הכשל. במקביל, הנתונים כבר מועברים למסד הנתונים של היעד לפני הכשל. אחרי המעבר לגיבוי, מסד הנתונים הראשי החדש שקודם מפגר מבחינת שינויי הנתונים ביחס למסד הנתונים של היעד (נקרא שחזור). מערכת העברה צריכה לזהות את המצב הזה ולשחזר אותו כך שמסד הנתונים של היעד ומסד הנתונים של המקור יחזרו למצב עקבי.
- עסקאות מקומיות. כדי שמסד הנתונים של המקור ומסד הנתונים של היעד יקבלו את אותם שינויים, גישה נפוצה היא שהלקוחות יכתבו גם למסד הנתונים של המקור וגם למסד הנתונים של היעד, במקום להשתמש במערכת להעברת נתונים. לגישה הזו יש כמה חסרונות. בעיה נפוצה היא ששתי פעולות כתיבה במסד נתונים הן שתי טרנזקציות נפרדות. יכול להיות שתיתקלו בכשל אחרי שהראשונה מסתיימת ולפני שהשנייה מסתיימת. במקרה כזה, הנתונים לא עקביים ותצטרכו לשחזר אותם. בנוסף, יש כמה לקוחות באופן כללי, והם לא מתואמים. הלקוחות לא יודעים את סדר ביצוע העסקאות במסד הנתונים של המקור, ולכן הם לא יכולים לכתוב למסדי הנתונים של היעד שמיישמים את סדר העסקאות הזה. יכול להיות שהלקוחות ישנו את הסדר, מה שיוביל לחוסר עקביות בנתונים. אלא אם כל הגישה עוברת דרך לקוחות מתואמים, וכל הלקוחות מבטיחים את סדר העסקאות של היעד, הגישה הזו עלולה להוביל למצב לא עקבי עם מסד הנתונים של היעד.
באופן כללי, יש עוד בעיות שכדאי להיזהר מהן. הדרך הכי טובה למצוא בעיות שעלולות לגרום לחוסר עקביות בנתונים היא לבצע ניתוח מלא של כשלים, שכולל את כל תרחישי הכשל האפשריים. אם בוצעה הטמעה של בו-זמניות (concurrency) במערכת להעברת מסד הנתונים, צריך לבדוק את כל סדרי ההרצה האפשריים של תהליך העברת הנתונים כדי לוודא שהעקביות של הנתונים נשמרת. אם מיושמת זמינות גבוהה או תוכנית התאוששות מאסון (DR) (או שניהם), צריך לבדוק את כל השילובים האפשריים של כשלים.
המאמרים הבאים
- כדאי לקרוא את המאמר העברות של מסדי נתונים: מושגים ועקרונות (חלק 2).
- מידע על העברת נתונים ממסדי נתונים מופיע במסמכים הבאים:
- מדריכים נוספים להעברת נתונים של מסדי נתונים זמינים במאמר בנושא העברת נתונים של מסדי נתונים.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.