ביצוע מעבר מ-MySQL

במדריך הזה מוסבר איך לבצע מעבר חד למערכת אחרת (cutover) של העברת מסד נתונים פעיל ממכונה של מקור MySQL למסד נתונים של Spanner באמצעות Datastream ו-Dataflow.

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

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

  1. העברת סכימה: פריסת הסכימה ב-Spanner. למידע נוסף, ראו העברת סכימה מ-MySQL.
  2. העברת מילוי חוסרים: השלמת ההעברה הראשונית של הנתונים באמצעות משימת Dataflow להעברת מילוי חוסרים. מידע נוסף זמין במאמר ביצוע העברה של מילוי חוסרים.
  3. רפליקציה פעילה של CDC: מוודאים שרפליקציה רציפה של סימון נתונים שהשתנו (CDC) פעילה ותקינה:
    • הזרם של Datastream קורא באופן פעיל אירועי שינוי ממסד הנתונים של MySQL במקור, וכותב אותם בקטגוריה של Cloud Storage.
    • ההתראות של קטגוריה של Cloud Storage מפרסמות אירועים של יצירת אובייקטים בנושא Pub/Sub.
    • משימת ה-Dataflow בסטרימינג (Cloud_Datastream_to_Spanner) צורכת את המינוי ל-Pub/Sub וכותבת שינויים ב-Spanner עם השהיית רפליקציה של פחות משנייה או השהיה זניחה. מידע נוסף זמין במאמר בנושא העברת נתונים מ-MySQL.
  4. אימות נתונים ראשוני: מריצים בדיקות לאימות נתונים כדי לוודא שהנתונים עקביים בין מופע המקור של MySQL לבין יעד Spanner. מידע נוסף זמין במאמר אימות של העברת הנתונים.
  5. ניקוי המצב של תור ההודעות הבלתי ניתנות לטיפול (DLQ): מוודאים שספריית ה-DLQ החמורה של שכפול ההעברה ב-Cloud Storage (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) ריקה לגמרי. אם יש שגיאות חמורות, פותרים את הבעיות הבסיסיות ומפעילים מחדש את כל אירועי השינוי שנכשלו באמצעות משימת אצווה של retryDLQ לפני שמתחילים את המעבר החד למערכת אחרת (cutover). מידע נוסף מופיע במאמר מעקב אחרי שגיאות ב-DLQ של CDC ופתרון שלהן.
  6. הגדרת רפליקציה הפוכה (מוכנות למקרה של כשל): אם אתם צריכים נתיב חלופי למקרה של כשל, הגדירו צינור עיבוד נתונים פעיל של רפליקציה הפוכה מ-Spanner בחזרה למסד הנתונים של MySQL. למידע נוסף, קראו את המאמר הגדרת מעבר ל-MySQL במקרה של כשל.

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

ביצוע מעבר

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

אימות התקינות של צינור עיבוד הנתונים והמצב של DLQ

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

  1. במסוף Google Cloud , נכנסים לדף הפרטים Job details של פייפליין Dataflow להזרמת נתונים.
  2. בכרטיסייה מדדים מותאמים אישית, בודקים את Total permanent errors המונה המותאם אישית.

  3. אם הערך של המונה הזה גדול מ-0, צריך לבדוק את ספריית ה-DLQ החמורה של Cloud Storage (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) ולוודא שהספרייה ריקה.

השהיית כתיבה של אפליקציות

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

מעקב אחרי Datastream והשהיה שלו

  1. במסוף Google Cloud , נכנסים לדף Stream details של השידור.
  2. בכרטיסייה Monitoring, בודקים את התרשים עדכניות הנתונים (סוג המדד ב-Cloud Monitoring: ‏datastream.googleapis.com/stream/freshness). ממתינים עד שערך המדד יורד ל-0. המשמעות היא ש-Datastream תיעד ועיבד את כל השינויים במסד הנתונים של המקור עד לרגע שבו הכתיבה הופסקה. מידע נוסף זמין במאמר בנושא מעקב אחרי סטרימינג.

  3. מוודאים שאירועי רפליקציה לא עוברים דרך הסטרימינג. בכרטיסייה Monitoring, בודקים את התרשים Throughput (סוג המדד של Monitoring: ‏datastream.googleapis.com/stream/event_count) ומוודאים שקצב האירועים הוא 0.

    לחלופין, כדי לבדוק את הנתונים באופן פרוגרמטי באמצעות הכלי 'Metrics Explorer', אפשר להריץ שאילתה על ספירת האירועים באמצעות שפת שאילתת מעקב (MQL): 

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     מחליפים את STREAM_ID במזהה של מקור הנתונים.

    מוודאים שהמדד הזה מדווח על 0 במשך שתי תקופות צבירה רצופות לפחות.

  4. משהים את ה-stream ב-Datastream באמצעותGoogle Cloud המסוף או ה-API, ומחכים שסטטוס ה-stream ישתנה ל-PAUSED.

המתנה עד שנתוני השינויים בתהליך יתפנו

  1. במסוף Google Cloud , נכנסים לדף Stream details של השידור.
  2. בכרטיסייה Monitoring, בודקים את התרשים System latency (סוג המדד של Monitoring: ‏datastream.googleapis.com/stream/system_latencies).
  3. שימו לב לערך זמן האחזור של האחוזון ה-99 (P99) והמתינו לפחות פי שניים מזמן האחזור של מערכת P99, בתוספת 30 שניות אחרי השהיית השידור. תקופת ההמתנה הזו עוזרת לוודא שכל קובצי הנתונים של השינויים שנוצרו לפני ההשהיה נכתבים בבטחה ב-Cloud Storage, ושהאירועים של יצירת האובייקטים שלהם מתפרסמים ב-Pub/Sub.
  4. מוודאים שמשימת הסטרימינג ב-Dataflow צרכה את כל אירועי השינויים בהמתנה. במסוף Google Cloud , עוברים לדף Subscriptions של Pub/Sub ובוחרים את המינוי שנוצר במהלך ההגדרה של העברת הנתונים מ-CDC.
  5. בכרטיסייה Monitoring, בודקים את התרשים Unacknowledged message count (סוג המדד של Monitoring: ‏pubsub.googleapis.com/subscription/num_undelivered_messages) ומוודאים שהספירה היא 0.

איך מוודאים שהשכפול הושלם

  1. מוודאים שצינור עיבוד הנתונים בסטרימינג ב-Dataflow סיים לכתוב את כל השינויים ששוכפלו. בדף פרטי המשימה של משימת הסטרימינג, בוחרים בכרטיסייה מדדים מותאמים אישית, ואז בודקים את מונה המשתמשים Replication lag total latency_MAX. מחכים עד שהערך של המונה יגיע ל-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 total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     מחליפים את JOB_ID במזהה של משימת Dataflow.

  2. מוודאים שפעילות הכתיבה במסד הנתונים של Spanner הופסקה. בדף Database details של מסד הנתונים המטורגט, בוחרים בכרטיסייה Monitoring ובודקים את התרשים Write throughput (סוג המדד למעקב: spanner.googleapis.com/transaction_stat/total/bytes_written_count). מוודאים שקצב העברת הנתונים בכתיבה הוא 0 למשך שתי תקופות צבירה רצופות לפחות של דקה אחת.

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

  4. מרוקנים את משימת הסטרימינג ב-Dataflow:

    1. במסוף Google Cloud , נכנסים לדף Job details של משימת הסטרימינג.
    2. לוחצים על Stop job, בוחרים באפשרות Drain ואז לוחצים על Stop job.
    3. מחכים עד שסטטוס העבודה ישתנה לDrained. מידע נוסף זמין במאמר עצירת צינור עיבוד נתונים פועל.

  5. בדיקת ה-DLQ אחרי הניקוז: אחרי שסטטוס המשימה משתנה ל-Drained, בודקים בפעם האחרונה את הספריות של ה-DLQ לניסיון חוזר ולשגיאות חמורות ב-Cloud Storage. מוודאים שלא הופיעו קובצי שגיאה חדשים בזמן שהנתונים בהעברה נמחקו. אם יש קבצים, פותרים את הבעיה ומפעילים אותם מחדש. מידע נוסף זמין במאמר בנושא מעקב אחרי שגיאות ב-DLQ של CDC ופתרון שלהן.

מעבר חד למערכת אחרת (cutover) של האפליקציה

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

  1. מעדכנים את הגדרות האפליקציה או את מחרוזות החיבור למסד הנתונים כדי להגדיר את מסד הנתונים של Spanner כמטרה.
  2. מפעילים את שירותי האפליקציה ומוודאים שתנועת הקריאה והכתיבה בזמן אמת פועלת בהצלחה ב-Spanner.
  3. עוקבים אחרי צינור עיבוד הנתונים של הרפליקציה ההפוכה כדי לזהות שגיאות. אם פעולת כתיבה ב-Spanner לא מצליחה לשכפל בחזרה ל-MySQL, ‏Dataflow שומר את הרשומה שנכשלה בספריית DLQ ב-Cloud Storage (לדוגמה, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). כדאי לבדוק את הנתיב הזה באופן קבוע כדי לוודא שהוא נשאר ריק. אם מופיעות רשומות שנכשלו, עיינו במאמר מעקב אחרי שגיאות ברפליקציה הפוכה ופתרון שלהן.

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