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

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

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

התנהגות

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

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

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

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

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

רפליקציה שמבוססת על מזהה עסקה גלובלי (GTID)

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

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

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

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

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

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

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

  1. מוודאים שכל הדרישות לרפליקציה שמבוססת על GTID מתקיימות. מידע נוסף זמין במאמר הגדרת מסד נתונים של MySQL כמקור.
  2. אופציונלי: יוצרים ומריצים בדיקה של סטרימינג מבוסס-GTID. מידע נוסף זמין במאמר יצירת מקור נתונים.
  3. יוצרים מקור נתונים שמבוסס על GTID. אל תתחיל עדיין.
  4. מפסיקים את תנועת האפליקציה למסד הנתונים של המקור.
  5. משהים את הסטרימינג הקיים שמבוסס על binlog. מידע נוסף זמין במאמר השהיית הסטרימינג.
  6. ממתינים כמה דקות כדי לוודא ש-Datastream התעדכן בהתאם למסד הנתונים. אפשר לבדוק את זה באמצעות המדדים בכרטיסייה מעקב, בדף פרטי השידור של השידור שלכם. הערכים של עדכניות הנתונים ו-Throughput צריכים להיות 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 טבלאות.
  • טבלאות משוכפלות חייבות להשתמש במנוע האחסון InnoDB. טבלאות שמשתמשות במנוע האחסון MyISAM לא נתמכות ונכשלות באימות הסטרימינג.
  • אי אפשר למלא מחדש טבלאות שהמפתח הראשי שלהן מוגדר כ-INVISIBLE.
  • אי אפשר למלא מילוי חסר בטבלה שיש בה יותר מ-500 מיליון שורות, אלא אם מתקיימים התנאים הבאים:
    1. לטבלה יש אינדקס ייחודי.
    2. אף אחת מהעמודות של האינדקס לא יכולה להיות ריקה.
    3. האינדקס לא יורד.
    4. כל העמודות של האינדקס נכללות בסטרימינג.
  • בזמן עיבוד האירועים, Datastream מאחזר מדי פעם את הסכימה האחרונה מהמקור. אם הסכימה משתנה, Datastream מזהה את השינוי בסכימה ומפעיל שליפה של הסכימה. עם זאת, יכול להיות שאירועים מסוימים יעובדו באופן שגוי או יושמטו בין אחזורי הסכימה, מה שעלול לגרום לפערים בנתונים.
  • לא כל השינויים בסכימת המקור ניתנים לזיהוי באופן אוטומטי, ובמקרים כאלה עלול להתרחש נזק לנתונים. השינויים הבאים בסכימה עלולים לגרום לפגיעה בנתונים או לכשל בעיבוד האירועים בהמשך:
    • הסרת עמודות
    • הוספת עמודות באמצע הטבלה
    • שינוי סוג הנתונים של עמודה
    • שינוי סדר העמודות
    • הסרת טבלאות (רלוונטי אם אותה טבלה נוצרת מחדש עם נתונים חדשים)
    • חיתוך טבלאות
  • ‫Datastream לא תומך בשכפול תצוגות.
  • ‫Datastream לא תומך בעמודות של סוגי נתונים מרחביים, למשל GEOMETRY,‏ POINT,‏ LINESTRING,‏ POLYGON. הערכים בעמודות האלה מוחלפים בערכים של NULL.
  • ‫Datastream לא תומך בערך אפס (0000-00-00 00:00:00) בעמודות של סוגי הנתונים DATETIME,‏ DATE או TIMESTAMP. ערך האפס מוחלף בערך NULL.
  • ‫Datastream לא תומך בשכפול שורות שכוללות את הערכים הבאים בעמודות JSON: ‏DECIMAL, ‏NEWDECIMAL, ‏TIME, ‏TIME2, ‏DATETIME, ‏DATETIME2, ‏DATE, ‏TIMESTAMP או TIMESTAMP2. אירועים שמכילים ערכים כאלה נמחקים.
  • ‫Datastream לא תומך בדחיסת טרנזקציות של יומן בינארי.
  • ‫Datastream לא תומך בקובצי יומן בינאריים שגדולים מ-4GiB. מכיוון ש-MySQL כותב כל טרנזקציה לקובץ יומן בינארי אחד, צריך לשמור על טרנזקציות בודדות מתחת ל-4GiB כדי שקובצי היומן הבינאריים לא יחרגו מהמגבלה הזו.
  • ‫Datastream לא תומך בשרשראות של אישורי SSL בפרופילי החיבור של מקור MySQL. יש תמיכה רק באישור יחיד בקידוד x509 PEM.
  • ‫Datastream לא תומך בפעולות מדורגות: ON UPDATE CASCADE ו-ON DELETE CASCADE. אירועים כאלה לא נכתבים ביומן הבינארי, ולכן הם לא מועברים ליעד. כדי לעקוף את הבעיה, אתם יכולים להחליף פעולות מדורגות בטריגרים של מסד נתונים.
  • ‫Datastream לא תומך בפעולות DROP PARTITION. פעולות כאלה הן פעולות של מטא-נתונים בלבד, והן לא משוכפלות. אירועים אחרים לא מושפעים והשידור פועל כרגיל.
  • יכול להיות שיהיו בעיות בקישוריות בזמן הרפליקציה של טבלאות 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 בניהול עצמי.
  • ‫Datastream לא תומך בטרנזקציות מבוזרות (XA). ‫MySQL כותב אירועי עסקאות XA ביומן הבינארי כשמריצים את ההצהרה XA PREPARE. לכן, שינויים מעסקאות XA מוכנות משוכפלים ליעד גם אם העסקה מבוטלת מאוחר יותר באמצעות הצהרת XA ROLLBACK.
  • מגבלות של MariaDB:
    • רפליקציה מבוססת-GTID לא נתמכת ב-MariaDB. כדי להשתמש ברפליקציה מבוססת-binlog, צריך להגדיר את הסטרימינג של MariaDB.
    • בגרסאות 11.4 עד 12.2 של MariaDB, צריך להפעיל את משתנה המערכת binlog_legacy_event_pos במסד הנתונים של המקור כדי להבטיח תאימות ל-Datastream.
    • ‫Datastream לא תומך בסוג הנתונים UUID (נוסף ב-MariaDB 10.7). צריך להחריג עמודות מסוג הנתונים UUID מהגדרת הסטרימינג.

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

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

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