העברת MySQL אונליין עם gh-ost ללא זמן השבתה: מדריך שלב אחר שלב

למה הגירת טבלת MySQL בלי gh-ost עוצרת את השירות

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

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

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

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

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

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

מה משתנה בפועל: זמן הנעילה וסוגי כשלים

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

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

עומס על המאסטר והתנהגות הרפליקות

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

חלון החזרה אחורה וסוג הכשלים שנעלם

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

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

השוואת גישות: gh-ost, טריגרים ובנייה מחדש של טבלה

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

היכן נשברת גישת הטריגרים

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

היכן gh-ost דורש בדיקה

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

שלבי הגירה מקוונת: ממדידת עומס ועד החלפת התעבורה

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

הכנה ובדיקות

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

הרצה, החלפה ובקרה

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

ארטיפקטים של הגירה: קונפיגורציות, סכימות רפליקציה, נהלים

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

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

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

כל סעיף עובר סקירה לפני ההתחלה, ולא אחריה: נוהל חזרה אחורה שאף אחד לא קרא חסר תועלת ברגע התקלה.

מקרה בוחן: הגירה מתוכננת של טבלה גדולה בלי עצירת השירות

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

מה לא הלך לפי התוכנית

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

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

מה לעשות אם הרפליקה מפגרת ברגע ההחלפה?

פער של רפליקה הוא התרחיש הנפוץ ביותר שבו הגירה מקוונת מפסיקה להיות בטוחה. בזמן ש-gh-ost מעביר שורות לטבלת הצל, הרפליקות מקבלות את אותו זרם אירועים, אבל מיישמות אותו לאט יותר מהמאסטר.

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

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

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

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

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

ספקות טכניים: נעילות, חזרה אחורה ופער רפליקות

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

מה יקרה אם תהליך ההגירה ייקטע?

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

האם נדרשת גישה ישירה לשרת המאסטר?

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

האם אפשר להגר כמה טבלאות בו-זמנית?

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

נדון בהגירה שלכם: סכימה, סיכונים, תוכנית עבודה

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

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

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