העברה מ-MySQL ל-Spanner

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

ההעברה ל-Spanner מחולקת לשלבים הבאים:

  1. הערכת ההעברה.
  2. מעבירים את הסכימה ומתרגמים את שאילתות ה-SQL.
  3. מעבירים את האפליקציה לשימוש ב-Spanner בנוסף ל-MySQL.
  4. טוענים נתוני מדגם ומבצעים אופטימיזציה של הביצועים.
  5. מעבירים את הנתונים.
  6. מאמתים את ההעברה.

הערכת ההעברה

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

העברת הסכימה

אתם ממירים את הסכימה הקיימת לסכימה של Spanner באמצעות כלי המיגרציה של Spanner.

מידע נוסף זמין במאמר בנושא העברת סכימה מ-MySQL.

העברת האפליקציה לשימוש ב-Spanner

ב-Spanner יש קבוצה של ספריות לקוח לשפות שונות, ואפשר לקרוא ולכתוב נתונים באמצעות קריאות ל-API שספציפיות ל-Spanner, וגם באמצעות שאילתות SQL והצהרות של שפת שינוי נתונים (DML). יכול להיות ששימוש בקריאות ל-API יהיה מהיר יותר עבור שאילתות מסוימות, כמו קריאות ישירות של שורות לפי מפתח, כי לא צריך לתרגם את הצהרת ה-SQL.

‫Spanner מספק JDBC driver לאפליקציות Java.

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

רמת הבידוד שמוגדרת כברירת מחדל לעסקאות ב-Spanner היא בידוד שניתן להפוך לסדרתי, מה שמבטיח עקביות חיצונית של הנתונים. ב-Spanner יש גם בידוד של קריאה חוזרת. כחלק מתהליך ההעברה של האפליקציה, מומלץ להגדיר את רמת הבידוד ל-repeatable read ואת בקרת הבו-זמניות ל-pessimistic concurrency, כדי שסמנטיקת הטרנזקציות של Spanner תתאים לסמנטיקת הטרנזקציות שמוגדרת כברירת מחדל ב-MySQL. הוראות להגדרת רמת הבידוד ובקרת בו-זמניות באפליקציה מפורטות במאמרים שימוש ברמת בידוד של קריאה חוזרת והגדרת בקרת בו-זמניות.

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

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

טעינת נתונים לדוגמה ל-Spanner

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

אתם יכולים להשתמש בתהליך העבודה של BigQuery reverse ETL וב-Google Cloud CLI כדי לטעון כמות קטנה של נתונים בפורמט קובץ CSV ל-Spanner.

מידע נוסף זמין במאמר טעינת נתונים לדוגמה.

כדי להעביר את הנתונים מ-MySQL ל-Spanner, אפשר גם לייצא את מסד הנתונים של MySQL לפורמט קובץ נייד – לדוגמה, XML – ואז לייבא את הנתונים האלה ל-Spanner באמצעות Dataflow.

העברת נתונים ל-Spanner

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

מידע נוסף זמין במאמר העברת נתוני MySQL.

אימות העברת הנתונים

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

אפשר להשתמש ב-Dataflow כדי לבצע השוואה מפורטת של קבוצות נתונים גדולות באמצעות join transform. הטרנספורמציה הזו מקבלת 2 קבוצות נתונים עם מפתחות, ומתאימה את הערכים לפי המפתח. לאחר מכן אפשר להשוות בין הערכים התואמים כדי לבדוק אם הם שווים. אתם יכולים להפעיל את האימות הזה באופן קבוע עד שרמת העקביות תתאים לדרישות העסקיות שלכם.

מידע נוסף זמין במאמר אימות של העברת הנתונים.

הגדרת חלופות ומעבר חד למערכת אחרת (cutover)

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

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

תהליך הרפליקציה ההפוכה כולל את השלבים הבאים, שמבוצעים על ידי תבנית Dataflow של spanner-to-sourcedb:

  1. קריאת שינויים מ-Spanner באמצעות סנכרון שינויים בזרמי נתונים של Spanner.

  2. לסנן את השינויים שהועברו.

  3. משנים את הנתונים ב-Spanner כדי שיתאימו לסכימה של מסד הנתונים במקור.

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

  5. כתיבת נתונים למסד הנתונים של המקור.

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