מדוע MariaDB Galera Cluster מאבד סנכרון תחת עומס
MariaDB Galera Cluster מאשר כתיבה לא על צומת אחד, אלא לאחר שכל המשתתפים אישרו את הטרנזקציה. כל עוד הצמתים מספיקים באותה מידה, אישור הכתיבה והרפליקציה אינם ניתנים להפרדה: אין אובדן נתונים בעת כשל של שרת אחד.
התצורה נשברת בדיוק כאשר צומת אחד מפסיק להספיק — מנגנון ויסות הזרימה מאט את כל האשכול למהירותו של המשתתף האיטי ביותר.
הצעד השני לכשל — נפילת צומת. השרת התנתק מהרשת או נתקע בהעברת מצב מלאה, הנותרים אינם מגיעים לרוב, ופיצול הקוורום מעביר חלק מהאשכול למצב ללא הרשאת כתיבה. היישום מקבל שגיאה על אי-מוכנות הצומת, החיבורים תלויים בהמתנה, והכתיבה נעצרת לחלוטין, אף שהדיסקים תקינים והנתונים במקומם.
מסוכן יותר התרחיש ההפוך: כל עוד האשכול מפוצל, החלק הקטן מצליח לקבל ולאשר טרנזקציות ללקוח, אך לאחר שחזור הקשר הן לא עוברות אישור ונפסלות. כך טרנזקציה מאושרת אינה מגיעה לשאר הצמתים — זו כבר לא עמידות בכשלים של מסד הנתונים, אלא אי-התאמה שיש לאמת ידנית.
בשיא, כשל כזה סביר יותר: תורי האישור גדלים, נעילות כתיבה מוחזקות זמן ארוך יותר, וזינוק בצומת אחד דרך ויסות הזרימה מגביר את ההשהיות בכולם. כל הפעלה מחדש או העברת מצב באשכול חם מפילים את הקוורום בקלות במיוחד.
נבחן כיצד זה נסגר: כיצד לחשב קוורום ומשקל צמתים, כיצד להשאיר צומת מפגר באשכול, וכיצד לבנות תצורה שבה כשל צומת אינו מוביל לחסימת כתיבה.
מה נותנת רפליקציה סינכרונית עם אישור כתיבה
כתיבה נחשבת מאושרת רק כאשר קוורום של צמתים קיבל אותה, ולא שרת ראשי אחד. הלקוח מקבל תשובה רק לאחר קיבוע אצל הרוב — לכן סוג הכשל «אובדן נתונים מאושרים» נעלם: אם צומת נופל מיד לאחר התשובה, הטרנזקציה בכל זאת נשארת על האחרים. MariaDB Galera Cluster מטפל בכך ברמת הרפליקציה עצמה, ללא שינויים ביישום.
בעת כשל צומת, הקוורום מתארגן מחדש בעצמו, וניתוב התעבורה מעביר לקוחות תוך שניות לצמתים חיים. זמן המיתוג נמדד בשניות בודדות ואינו תלוי בנפח מסד הנתונים — המיתוג אינו ממתין להחלת היומנים. היישום רואה ניתוק קצר של חיבורים, ולא השבתה של דקות.
הצומת השב מתאושש באופן חם: הוא מקבל תמונת מצב ומדביק את זרם השינויים, בעוד האחרים ממשיכים לקבל כתיבה. הכתיבה אינה נעצרת — צמצום ההשבתה מושג בכך שהשחזור מתבצע במקביל לעומס העבודה.
המחיר לכך — השהיית הכתיבה נקבעת לפי הצומת האיטי בקבוצה, לכן בוחרים במודע את הרשת בין הצמתים ואת מספרם: קוורום אי-זוגי, בלי משתתפים מיותרים. החוליה החלשה נראית לפי מדדי זרם הרפליקציה, וזה הדבר הראשון שאנו בודקים בעת ההגדרה.
מצבי רפליקציה ב-MariaDB: השוואת אפשרויות
מצבי הרפליקציה נבדלים לא ב«שלמות», אלא במי שמאשר את קיבוע השינוי ומה קורה כאשר יש אי-התאמה בין צמתים. מכך תלויים ההתנהגות בעת כשל, הרגישות להשהיה בין אתרים, ואיזו חזרה לאחור בכלל אפשרית.
| אפשרות | מתי מתאימה | מגבלות המצב |
|---|---|---|
| רפליקציה אסינכרונית | עותקי דוחות, אתרים נפרדים שבהם אובדן השינויים האחרונים מותר | הצומת הראשי מאשר קיבוע בלי להמתין לעותק: בעת כשל לפני העברת היומן, ההבדל הולך לאיבוד ללא אפשרות שחזור |
| רפליקציה חצי-סינכרונית | נדרש איזון בין מהירות הכתיבה להבטחה שהעותק קיבל את היומן | האישור מגיע לפני ההחלה על העותק, לכן בעת מיתוג חלק מהשינויים עדיין מדביקים; ההתנהגות כאשר העותק לא זמין נקבעת לפי מדיניות פסק זמן |
| אישור סינכרוני (Galera) | נתונים קריטיים שבהם אי-התאמה בין צמתים אסורה, והצמתים נמצאים באותה רשת עם השהיה קטנה | הקיבוע עובר רק ברוב הצמתים: אובדן קוורום עוצר את הכתיבה, והגדלת מספר הצמתים מגדילה את זמן התגובה לכתיבה |
| עותק עם השהיית החלה | הגנה מפני שינוי המוני שגוי | אינו מזרז מיתוג, דורש צומת נפרד ומקום פנוי ליומנים |
הבחירה אינה בינארית: בהתקנה אחת, אשכול סינכרוני בדרך כלל נושא מסדי נתונים קריטיים, ועותק אסינכרוני — דוחות ואנליטיקה. כך עומס הקריאה עובר מהמעגל הראשי, ודרישות ההשהיה בין האתרים נשארות ברות-ביצוע.
הטמעת אשכול עמיד בכשלים: שלבי העבודה
אשכול רפליקציה סינכרונית על MariaDB Galera לא בונים אותו על מערכת חיה: סדר העבודות קובע אם המיתוג בעת כשל יהיה צפוי או יהפוך לפעולות ידניות תחת לחץ. כל שלב מסתיים בארטיפקט שאנו בודקים לפני המעבר לשלב הבא.
- ביקורת התצורה הנוכחית. טופולוגיה, גודל נתונים חמים, השהיות בין צמתים, שינויי מבנה מחוץ לנוהל, התנהגות היישום בעת שגיאת כתיבה. התוצאה — מפת צווארי בקבוק ורשימת שאילתות האסורות באשכול: טרנזקציות חוסמות ארוכות, הכנסות המוניות ללא פיצול.
- תכנון טופולוגיה. מספר צמתים, קוורום, ארביטר נפרד מחוץ לאזור הכשל הראשי, מצב אישור טרנזקציה בכתיבה לקוורום. כאן גם מקבעים את ההתנהגות בעת אובדן קוורום: עצירת כתיבה אוטומטית או לפי החלטת התורן.
- הגדרת כתיבה סינכרונית. פרמטרים של זרם הרפליקציה, הגבלת גודל טרנזקציה לצורך הדבקת שינויים, התנהגות הצומת בעת פיגור, העברת הצומת למצב ללא כתיבה. בודקים כיצד היישום שורד חזרה לאחור של טרנזקציה והתחברות מחדש לצומת אחר.
- בדיקות כשל. הוצאה מתוכננת של צומת, עצירה חדה, ניתוק רשת בין אזורים, אובדן קוורום, הרכבה מחדש מלאה של צומת מתורם. מתעדים את זמן שחזור הכתיבה ואת מספר הטרנזקציות המאושרות שאבדו — היעד אפס.
- גיבוי ושחזור. תמונת מצב מצומת תורם, בדיקת שחזור במעגל נפרד, נוהל סנכרון מלא כאשר הדבקת שינויים אינה אפשרית.
- מסירה לתפעול. ניטור מצב הצמתים והפיגור, הוראות לתורן, סדר החלפת צומת ועדכון מבנה בחלון תחזוקה. בהמשך — ליווי, עד שהצוות יבצע החלפת צומת בעצמו.
תצורות, תרשימי קוורום ונוהלי מיתוג
לאחר ההטמעה, לצוות הלקוח נשאר לא רק אשכול עובד, אלא גם סט ארטיפקטים שלפיהם אפשר לתפעל אותו בלעדינו. להלן מה שאנו מעבירים למאגר התצורות של הלקוח ומסבירים במסירה.
- קובצי תצורה של צמתים. סט מלא של פרמטרים לרפליקציה סינכרונית: שם האשכול, מצב אישור כתיבה, התנהגות הצומת בעת אובדן קשר עם הקבוצה, מגבלות על זרם השינויים. מסודרים לפי מכונות ומשוכפלים במערכת בקרת גרסאות.
- תרשים פריסת צמתים. כמה צמתים, באילו אזורי זמינות, כיצד מופץ הקוורום, אילו השהיות בין אתרים תוכננו ולמה דווקא הרכב מצביעים כזה.
- נוהל מיתוג. סדר שלב-אחר-שלב להוצאה מבוקרת של צומת, פעולות בעת אובדן קוורום, הנקודה שבה מתקבלת ההחלטה להעביר תעבורה לאתר גיבוי.
- כללי גישה. תפקידים ליישום, לאבחון שירותי ולשחזור, מאיפה מותר להתחבר, למי יש הרשאה לשנות פרמטרים של האשכול וכיצד זה מתועד.
- תיעוד שחזור. תרחישים לאתחול קר של הקבוצה, העלאת צומת מפגר אחד, סדר עבודה עם גיבוי והשוואת מצב לאחר החזרה.
- רשימות בדיקה. בדיקות לפני שינוי תצורה, לאחר מיתוג חירום, ובקרה שוטפת של אי-התאמת נתונים בין צמתים.
- מפת מדדים והתראות. אילו מדדים של צומת ושל אשכול נחשבים לתקינים, אילו דורשים התערבות של התורן, ולמי נשלחת ההתראה.
מקרה בוחן: אשכול של חנות אינטרנטית ללא השבתה בעת כשל צומת
איך היה לפני
החנות עבדה על מסד נתונים ראשי אחד ורפליקציה אסינכרונית. כאשר צומת נפל, העותק פיגר, וחלק מההזמנות שבוצעו ברגע הכשל נעלמו — שיעור הטרנזקציות שאבדו הגיע ל-0.3% מהזרימה היומית. על אי-ההתאמות נודע מתלונות קונים, כלומר רק לאחר שהלקוח לא קיבל אישור להזמנה.
המיתוג נעשה ידנית: המהנדס התורן העלה את העותק, שינה את נקודת החיבור בתצורת היישום, ורק אחר כך הסיר את מצב התחזוקה. זמן ההשבתה עמד על 4 עד 11 דקות, וכל כשל רביעי הסתיים בהרכבה ידנית מחדש של הצומת מגיבוי.
מה שינו ומה נהיה
הרכיבו אשכול משלושה צמתים עם רפליקציה סינכרונית: כתיבה מאושרת רק לאחר שרוב הצמתים קיבלו אותה, לכן אובדן הזמנות בעת כשל של צומת אחד הפסיק להיות אפשרי. הכשל מטופל אוטומטית — שני הצמתים הנותרים שומרים על קוורום, והאשכול ממשיך לקבל כתיבות ללא מעורבות התורן.
זמן המיתוג הצטמצם מדקות ל-3-8 שניות, שיעור הטרנזקציות שאבדו — מ-0.3% לאפס, שיעור השחזורים הידניים — מרבע מהכשלים לאחד מעשרה, ורק כאשר דיסק הצומת אינו זמין כלל. ניתוח האירוע אורך כ-20 דקות: ביומן רואים איזה צומת נפל, למה ומתי חזר לפעילות — קודם לכן השוואת לוגים ארכה שעות.
את ההגדרות הצלבנו עם שני מקורות בלתי תלויים — תיעוד Galera Cluster ו-דוחות קהילה בנושא קוורום: הם מאשרים שהמצב הנבחר נותן כשל צפוי, ולא אובדן נתונים שקט.
מה לעשות אם כבר פרוס אשכול אסינכרוני?
המעבר אפשרי ללא חלון אי-זמינות ארוך: הנתונים על העותקים כבר קיימים, משתנה רק אופן הקבלה שלהם ואישור הכתיבה. הסדר כאן הפוך מהרגיל — תחילה מכניסים לאשכול הסינכרוני עותק אחד, והמאסטר הנוכחי ממשיך לעבוד כמו קודם.
לפני כן בודקים את התצורה הנוכחית. כל הטבלאות צריכות להיות InnoDB ועם מפתח ראשי: בלי מפתח, החלה סינכרונית של שורות עובדת בלי יעילות.
בודקים אם הפיגור של הרפליקציה לא גדל, אם הסכמות בצמתים תואמות, ואם אין חיבורים ישירים לעותקים לצורך קריאה — לאחר המיתוג אלו כבר משתתפים שווי זכויות באשכול. בנפרד — טרנזקציות ארוכות ושינוי מבנה טבלאות: הם מתואמים בין הצמתים ועל טבלה גדולה יכולים להאט את הכתיבה.
תאימות לאחור של יישומים — הסיכון המרכזי. תצורה אסינכרונית סובלת קונפליקטים: אי-ההתאמות מצטברות וצפות מאוחר יותר. סינכרונית מחזירה אותם מיד כשגיאת טרנזקציה, לכן הקוד צריך לדעת לחזור על הפעולה, ולא לקרוס. השני — נקודת החיבור: מאסטר שמוגדר לפי שם מוחלף בכתובת האשכול, אחרת פיזור הכתיבה לא יעבוד.
תוכנית המיגרציה: מקבעים הגדרות, מעלים צומת חדש לצד העותק ומעבירים נתונים בהעתק פיזי — העברה באמצעות דאמפ יוצרת בדיוק את החלון הארוך הזה. לאחר מכן מעבירים את היישום, מוסיפים את שאר הצמתים ועוקבים אחר הקוורום. חלון אי-הזמינות עצמו — דקות להחלפת נקודת החיבור ובדיקת כתיבה וקריאה. החזרה לאחור פשוטה: להחזיר את היישום למאסטר הקודם, הוא נשאר גיבוי קר עד שהאשכול יעבוד תחת עומס.
שאלות טכניות נפוצות לפני הטמעת אשכול
בשלב התכנון חשוב לבדוק לא את הרפליקציה עצמה, אלא את התנהגות האשכול בתרחישי חירום: ניתוק קשר בין אתרים, הוספת צומת תחת עומס, זמן תגובת כתיבה. להלן חמש שאלות ברמת הנדסה עם תשובות קצרות.
כמה צמתים נדרשים לקוורום?
שלושה — ההרכב המינימלי שבו האשכול שורד כשל של צומת אחד ושומר על קוורום. שני צמתים עמידים לכשלים, אך בלי רזרבה: אובדן אחד משאיר קול אחד, והאשכול עובר למצב קריאה בלבד. לשני אתרים מוסיפים ארביטר קל ללא עותק נתונים.
מה קורה בעת פיצול רשת?
החלק הקטן מאבד קוורום ועובר למצב קריאה בלבד — הכתיבה עליו נעצרת כדי שגרסאות הנתונים לא יתפצלו. החלק הגדול ממשיך לשרת טרנזקציות, ולאחר שחזור הקשר הצמתים המפגרים מדביקים את המצב בעצמם.
אפשר להוסיף צומת תוך כדי עבודה?
כן, אין צורך בעצירת השירות. הצומת החדש מקבל עותק נתונים ומצטרף להצבעה רק לאחר ההדבקה. בזמן העברת עותק מלאה, צומת אחד משמש כתורם — מפזרים מראש את העומס שלו כדי לא לפגוע בזמן התגובה.
האם רפליקציה סינכרונית מאטה את הכתיבה?
את תגובת הכתיבה קובעת השהיית הרשת בין הצמתים, ולא הדיסק. בתוך אתר אלו שברי מילישניות, בין אזורים — מורגש יותר. קיבוע קבוצתי מאחד טרנזקציות מקבילות לסבב תיאום אחד, לכן תפוקת המערכת בעומס המוני אינה נפגעת.
כיצד צומת מתאושש לאחר כשל?
לאחר היעדרות קצרה הוא מדביק שינויים מהיומן וחוזר לפעילות בלי עותק מלא של מסד הנתונים. אם הפיגור גדול יותר מאשר היומן שנשמר, מופעלת העברה מלאה. אי-התאמת נתונים בין צמתים מזוהה בנפרד ודורשת הרכבה מחדש של הצומת.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שההערכה תהיה עניינית ולא «בעין», להתחלה נדרשים נתוני מקור על התשתית ודרישות זמינות. תארו את תצורת הרפליקציה הנוכחית, מספר הצמתים והאתרים, נפחי מסדי הנתונים ופרופיל עומס הכתיבה — זה מספיק כדי להבין אילו מצבי קוורום וסנכרון יתאימו בדיוק לכם.
- תצורת הטופולוגיה הנוכחית: כמה צמתים, כיצד הם מפוזרים בין אתרים, היכן נמצאים כעת נקודות הכשל.
- נפחים ואופי העומס: גודל מסדי הנתונים, יחס קריאה לכתיבה, תקופות שיא.
- דרישות זמינות: זמן השבתה מותר בעת מיתוג והאם נדרש מעבר אוטומטי בעת כשל צומת.
- דרישות עקביות: אילו טרנזקציות חייבות להיות מאושרות ברוב הצמתים, והיכן מספיקה רפליקציה אסינכרונית.
- כיצד בנויים הגיבוי והשחזור — כדי שתוכנית העבודה לא תשבור נהלים קיימים.
- מגבלות חלון העבודה: מתי אפשר לשנות תצורה בלי להשפיע על המשתמשים.
בתמורה נחזור עם תוכנית עבודה להטמעה: מעבר הדרגתי של צמתים, הרכב האשכול, סדר הבדיקות וסדר הקבלה עם קריטריונים מדידים. מראש מקבעים איזה כשל האשכול חייב לשרוד ותוך כמה זמן הוא חוזר לשגרה לאחר כשל. תארו את המשימה — נדון בפרטים ונחזור עם הערכה ותוכנית.