העברת מעבר בסיסי נתונים לאגם נתונים ב-S3 דרך AWS DMS, חלק I

שירות ההעברה של מסד הנתונים של AWS הוא שירות ענן המעביר מסדי נתונים רלציוניים, מסדי נתונים NoSQL, מחסני נתונים וכל סוגי האחסון השונים לענן של AWS או בין הענן וההתקנים באופן יעיל ובטוח. שירות ההעברה של מסד הנתונים תומך במספר סוגים של מסדי נתונים מקור ויעד כגון Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift ו-S3, וכו.

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

עבדנו על עיצוב ויצירת אגם נתונים של AWS S3 ומחסן נתונים ב-Redshift של AWS עם מקורות הנתונים מההתקנים ל-Oracle, MS SQL Server, MySQL, Postgres SQL ו-MongoDB עבור מסדי נתונים רלציוניים. השתמשנו ב-AWS DMS עבור העברת הטעינה המלאה הראשונית והעברת הנתונים הגוברת יומית ממקורות אלו ל-S3 של AWS.

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

1. תאריך השינוי לא נמלא כראוי במקור

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

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

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

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. הפעלת Supplemental Logging עבור Oracle כמקור

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

ניתן להפעיל Supplemental Logging עבור מפתחות ראשיים, ייחודיים, סטים של עמודות או עבור כל העמודות. Supplemental Logging עבור כל העמודות תופס את כל העמודות עבור הטבלאות במסד הנתונים המקורי ומסייע להחלפת הרשומות המלאות בשכבת היעד של AWS S3.

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

3.

העברה המלאה הראשונית ממקורות באתר ל-Oracle, MS SQL Server, וכו', עבדה בצורה טובה ותפסת שינויים, גם, לרוב הזמן. 

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

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

• CDCLatencySource – הפער, בשניות, בין האירוע האחרון שנתפס מנקודת הקצה של המקור ולזמן המערכת הנוכחי של תצורת מופע ה- AWS DMS.
• CDCIncomingchanges – מספר האירועים שינוי כולל בנקודה נתונה שממתין להיות מיושם ביעד. מספר זה מתרבה מאפס לאלפים במהלך פעילויות הסדרת חשבונות בשעות הבוקר המוקדמות.
• מקורCDCLatencySource – הפער, ב-שניות, בין האירוע האחרון שנלכד מקצה המקור וציון הזמן הנוכחי של מערכת AWS DMS. ערך זה עולה מאפס למספר אלפים ועד 10-12 אלפי שניות במהלך פעילויות קיזוז לאחר חצות. ערך זה היה עד 40 אלפי שניות במהלך פעילויות סוף חודש.

בעקבות ניתוח קבצי יומן נוספים וסקירת מדדים נוספים, למדנו כי:

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

נמצא כי הרוחב פס קליטת הרשת היה עד 30MB/s, כלומר, 250Mb/s, עקב החיבור ב-VPN בין המקור ו-AWS, ששותף גם ליישומים אחרים.

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

1. נתיב VPN כגון VPN בין אתרי AWS או VPN בין אתרי Oracle Cloud Infrastructure (OCI) (Oracle AWS) יכול לספק תפוקה של עד 1.25 Gbps. זה יהיה מספיק להעברת טבלאות קטנות או טבלאות עם תנועת DML נמוכה.
2. למיגרציות נתונים גדולים עם מספר עסקאות כבד על הטבלאות, עליך לשקול את AWS Direct Connect. השירות מספק אפשרות ליצירת חיבור פרטי מוקד לקשרים עם 1 Gbps, 10 Gbps וכו'.

מסקנה

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