הגדרת MongoDB Replica Set לזמינות גבוהה: בפועל

מדוע MongoDB Replica Set מדרדר תחת עומס

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

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

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

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

מה נותן קלאסטר של רפליקות: זמינות ומחלקות כשל

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

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

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

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

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

סט רפליקות MongoDB: השוואת טופולוגיות ומצבים

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

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

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

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

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

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

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

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

תוצרי הפרויקט: קונפיגורציות, סכמות ונהלי תחזוקה

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

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

מקרה בוחן: העברת בסיס נתונים לסט רפליקות בלי השבתה

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

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

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

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

במה סט רפליקות שונה מקלאסטר משורד?

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

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

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

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

ספקות טכניים בתפעול הקלאסטר

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

כמה צמתים להחזיק בסט?

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

איך לוודא שהמעבר עובד?

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

האם נדרשים גיבויים אם יש רפליקציה?

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

נדבר על המשימה: מה נדרש מכם להתחלה

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

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

מה לשלוח להתחלה:

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

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