הזרמת נתונים ממסדי נתונים של MySQL

בקטע הזה מופיע מידע על:

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

התנהגות

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

רפליקציה מבוססת-Binlog

‫Datastream יכול להשתמש בקובצי binary log כדי לשמור תיעוד של שינויים בנתונים במסדי נתונים של MySQL. המידע שכלול בקבצים האלה משוכפל ליעד כדי לשחזר את השינויים שבוצעו במקור.

המאפיינים העיקריים של שכפול מבוסס-binlog ב-Datastream הם:

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

שכפול מבוסס מזהה טרנזקציה גלובלי (GTID)

‫Datastream תומך גם בשכפול שמבוסס על מזהה גלובלי (GTID).

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

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

המאפיינים העיקריים של שכפול מבוסס GTID ב-Datastream הם:

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

מעבר מרפליקציה מבוססת-binlog לרפליקציה מבוססת-GTID

אם רוצים לעדכן את הזרם ולעבור משכפול מבוסס-binlog לשכפול מבוסס-GTID בלי לבצע מילוי חוזר, צריך לבצע את השלבים הבאים:

  1. מוודאים שכל הדרישות לשכפול מבוסס GTID מתקיימות. מידע נוסף זמין במאמר הגדרת מסד נתונים של MySQL כמקור.
  2. אופציונלי: יוצרים ומריצים שידור מבוסס-GTID לצורך בדיקה. מידע נוסף זמין במאמר יצירת מקור נתונים.
  3. יוצרים מקור נתונים מבוסס-GTID. אל תתחילו אותו עדיין.
  4. מפסיקים את תנועת הנתונים של האפליקציה למסד הנתונים של המקור.
  5. משהים את הסטרימינג הקיים שמבוסס על binlog. מידע נוסף מופיע במאמר בנושא השהיית הסטרימינג.
  6. ממתינים כמה דקות כדי לוודא ש-Datastream השלים את הסנכרון עם מסד הנתונים. כדי לבדוק את זה, אפשר להשתמש במדדים שבכרטיסייה מעקב בדף פרטי השידור של השידור. הערכים של עדכניות הנתונים ושל קצב העברת הנתונים צריכים להיות 0.
  7. מתחילים את הזרם שמבוסס על GTID. מידע נוסף זמין במאמר בנושא הפעלת הסטרימינג.
  8. ממשיכים את התנועה למסד הנתונים של המקור.

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

גרסאות

‫Datastream תומך בגרסאות הבאות של מסד הנתונים MySQL:

  • ‫MySQL 5.6
  • ‫MySQL 5.7
  • ‫MySQL 8.0

  • ‫MySQL 8.4 (נתמך רק בשכפול מבוסס-GTID)

‫Datastream תומך בסוגים הבאים של מסדי נתונים של MySQL:

שיטות מומלצות

בקטע הזה מפורטות שיטות מומלצות להגדרת מקור MySQL לשימוש עם Datastream.

שימוש ב-GTID להגדרות של זמינות גבוהה

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

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

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

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

הגדרת גודל נכון של העותק לקריאה

אם מגדירים את Datastream לשכפול מתוך העתק לקריאה, יכול להיות שתיתקלו בפיגור כפול, שהוא שילוב של פיגור בשכפול של MySQL (מהמקור להעתק) ופיגור בשכפול של Datastream (מההעתק ליעד). לרוב, העותקים לקריאה מוקצים עם פחות משאבים (CPU,‏ RAM,‏ IOPS) מאשר העותקים הראשיים, כדי לחסוך בעלויות. כתוצאה מכך, יכול להיות שהם יפגרו אחרי העותק הראשי בתקופות של כתיבה אינטנסיבית.

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

הגדלת התפוקה של שיטת ה-CDC של binlog

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

המלצה: כדי לקבוע את הערך המתאים לעדכניות הנתונים, כדאי לעקוב אחרי קצב יצירת ה-binlog בשרת MySQL בשעות השיא. כדי לעשות את זה, אפשר לעקוב אחרי הקצב שבו נוצרים קובצי binlog חדשים ומתבצעת רוטציה שלהם בספריית הנתונים של MySQL, או להשתמש בכלי ניטור של MySQL כדי לעקוב אחרי הגידול ביומנים בינאריים. לדוגמה, אם המקור שלכם יוצר 10 קובצי binlog בדקה בזמני שיא, הגדרה של maxConcurrentCdcTasks לערך כמו 10-15 מאפשרת ל-Datastream לעבד את הקבצים האלה במקביל, וכך למנוע הצטברות של נתונים שלא עברו עיבוד.

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

הגדרת גודל נכון לפרמטר max_allowed_packet

ההגדרה max_allowed_packet שמוגדרת כברירת מחדל ב-MySQL (לדוגמה, 16MB-64MB) עשויה להיות קטנה מדי. אם שורה אחת עם שדות גדולים מהסוגים BLOB, JSON או TEXT, או אם עסקה גדולה אחת חורגת מהגודל הזה, מערכת MySQL תסיים את החיבור ל-Datastream, והסטרים ייכשל עם שגיאות כמו Packet for query is too large או Got a packet bigger than 'max_allowed_packet' bytes.

המלצה: מגדירים את הפרמטר max_allowed_packet בשרת MySQL לערך המקסימלי המותר של 1G. כך השרת יוכל לטפל בכל שורה או עסקה גדולה ש-Datastream צריך לקרוא מיומן ה-binlog.

מגבלות ידועות

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

  • הסטרימינג מוגבל ל-10,000 טבלאות.
  • אי אפשר לבצע מילוי חוזר של טבלאות שמוגדר בהן מפתח ראשי כ-INVISIBLE.
  • אי אפשר לבצע מילוי חוזר של טבלה עם יותר מ-500 מיליון שורות, אלא אם מתקיימים התנאים הבאים:
    1. לטבלה יש אינדקס ייחודי.
    2. אף אחת מהעמודות של האינדקס לא יכולה להכיל ערך null.
    3. האינדקס לא בסדר יורד.
    4. כל העמודות של האינדקס נכללות בזרם.
  • הכלי Datastream מאחזר מעת לעת את הסכימה העדכנית מהמקור בזמן העיבוד של האירועים. אם סכימה משתנה, Datastream מזהה את השינוי בסכימה ומפעיל אחזור של הסכימה. עם זאת, יכול להיות שחלק מהאירועים יעברו עיבוד שגוי או יושמטו בין אחזור הסכימות, מה שיכול לגרום לאי-התאמות בנתונים.
  • לא כל השינויים בסכימת המקור ניתנים לזיהוי אוטומטי, ובמקרה כזה עלול להתרחש שיבוש בנתונים. השינויים הבאים בסכימה עלולים לגרום לפגם בנתונים או לכך שהמערכת לא תעבד את האירועים בהמשך:
    • הסרת עמודות
    • הוספת עמודות באמצע הטבלה
    • שינוי סוג הנתונים של עמודה
    • שינוי הסדר של העמודות
    • מחיקת טבלאות (רלוונטי אם הטבלה זהה ואז נוצרת מחדש עם נתונים חדשים)
    • חיתוך טבלאות
  • הכלי Datastream לא תומך בשכפול תצוגות.
  • ב-Datastream אין תמיכה בעמודות של סוגי נתונים מרחביים. הערכים בעמודות האלה מוחלפים בערכים NULL.
  • הזרמת נתונים לא תומכת בערך אפס (0000-00-00 00:00:00) בעמודות של סוגי הנתונים DATETIME,‏ DATE או TIMESTAMP. הערך אפס מוחלף בערך NULL.
  • הכלי להעברת נתונים לא תומך בשכפול שורות שכוללות את הערכים הבאים בעמודות JSON: DECIMAL,‏ NEWDECIMAL,‏ TIME,‏ TIME2,‏ DATETIME,‏ DATETIME2,‏ DATE,‏ TIMESTAMP או TIMESTAMP2. אירועים שמכילים ערכים כאלה נפסלים.
  • הכלי Datastream לא תומך בדחיסה של עסקאות ביומן בינארי.
  • ‫Datastream לא תומך בשרשראות של אישורי SSL בפרופילים של חיבורי MySQL למקור. יש תמיכה רק באישורים יחידים בקידוד PEM מסוג x509.
  • ‫Datastream לא תומך בפעולות מדורגות: ON UPDATE CASCADE ו-ON DELETE CASCADE. אירועים כאלה לא נכתבים ביומן הבינארי, ולכן הם לא מועברים ליעד. כפתרון עקיף, אפשר להחליף פעולות מדורגות בטריגרים של מסד נתונים.
  • הפעולות DROP PARTITION לא נתמכות ב-Datastream. פעולות כאלה הן פעולות של מטא-נתונים בלבד, והן לא משוכפלות. אירועים אחרים לא מושפעים והשידור פועל בהצלחה.
  • יכול להיות שתיתקלו בבעיות בחיבור כשמשכפלים טבלאות FEDERATED. במקרה כזה, צריך להסיר את כל הטבלאות של FEDERATED מההגדרה של מסד הנתונים של המקור ולהגדיל את הערכים של הפרמטרים connect_timeout, net_read_timeout ו-max_allowed_packet כדי למנוע בעיות שקשורות לזמן קצוב לתפוגה במהלך מילוי חוסרים.
  • במופעים של Cloud SQL Enterprise Plus צריך להשתמש בשכפול מבוסס-GTID כי הם כפופים לתחזוקה עם זמן השבתה כמעט אפסי. שכפול שמבוסס על יומן בינארי נכשל במעבר לגיבוי, ולכן מומלץ להשתמש בשכפול שמבוסס על GTID בתרחישי שימוש של זמינות גבוהה.
  • ב-MySQL מגרסה 8.0 ואילך, צריך להגדיר את המשתנה binlog_row_value_options כערך ריק. זוהי הגדרת ברירת המחדל ברוב הגרסאות, אבל בחלק מהגרסאות, למשל מקורות MySQL ב-Oracle Cloud Infrastructure‏ (OCI), צריך להגדיר אותה באופן מפורש. מידע נוסף זמין במאמר הגדרת מסד נתונים של MySQL בניהול עצמי.

מגבלות נוספות לשכפול מבוסס GTID

  • אפשר לשחזר סטרימינג שמשתמש בשכפול מבוסס-GTID רק כשמשתמשים ב-Datastream API.
  • אין תמיכה ביצירת טבלאות מטבלאות אחרות באמצעות הצהרות CREATE TABLE ... SELECT.
  • ב-Datastream אין תמיכה ב-GTID עם תגים.
  • למידע על הגבלות של MySQL שחלות על שכפול מבוסס GTID, אפשר לעיין במסמכי MySQL.

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