בדף הזה מפורטות שיטות מומלצות לשימוש ב-Datastream. הן כוללות שיטות מומלצות כלליות לשימוש ב-Datastream.
שינוי של מסד הנתונים המקורי של שידור
במקרים מסוימים, יכול להיות שתצטרכו לשנות את מסד הנתונים של המקור של הזרם. לדוגמה, יכול להיות שתצטרכו לשנות את מקור הנתונים כדי לשכפל מתוך עותק משוכפל במקום מתוך מופע מסד הנתונים הראשי.
- יוצרים פרופיל חיבור עבור מופע הרפליקה.
- יוצרים מקור נתונים באמצעות פרופיל החיבור של העותק שנוצר ופרופיל החיבור הקיים של היעד.
- מתחילים את השידור כשהאפשרות 'מילוי היסטורי' מושבתת. כשהסטרימינג מתחיל, הוא מעביר רק את הנתונים מיומני ה-binary.
- זה שינוי אופציונלי. אחרי שהסטרימינג פועל, משנים אותו כדי להפעיל מילוי אוטומטי של נתונים חסרים.
- להשהות את השידור שקורא מהמופע הראשי.
- זה שינוי אופציונלי. מוחקים את מקור הנתונים שהזרים נתונים מהמופע הראשי.
- זה שינוי אופציונלי. מוחקים את פרופיל הקישור של המופע הראשי.
התראות ומעקב ב-Datastream
לוח הבקרה של Datastream מכיל הרבה מידע. המידע הזה יכול לעזור בניפוי באגים. מידע נוסף מופיע ביומנים, שזמינים ב-Cloud Logging.
התראות של Datastream
לא הוגדרה התראה כברירת מחדל ל-Datastream. לדוגמה, אתם יכולים ליצור מדיניות התראות למדד Data freshness (רעננות הנתונים) על ידי לחיצה על הקישור Create alerting policy (יצירת מדיניות התראות) בכרטיסייה Overview (סקירה כללית). לגבי שאר המדדים, פועלים לפי השלבים הבאים:
נכנסים לדף notifications Alerting במסוף Google Cloud :
לוחצים על יצירת מדיניות.
לוחצים על התפריט הנפתח בחירת מדד.
בשדה המסנן, מזינים
Datastream.אופציונלי: יכול להיות שתצטרכו להשבית את המסנן פעיל כדי לראות את כל המדדים הזמינים.
מחפשים את המדד שרוצים לעקוב אחריו בקטע Datastream Stream (מקור נתונים).
לוחצים על אישור.
אופציונלי: מזינים את הפרטים הנדרשים בקטעים הוספת מסננים וטרנספורמציה של נתונים. לוחצים על הבא.
מזינים את המידע הנדרש בקטע הגדרת טריגר להתראה. לוחצים על Next.
מגדירים את ההתראות בקטע הגדרת התראות וסיום ההתראה.
בודקים את ההתראה ולוחצים על יצירת מדיניות כשמוכנים.
למידע מפורט על השלמת כל אחד מהשלבים האלה, אפשר לעיין במאמר בנושא יצירת מדיניות התראות.
מומלץ ליצור התראות לגבי המדדים הבאים של Datastream:
- עדכניות הנתונים
- מספר האירועים שלא נתמכים בסטרימינג
- זמני האחזור הכוללים של השידור
התראה לגבי אחד מהמדדים האלה יכולה להצביע על בעיה בסטרימינג או במסד הנתונים של המקור.
הסבר על זמן האחזור
המדדים הבאים זמינים ב-Datastream ויעזרו לכם להבין את זמן האחזור של השכפול:
- עדכניות הנתונים: ההבדל בין הזמן שבו הנתונים נשמרו במקור לבין הזמן שבו הם נקראו על ידי Datastream. אם הערך של המדד הזה גבוה, זה מצביע על כך ש-Datastream קורא את הנתונים לאט יותר מהקצב שבו הם נוצרים במקור. ההודעה הזו מציינת שאולי יש בעיה במקור או בחיבור לרשת של המקור.
- השהיית המערכת: הזמן שנדרש ל-Datastream לעיבוד אירוע, מהרגע שבו האירוע נקרא מהמקור ועד שהוא נכתב ביעד.
- השהיה הכוללת: הפער בין הזמן שבו הנתונים נשמרים במקור לבין הזמן שבו הם נכתבים ביעד.
אם עדכניות הנתונים גבוהה, הסיבות הנפוצות לכך הן:
- עומס יתר על המקור: מסד הנתונים של המקור יוצר יומנים (קבצי binlog, קבצי redo log, קבצי WAL) מהר יותר ממה ש-Datastream יכול לקרוא אותם.
- פעולה לביצוע ב-MySQL/Oracle:
הגדלת הפרמטר
maxConcurrentCdcTasksכדי לקרוא יותר יומנים במקביל. - פעולה ל-PostgreSQL: בידוד טבלאות עם שיעור נטישה גבוה לזרמים ייעודיים משלהן.
- פעולה ל-SQL Server: מגדילים את הפרמטר
maxConcurrentCdcTasksכדי לקרוא יותר טבלאות שינוי במקביל.
- פעולה לביצוע ב-MySQL/Oracle:
הגדלת הפרמטר
- מחסור במשאבי המקור: בשרת מסד הנתונים של המקור יש בעיות כמו שימוש גבוה ביחידת העיבוד המרכזית (CPU), זיכרון נמוך או צווארי בקבוק של קלט/פלט בדיסק.
- פעולה: מוודאים שהמופע של המקור תקין. בודקים את השימוש ב-CPU/RAM. ב-PostgreSQL, כדאי להגדיל את הערך של הפרמטר
logical_decoding_work_mem. ב-Oracle, צריך לוודא שהוקצה מספיק שטח אחסון גלובלי במערכת (SGA).
- פעולה: מוודאים שהמופע של המקור תקין. בודקים את השימוש ב-CPU/RAM. ב-PostgreSQL, כדאי להגדיל את הערך של הפרמטר
- בעיות בקיבולת הרשת: זמן פינג גבוה או רוחב פס רווי בין המקור לבין Google Cloud.
- פעולה: מעקב אחרי רוחב הפס וזמן האחזור של ה-VPN או של Cloud Interconnect.
- טרנזקציה גדולה אחת: עבודה גדולה באצווה, כמו
UPDATEעל מיליוני שורות, עלולה לגרום לעלייה זמנית בחביון.- פעולה: זה צפוי. ממתינים עד ש-Datastream יעבד את האירוע הגדול. כדאי לפצל בעתיד משימות גדולות של עיבוד באצווה לחלקים קטנים יותר.
אם זמן האחזור של המערכת גבוה, יכול להיות שיש בעיה ב-Datastream או ביעד.
- פעולה: בודקים ב-Cloud Logging אם יש שגיאות מתמשכות ברמת השורה (לדוגמה,
invalid input for type json). אם הסטרים נמצא בלולאת ניסיון חוזר בגלל שגיאות בסוג הנתונים או באילוץ, יכול להיות שיהיה צורך לתקן את הנתונים באופן ידני במקור. אם לא מופיעות שגיאות ברורות, פנו לתמיכה של Google לקבלת עזרה.
כמה טבלאות יכולות להיות בזרם אחד?
מומלץ שכל סטרימינג יכלול עד 10,000 טבלאות. אין הגבלה על גודל הטבלאות. אם צריך ליצור סטרימינג עם יותר טבלאות, יכול להיות שהסטרימינג יעבור למצב שגיאה. כדי להימנע מכך, כדאי לפצל את המקור לכמה זרמים.