MySQL InnoDB Cluster: מעבר אוטומטי עם Shell ו-Router

MySQL InnoDB Cluster: היכן נשבר המעבר האוטומטי

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

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

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

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

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

מה נותן המעבר האוטומטי: אפקט מדיד

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

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

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

שיעור המעברים האוטומטיים

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

יכולת חיזוי של כשלים וקוורום צמתים

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

חלון עבודות מתוכננות

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

סכמות עמידות כשלים של MySQL: אתר אחד, שני מרכזי נתונים, ענן

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

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

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

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

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

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

1. ביקורת טופולוגיה. מסירים מפת שרתים, גרסאות, מצב שכפול, נפחים ופרופיל עומס. מתעדים נקודות כשל נוכחיות ומבררים אילו צמתים בכלל מסוגלים לקבל את תפקיד הראשי בלי לאבד נתונים.
2. תכנון סכמת האשכול. קובעים מספר צמתים וקוורום, פריסה לפי אזורי זמינות, מצב אישור כתיבה והתנהגות בעת אובדן קשר בין אתרים. כאן גם מחליטים היכן למקם Router ואיך לפזר עומס קריאה.
3. הכנת נתונים והעברתם. ממירים נתונים לפורמט מוסכם, משחזרים בצמתים החדשים, משווים סכומי בקרה לפי טבלאות. פערים מטופלים לפני הפעלת האשכול, לא אחרי.
4. הגדרת מעבר. מגדירים ספי כשל, עדיפויות צמתים, פסקי זמן ומדיניות החזרת הצומת הראשי הקודם. בנפרד מתארים מה קורה לאפליקציה ברגע החלפת המנהיג.
5. בדיקת תרחישי כשל. בתורו מוציאים מכלל פעולה צומת ראשי, רפליקה, Router ואזור שלם — מודדים זמן התאוששות הכתיבה ושלמות הנתונים אחרי החזרה לפעילות. התרחיש חוזר עד שהתוצאה הופכת לצפויה.
6. מסירה לתפעול. מוסרים סכמות, מדיניות, נוהל גיבוי ושחזור, ורשימת בדיקה לתורן. מדריכים את המשמרת: איך לקרוא את מצב האשכול, מה לעשות באובדן קוורום ומתי להסלים.

תצורות, סכמות ונוהלים: ערכה במסירה

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

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

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

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

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

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

מה שינו

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

את הניתוב העבירו ל-Router עם מדיניות «רק הצומת הראשי», ואת התזמור ל-Shell: העלאת צומת, יציאה מפיצול רשת ומעבר כפוי בעת אובדן קוורום מתבצעים לפי נוהל, לא לפי הזיכרון של התורן.

מדדים לפני ואחרי

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

עמידות הכשלים גדלה בלי להרחיב את מלאי השרתים: אותם שלושה צמתים עכשיו שורדים אובדן של אחד מהם בלי עצירת כתיבה.

מה לעשות אם מסד הנתונים כבר פרוס, והמעבר נעשה ידנית?

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

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

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

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

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

ספקות טכניים נפוצים: עונים לגופם

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

איך האשכול מתנהג באובדן קשר בין אתרים?

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

האם צריך לשנות את האפליקציה?

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

איך לשלב גיבוי עם תחזוקה מתוכננת?

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

נדון במשימה שלך: מה להבהיר לפני ההתחלה

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

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

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