שחזור שידור

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

סקירה כללית על שחזור שידורים

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

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

  • במקורות Oracle, מיקום השכפול הוא יומן Redo במסד הנתונים ומספר השינוי במערכת (SCN) בקובץ הזה.
  • במקורות MySQL, מיקום השכפול הוא קובץ יומן בינארי של מסד הנתונים (binlog) והמיקום בקובץ הזה (לשכפול מבוסס-binlog), או קבוצה של מזהי עסקאות גלובליים שנקראת קבוצת GTID (לשכפול מבוסס-GTID, שנתמך רק ב-Datastream API).
  • במקורות של SQL Server, מיקום השכפול הוא מספר רצף היומן (LSN) ביומני העסקאות או בטבלאות השינויים.
  • במקורות PostgreSQL (כולל AlloyDB ל-PostgreSQL), מיקום השכפול הוא מספר הרצף ביומן (LSN) במשבצת השכפול. במהלך השחזור, הזרם מתחיל לקרוא מה-LSN הראשון במשבצת השכפול.
  • במקורות MongoDB, מיקום השכפול הוא חותמת זמן ביומן הפעולות (oplog) של MongoDB.

שחזור של סטרימינג ממקור MySQL או Oracle

כדי לשחזר סטרימינג ממקור MySQL (שכפול מבוסס-binlog) או Oracle, יש לכם את האפשרויות הבאות:

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

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

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

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

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

  1. עוברים לדף עדכונים ב- Google Cloud.

    מעבר לדף העדכונים

  2. לוחצים על שחזור בשורה עם השם של מקור הנתונים שרוצים לשחזר.

  3. נפתח החלונית בחירת אסטרטגיית שחזור. אפשר לבחור באחת מהאפשרויות. אם בוחרים באפשרות Resume from your preferred streaming file and position (המשך מהקובץ וממיקום הסטרימינג המועדפים), מזינים את הפרטים הבאים:

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

  4. לוחצים על אישור.

  5. כשמשחזרים את השידור, חותמת זמן מופיעה בעמודה ששוחזר בדף שידורים.

שחזור של זרם ממקור PostgreSQL

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

  • אם לשבצת השכפול החדשה יש שם אחר, צריך לספק את השם החדש של שבצת השכפול ל-Datastream.

  • אם לא מציינים שם של משבצת שכפול, Datastream משתמש בשם של משבצת השכפול שצוין בהגדרת המקור.

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

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

כדי לשחזר זרם שנכשל לצמיתות ממקור PostgreSQL, מבצעים את השלבים הבאים:

  1. עוברים לדף עדכונים ב- Google Cloud.

    מעבר לדף העדכונים

  2. לוחצים על שחזור בשורה עם השם של מקור הנתונים שרוצים לשחזר.

  3. ייפתח החלונית Define a new replication slot (הגדרת משבצת שכפול חדשה).

  4. בשדה Replication slot name (שם משבצת השכפול), מציינים את השם של משבצת שכפול חדשה שממנה מקור הנתונים ינסה לשחזר את הנתונים. אם יצרתם מחדש את משבצת השכפול באמצעות אותו שם, או שאתם רוצים להשתמש מחדש במשבצת שציינתם כשקבעתם את הגדרות המקור, אתם יכולים להשאיר את השדה הזה ריק.

  5. לוחצים על אישור.

  6. כשמשחזרים את השידור, חותמת זמן מופיעה בעמודה ששוחזר בדף שידורים.

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

שחזור של שידור ממקור SQL Server

כדי לשחזר מקור נתונים של SQL Server, יש לכם את האפשרויות הבאות:

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

  • המשך מנקודה מסוימת במספר הסידורי של יומן הרישום (LSN): בוחרים באפשרות הזו כדי להמשיך את הסטרימינג מ-LSN ספציפי ביומני הטרנזקציות או בטבלאות השינויים. זו השיטה המומלצת כדי להבטיח תקינות נתונים אם אתם צריכים לשחזר נתונים אחרי נקודת כשל, במיוחד אם טבלה נמחקה ואז נוצרה מחדש, או אם בוצעה תחזוקה. כדי למנוע אובדן נתונים, צריך לבחור מספר LSN שקודם לאירוע שגרם לכשל במקור הנתונים או לתקופה שבה בוצעו שינויים. לדוגמה, אם שינויים ב-DDL הוחלו במהלך חלון זמן לתחזוקה, צריך להשתמש ב-LSN מלפני תחילת התחזוקה.

    איך מוצאים מספר LSN מתאים:

    • כדאי לעיין ביומני מסד הנתונים של SQL Server כדי לקשר בין הזמנים לבין מספרי ה-LSN.
    • אם אתם יודעים את השעה המשוערת, אתם יכולים לשלוח שאילתה לפונקציות או לטבלאות של המערכת כדי למצוא מספר LSN שקרוב לשעה הזו. לדוגמה, אפשר להשתמש ב-sys.fn_dblog(NULL, NULL). חשוב להשתמש בפונקציה הזו בזהירות במערכת ייצור, כי היא קוראת את יומן העסקאות הפעיל. אפשר גם לבדוק טבלאות מערכת של CDC כמו cdc.lsn_time_mapping בכל מסד נתונים עם מעקב אחר שינויים.
    • מספר ה-LSN בשני סוגי היומנים (יומני עסקאות וטבלאות שינויים) מכיל 20 תווים הקסדצימליים, אבל ביומני עסקאות הוא מופרד באמצעות תו מפריד. לדוגמה:
      • מספר LSN ביומני טרנזקציות: 0000123C:0000BA78:0004
      • מספר LSN בטבלאות של שינויים: 0000123C0000BA780004

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

כדי לשחזר זרם שנכשל באופן סופי ממקור SQL Server, מבצעים את השלבים הבאים:

  1. עוברים לדף עדכונים ב- Google Cloud.

    מעבר לדף העדכונים

  2. לוחצים על שחזור בשורה עם השם של מקור הנתונים שרוצים לשחזר.

  3. נפתח החלונית בחירת אסטרטגיית שחזור. אפשר לבחור באחת מהאפשרויות.

  4. לוחצים על אישור.

  5. כשמשחזרים את השידור, חותמת זמן מופיעה בעמודה ששוחזר בדף שידורים.

שחזור מקור נתונים של MongoDB

אפשר לשחזר מקורות נתונים של MongoDB באמצעות Datastream API. אפשר לשחזר נתונים מ-MongoDB באמצעות האפשרויות הבאות:

  • המיקום האחרון להתחלה: בוחרים באפשרות הזו אם רוצים להמשיך את הסטרימינג מחותמת הזמן הנוכחית ב-oplog של MongoDB. האירועים החסרים אבדו, אבל אפשר לשחזר אותם באמצעות מילוי חוסרים.

  • מיקום התחלה ספציפי: בוחרים באפשרות הזו כדי להמשיך את השידור מחותמת זמן נבחרת. חותמת הזמן שבה משתמשים בבקשה צריכה להיות תקינה, כלומר היא לא יכולה להיות מוקדמת מהמיקום המוקדם ביותר שזמין ב-oplog של MongoDB, והיא לא יכולה להיות בעתיד.

מידע על יצירת בקשה לשחזור של מקור נתונים של MongoDB מופיע במאמרי העזרה של Datastream API.

מידע על יומן הפעולות של MongoDB זמין במסמכי העזרה של MongoDB.

שימוש בשחזור סטרימינג למקור MySQL בתרחיש של מעבר ידני לגיבוי

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

  1. מפסיקים את כל פעולות הכתיבה למופע הראשי.
  2. מוודאים שהמדד 'עדכניות הנתונים' מוגדר ל-0. המשמעות היא ש-Datastream תיעד את כל השינויים ואין אירועים חדשים לקריאה ממקור הנתונים. מידע נוסף זמין במאמר בנושא מעקב אחרי שידור.
  3. מעבר אוטומטי למסד הנתונים החדש.
  4. אם צריך, מעדכנים את פרופיל החיבור של הזרם למופע החדש של מסד הנתונים (לדוגמה, יכול להיות שתצטרכו לשנות את שם המארח או את כתובת ה-IP של מסד הנתונים). מידע נוסף זמין במאמר בנושא שינוי פרופילים של חיבורים.
  5. שחזור הנתונים מהזרם ממיקום ספציפי במופע של המעבר לגיבוי כדי להבטיח את המשכיות של ה-CDC.

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