ביצוע מעבר חזרה ל-MySQL

במדריך הזה מוסבר איך לבצע מעבר לגיבוי (fallback) וביטול שינויים (rollback) של התאוששות מאסון מ-Spanner בחזרה למופעי MySQL של המקור.

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

לפני שמתחילים

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

1. רפליקציה הפוכה פעילה: מוודאים שפייפליין Dataflow לרפליקציה הפוכה (Spanner_to_SourceDb) פועל ומשתמש באופן פעיל בסנכרון שינויים בזרמי נתונים של Spanner במצב סינון forward_migration. מידע נוסף זמין במאמר בנושא הגדרת מעבר ל-MySQL.
2. זמינות של MySQL כמקור: מוודאים שמסד הנתונים של MySQL כמקור נמצא אונליין, שאפשר להגיע אליו מ-Dataflow ושהוא יכול לקבל חיבורי כתיבה.
3. חלון זמן לתחזוקה: צריך להודיע לבעלי העניין שנדרש חלון זמן מתוכנן להשבתה בזמן שהכתיבות ב-Spanner מושהות והרפליקציה ההפוכה מתרוקנת.

התפקידים הנדרשים

• כדי לקבל את ההרשאות שדרושות לביצוע חזרה למצב קודם ב-MySQL, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

  • משתמש במסד נתונים ב-Cloud Spanner ‏ (roles/spanner.databaseUser)
  • אדמין ב-Dataflow (roles/dataflow.admin)
  • אדמין ב-Datastream (roles/datastream.admin)
  • אדמין באחסון (roles/storage.admin)
  • צפייה במעקב (roles/monitoring.viewer)
  • צפייה (roles/viewer)

השהיית פעולות הכתיבה ב-Spanner

אזהרה: זמן ההשבתה של האפליקציה מתחיל בשלב הזה.

1. באפליקציה, משהים את כל תנועת הכתיבה של מסד הנתונים ל-Spanner.
2. מאפשרים לטרנזקציות פעילות ב-Spanner להתבצע באופן מלא ולהתרוקן.

מתן הרשאה לניקוז של רפליקציה הפוכה

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

מעקב אחרי השהיית הרפליקציה

כדי לוודא שכל השינויים שנמצאים בתהליך נכתבים ל-MySQL, עוקבים אחרי השהיית השכפול:

1. במסוף Google Cloud , נכנסים לדף Job details של משימת ה-Dataflow לרפליקציה הפוכה.
2. בכרטיסייה מדדים מותאמים אישית, בודקים את מונה המשתמשים replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. מידע נוסף זמין במאמר הגדרת חלופה ל-MySQL.
3. מחכים עד שערך המונה יגיע ל-0.

אפשרות אחרת היא לשלוח שאילתה למונה המשתמשים ב-Metrics Explorer באמצעות שפת שאילתת מעקב (MQL):

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
    

מחליפים את הערכים הבאים: * JOB_ID: המזהה של משימת Dataflow של השכפול ההפוך. ‫* LOGICAL_SHARD_NAME: השם הלוגי של השבר שהוגדר למסד הנתונים של המקור.

אימות פעולות כתיבה ב-MySQL

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

1. במסד הנתונים הראשי של MySQL, בודקים את השאילתות הפעילות ואת מדדי החיבור למסד הנתונים.
2. מוודאים שתנועת הכתיבה מצינור הרפליקציה ההפוכה נעצרה.

אימות המצב של תור ההודעות הבלתי ניתנות לניתוב (DLQ)

בודקים את תורי ההודעות המתות (DLQ) כדי לוודא שלא התרחשו שגיאות לא מטופלות במהלך השכפול ההפוך:

1. במסוף Google Cloud , נכנסים לדף Job details של משימת ה-Dataflow לרפליקציה הפוכה. בכרטיסייה מדדים מותאמים אישית, בודקים את severe_error_count מונה המשתמשים.

2. בודקים את שתי ספריות ה-DLQ של הרפליקציה ההפוכה ב-Cloud Storage (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ ו-gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

   כדי להציג את התוכן של ספריית ה-DLQ החמורה, אפשר להשתמש ב-CLI של gcloud:

   gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MIGRATION_BUCKET: שם הקטגוריה של Cloud Storage.
   • ‫ENV: שם סביבת הפריסה (לדוגמה, prod).
   • ‫SERVICE: השם של האפליקציה או השירות.
   • ‫DB_SCHEMA: השם של סכימת מסד הנתונים.

3. מוודאים שהספריות של תור ההודעות המתות נשארות ריקות לגמרי.

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

המשך הסטרימינג של נתוני CDC קדימה

אם אתם מתכננים להמשיך את ההעברה קדימה ל-Spanner בעתיד, המשיכו את הסטרימינג קדימה ב-Datastream:

1. נכנסים לדף Stream details של השידור במסוף Google Cloud .
2. לוחצים על הפעלה מחדש ומחכים שסטטוס מקור הנתונים ישתנה ל-RUNNING. מידע נוסף זמין במאמר העברת נתוני MySQL.

לחלופין, כדי להפעיל מחדש את הסטרימינג באמצעות ה-CLI של gcloud, מריצים את הפקודה gcloud datastream streams resume:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

מחליפים את מה שכתוב בשדות הבאים:

• ‫STREAM_ID: המזהה של מקור הנתונים ב-Datastream.
• ‫LOCATION: האזור ב- Google Cloud שבו נמצא ה-stream.

ניתוב מחדש של פעולות כתיבה ל-MySQL

הערה: זמן ההשבתה של האפליקציה מסתיים בשלב הזה.

1. מעדכנים את הגדרות האפליקציה ואת מחרוזות החיבור למסד הנתונים כדי לטרגט את המכונות של מסד הנתונים הראשי של MySQL במקור.
2. מפעילים את שירותי האפליקציה וממשיכים את תנועת הקריאה והכתיבה בזמן אמת ב-MySQL.
3. מוודאים שפעולות הקריאה והכתיבה של האפליקציה פועלות בהצלחה מול מסד הנתונים של MySQL.

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

• מעבר חד למערכת אחרת (cutover) מ-MySQL
• הגדרת מעבר לגיבוי ל-MySQL
• העברה מ-MySQL ל-Spanner