failover אוטומטי של בסיס נתונים: היכן כשל של צומת עוצר את השירות
כשל של הצומת הראשי לעיתים רחוקות נראה כמו תקלה יפה — לעיתים קרובות מדובר בתהליך תקוע, בירידה בביצועי הדיסק או בפיצול רשת, שבו הרפליקה формально חיה, אך האפליקציה כבר לא כותבת.
ללא failover אוטומטי של בסיס הנתונים, ההחלפה נופלת על התורן: עליו להבחין בבעיה, לוודא שזו לא התראת שווא, להעלות ידנית את הרפליקה ולהעביר את התעבורה. בזמן החקירה הזו, השירות מושבת.
המחיר של החלפה ידנית של רפליקה מורכב משני חלקים. הראשון — השבתה של בסיס הנתונים: בזמן שהמהנדס מתעסק בכך, מצטברות שגיאות כתיבה, גדלות התורים, וחלק מהבקשות נופלות בגלל timeout.
השני — אובדן טרנזקציות: אם הרפליקה פיגרה אחרי המאסטר, בעת ההעלאה היא הופכת למקור האמת החדש, וכל מה שלא הספיק להגיע נעלם ללא אפשרות שחזור. הלקוח רואה לא "בסיס הנתונים לא זמין", אלא הזמנה שנעלמה או תשלום שהוכפל.
סוג נפרד של כשלים — דעיכה "שקטה". הצומת מגיב לבדיקות, אך מפסיק לקבל כתיבות; הרפליקציה נעצרת בגלל קונפליקט או הצפת יומן. ניטור חיצוני לפי ping בודד לא תופס זאת, וניתוח ידני אורך עשרות דקות — בדיוק במקום שבו הספירה היא בשניות.
failover אוטומטי בנוי לא כ"כפתור", אלא כמערכת של תנאים: מי ולפי אילו סימנים מכיר בצומת כמת, כיצד נבחרת רפליקה חדשה, כיצד מגנים מפני פיצול רשת כדי לא להעלות שני מאסטרים. להלן נבחן כיצד זה מכוסה עבור PostgreSQL ו-MySQL — מבחירת רפליקה חדשה ועד החזרת התעבורה.
איך עובד failover אוטומטי: מצבים, מדדים, בחירת סכימה
failover אוטומטי של בסיס נתונים הוא לא "לסמן תיבת סימון", אלא בחירת סכימת מעבר המתאימה לפרופיל העומס. להלן שלוש תצורות עבודה שאנחנו פורסים, והמגבלות הכנות של כל אחת.
סכימה עם ארביטר קוורום
צומת ארביטר קל ונפרד מצביע בעד קידום הרפליקה ואינו מאחסן נתונים. הקלאסטר שורד נפילה של הצומת הראשי ללא התערבות ידנית: זמן ההתאוששות מסתכם בעשרות שניות, ו-Split-brain נמנע. המגבלה — הארביטר עצמו הופך לנקודת כשל, ולכן ממקמים אותו באזור זמינות נפרד.
מצב רפליקציה סינכרונית
טרנזקציה מאושרת רק לאחר כתיבה לרפליקה — שיעור הטרנזקציות שאבדו יורד לאפס. המחיר: השהיית הכתיבה גדלה בזמן האישור, ובמקרה של ירידת ביצועי הערוץ ייתכן חסימת כתיבה. מתאים לקונטורים פיננסיים וחשבונאיים, שבהם אובדן של אפילו טרנזקציה אחת אינו מתקבל על הדעת.
רפליקציה אסינכרונית עם קידום מהיר
הכתיבה אינה ממתינה לרפליקה, ולכן ההשהיה מינימלית. במקרה של תקלה ייתכן אובדן של הטרנזקציות האחרונות — החלון נמדד בשניות. בחירה לשירותי read-heavy, שבהם המהירות חשובה יותר מעקביות קפדנית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ארביטר קוורום | שירות קריטי, נדרש קידום אוטומטי | צומת נוסף באזור נפרד |
| רפליקציה סינכרונית | פיננסים, חשבונאות, איסור על אובדן טרנזקציות | עלייה בהשהיית הכתיבה, סיכון לחסימה |
| רפליקציה אסינכרונית | read-heavy, תפוקה גבוהה | חלון לאובדן הטרנזקציות האחרונות |
המדדים שלפיהם אנחנו בוחרים סכימה: זמן התאוששות, שיעור הטרנזקציות שאבדו, מספר ההתערבויות הידניות ברבעון. לתזמור אנחנו משתמשים ב-Patroni — הוא מנהל את הקידום ושומר על הקוורום דרך אחסון מבוזר.
ננתח את פרופיל העומס שלכם ונתאים לו סכימה.
הטמעת מעבר אוטומטי: שלבי העבודה ההנדסית
failover אוטומטי של בסיס נתונים אינו מסתכם בהתקנת דמון-משגיח אחד: מעבר הוא תוצאה של טופולוגיה מתוכננת כהלכה, רפליקציה וכללי הצבעה. לכן מתחילים בביקורת, ולא בהגדרה, ומביאים לבדיקה באמצעות כשל אמיתי.
- ביקורת טופולוגיית בסיס הנתונים. מתעדים את התמונה הנוכחית: היכן המאסטר, אילו רפליקות (סינכרוניות או אסינכרוניות), כיצד האפליקציה מתחברת — דרך מאגר חיבורים, פרוקסי או ישירות לפי כתובת. מתעדים נקודות כשל: צומת-מתאם יחיד, היעדר קוורום, העברת מאסטר ידנית.
- תכנון סכימת המעבר. מגדירים את המודל: ראשי-משני עם קידום אוטומטי או סכימת קוורום עם קונצנזוס מבוזר. קובעים ספים — כמה שניות של שתיקת המאסטר נחשבות לכשל, כמה רפליקות צריכות לאשר את הקידום כדי למנוע "שני מאסטרים" ופערים בנתונים.
- הגדרת הרפליקציה. מסדירים את זרימת הנתונים: מצב סינכרוני לטרנזקציות קריטיות, בקרת פיגור הרפליקות, טיפול נכון בקונפליקטים לאחר הקידום. מעבירים את האפליקציה לכתובת-מתווכת שעוברת החלפת מאסטר ללא עריכת קונפיגורציות.
- בדיקה באמצעות כשל. מדמים נפילת מאסטר, פיצול רשת, החזרת הצומת הישן לפעילות. מודדים את זמן המעבר ובודקים שהאפליקציה שיקמה את הכתיבה ללא התערבות ידנית, ושהנתונים לא אבדו.
- מסירת תיעוד. מוסרים את סכימת הטופולוגיה, כללי ההצבעה, הוראות למעבר מתוכנן ול� Rollback, וכן ניתוח תרחישים שבהם האוטומציה במכוון אינה פועלת.
סדר העבודות בנוי כך שכל שלב נבדק לפני המעבר לשלב הבא: רפליקציה לא בדוקה בשלב התכנון מתבטאת בפערים בנתונים כבר בכשל אמיתי ראשון. תארו את הקונפיגורציה הנוכחית שלכם — נחזור עם הערכה ותוכנית עבודה.
במה שונה failover אוטומטי מהחלפה ידנית ומאיזון עומסים?
failover אוטומטי של בסיס נתונים פותר בעיה שאף החלפה ידנית ואף איזון קריאה לא מכסים. אלה שלושה מנגנונים שונים, ובלבול ביניהם פירושו להשאיר את המערכת ללא הגנה בדיוק בנקודה הפגיעה ביותר.
החלפה ידנית היא כאשר מהנדס מבחין בתקלה ומעלה ידנית רפליקה לתפקיד הלידר. עד שהוא מגיב, הכתיבה מושבתת: האפליקציות מקבלות שגיאות, טרנזקציות מתבטלות, והתור של הפעולות המצטברות גדל. בלילה, בסופי שבוע, ברגע של עומס שיא — התגובה אורכת דקות, וכל אותו זמן תהליכי העסק לא עובדים.
failover אוטומטי מוציא את האדם מהשרשרת הזו: המערכת עצמה מזהה את אובדן הלידר, בוחרת את הרפליקה המעודכנת ביותר ומעבירה אותה למצב כתיבה.
איזון קריאה עוסק במשהו אחר. הוא מפזר בקשות קריאה בין הרפליקות כדי להפחית את העומס על הצומת הראשי. זה קשור לביצועים, ולא לעמידות בפני כשל בכתיבה: אם הלידר נפל, מאזן העומסים ימשיך לחלק קריאות, אבל לא יהיה לאן לכתוב נתונים. לכן איזון קריאה ו-failover אוטומטי אינם חלופות, אלא שני רבדים של אותה ארכיטקטורה.
המושג המרכזי כאן הוא תפקיד הלידר. בכל רגע רק צומת אחד מקבל כתיבה; שאר הרפליקות מדביקות אותו לפי יומן השינויים. failover אוטומטי עוקב אחרי תקינות הלידר, ובמקרה של כשל מעביר את תפקידו לצומת הבא, ושאר הרפליקות מוגדרות מחדש למול הלידר החדש. חלוקת העומס על הקריאה נשמרת — רק נקודת הכתיבה משתנה.
המסקנה המעשית: איזון קריאה מרחיב את קיבולת העומס, אבל לא מציל מפני כשל. עמידות בפני כשל בכתיבה מובטחת דווקא על ידי failover אוטומטי — ורק הוא מקצר את זמן ההשבתה מדקות של התערבות ידנית לשניות. תארו את התצורה שלכם — נחזור עם הערכה ותוכנית יישום.
מקרה בוחן: צמצום זמן ההשבתה בעת כשל צומת באשכול מסד נתונים
הלקוח הגיע עם תמונה קלאסית: צומת ראשי של האשכול ורפליקה, מעבר ידני לפי הנחיות בוויקי. בעת כשל של הצומת הראשי, המהנדס התורן היה מעלה את הרפליקה ידנית — בדיקת פיגור, העברה למצב כתיבה, החלפת מחרוזת החיבור באפליקציה, חימום מטמון.
לפי יומני האירועים, שחזור השירות ארך בין 25 ל-40 דקות, ובשליש מהמקרים המעבר בוצע עם שגיאות: האפליקציה המשיכה לכתוב לצומת שקרס, חלק מהטרנזקציות אבדו, והחזרה לאחור דרשה חלון השבתה נוסף.
פירקנו את שרשרת הכשל והוצאנו ממנה את האדם. האשכול קיבל בורר קוורום, שמאשר את מצב הצמתים ומונע משתי רפליקות להחשיב את עצמן כראשיות בו-זמנית — זה סוגר את בעיית ה-split-brain בעת ניתוק התקשורת בין האתרים. מצב הצמתים נבדק לפי מספר סימנים בלתי תלויים, ולא לפי פינג בודד.
האפליקציה עוברת לצומת הראשי החדש דרך מאגר חיבורים עם בדיקת חיות: מחרוזת החיבור מובילה לכתובת וירטואלית, והחלפת הצומת אינה דורשת עריכת תצורה והפעלה מחדש של השירותים.
מה השתנה במדדים
| מדד | לפני | אחרי |
|---|---|---|
| זמן שחזור השירות | 25-40 דקות | 40-90 שניות |
| שיעור המעברים המוצלחים | ~70% | 100% בכשלים מתורגלים ובכשלים אמיתיים |
| פעולות ידניות של התורן | 8-12 שלבים | 0 בעת כשל שגרתי |
| אובדן טרנזקציות בעת מעבר | עד כמה מאות | 0 במצב רפליקציה סינכרונית |
בנפרד בדקנו את הצד ההפוך: האוטומציה לא אמורה לפעול על פרצי רשת קצרי טווח. סף אישור הכשל וההשהיה לפני המעבר מכוונים כך שתקלת תקשורת קצרה אינה מפעילה החלפת צומת ראשי, וכשל אמיתי — כן מפעיל. במשך חצי שנה של תפעול לא נרשם אף מעבר שגוי.
פעולות ידניות נותרו רק במקומות שבהם הן מתאימות: תחזוקה מתוכננת והחזרת צומת לפעילות לאחר תיקון. זה הפחית את העומס על התורנים והסיר את מקור השגיאות העיקרי — החיפזון ברגע התקלה.
Patroni
התלבטויות לפני הטמעה: תאימות, מיגרציה, נסיגה והרשאות
failover אוטומטי הוא תוספת מעל הרפליקציה הקיימת, ולא החלפה של התשתית. אם כבר מוגדר לכם העברת שינויים בזרימה (streaming) בין הצומת הראשי לרפליקה, אנחנו מוסיפים שכבת ניהול: סוכן ניטור, קוורום לבחירת מנהיג חדש וניתוב תעבורה.
סכמות הנתונים, האינדקסים והרשאות המשתמשים הקיימים נשארים ללא שינוי — משתנה רק מי מקבל את ההחלטה על המעבר וכיצד מהר.
מה אם הגרסה הנוכחית של בסיס הנתונים אינה תומכת במצב הנדרש? אנחנו בודקים זאת בשלב הניתוח: משווים את הענף, קיום ההרחבות והטופולוגיה של הרפליקות, ולאחר מכן מציעים либо שדרוג לענף עדכני, либо סכמה עם צומת ביניים-בורר (arbiter). כיצד מתבצעת המיגרציה?
בשלבים: תחילה הרפליקה-מועמדת מוכנסת לקוורום, לאחר מכן העומס מועבר אליה במצב קריאה, ורק לאחר הרצת בקרה המעבר הופך לאוטומטי. מה אם לאחר ההטמעה משהו ישתבש? הליך הנסיגה מתואר מראש: החזרה לצומת הקודם, הסרת הסוכן מהקוורום ושחזור השליטה הידנית אורכים דקות, ולא שעות.
מי יקבל גישה לצמתי הניהול וכיצד היא מופרדת?
ההרשאות ניתנות לפי תפקידים: תפעול רואה את מצב הקלאסטר ויכול ליזום מעבר ידני, פיתוח — רק מטריקות ולוגים. פעולותprivileged עם הקוורום והגדרות הסוכן זמינות למעגל מצומצם עם רישום חובה ביומן ביקורת. מפתחות וטוקנים נשמרים במאגר מאובטח, ולא בקבצי הגדרה על הדיסק.
לידי הלקוח נמסר סט מלא:
- הגדרות של סוכן הניטור, הקוורום והנתב תעבורה עם הערות לכל פרמטר.
- סכמה של הטופולוגיה הנוכחית והמיועדת עם ציון תפקידי הצמתים ונקודות הכשל.
- מדיניות הפרדת הרשאות: תפקידים, זכויות, סדר מתן ושלילה.
- נוהל מעבר ידני והליך נסיגה עם פקודות שלב-אחר-שלב.
- סט בדיקות לבקרת מצב הקלאסטר וספי הפעלה.
- תיעוד תפעולי: מה לבדוק ראשון בעת תקלה ולאן לפנות בהמשך.
תארו את הטופולוגיה הנוכחית ואת גרסת בסיס הנתונים — נחזור עם הערכה, תוכנית מיגרציה ורשימת עבודות לקונטור שלכם.
לוחות זמנים ליישום failover אוטומטי לפי שלבים
לוחות הזמנים אינם תלויים בגודל מסד הנתונים, אלא במספר נקודות הכשל בסכמה הנוכחית: צומת בודד עם מיתוג ידני עובר מהר יותר מאשר מפל רפליקות עם מאזן עומסים והפרדת קריאה/כתיבה. להלן משך זמן משוער לפי שלבים, ללא תלות בתאריכים קלנדריים. הערכה עבור התצורה שלכם תינתן לאחר ביקורת.
השלבים חופפים חלקית: התכנון מתנהל במקביל להכנת סביבת הבדיקה, והנהלים נכתבים כבר במהלך היישום. הנקודה הכי פחות צפויה היא ההרצה: דווקא שם צפים פערים בגרסאות, הרחבות לא סטנדרטיות ושאילתות שלא שורדות החלפת תפקיד. לכן אנחנו לא מקצרים את סביבת הבדיקה — זול יותר לתפוס split-brain על עותק מאשר בפרודקשן.
בנפרד אנחנו מקצים זמן לחלון תצפית לאחר המסירה: במשך שבוע המשמרת התורנית עובדת עם הסכמה החדשה תחת השגחתנו, ורק אחר כך סוגרים את הפרויקט. משך הזמן הכולל לתצורה טיפוסית — משלושה עד שישה שבועות; מפל רפליקות ופריסה גיאוגרפית מוסיפים לכך שבוע עד שבועיים.