שדרוג גרסה ראשית של MongoDB: מדריך שלב-אחר-שלב ללא השבתה

שדרוג גרסה ראשית של MongoDB: מדריך שלב-אחר-שלב ללא השבתה

שדרוג MongoDB מ-4.4 ל-6.0 אינו apt upgrade mongodb. נתקלנו במצבים שבהם צוותים לא עדכנו שנים ולאחר מכן רצו לקפוץ מ-4.0 ל-7.0, וסיימו עם חמישה שלבים רצופים. בעיות נפוצות כוללות אי-תאימות דרייברים, אינדקסים מיושנים ואזהרות deprecation נסתרות. MongoDB דורש שדרוג רציף דרך כל גרסה ראשית: 4.4 → 5.0 → 6.0. דילוג על גרסה אינו מותר. אם אתה על 4.2 וצריך 7.0 — זה ארבעה שדרוגים. כל אחד דורש אישור דרך setFeatureCompatibilityVersion. אנו מבטיחים שהמסד נתונים שלך יעבור את כל השלבים עם אפס אובדן נתונים והשבתה מינימלית. לפי סטטיסטיקות, עד 30% מהפרויקטים נתקלים באי-תאימות דרייברים — אנו בודקים ומתקנים זאת בשלב הבדיקה.

לפי תיעוד MongoDB, "שדרוג על פני מספר גרסאות ראשיות בשלב אחד אינו נתמך."

תכונה ספציפית זו מרבה להפתיע צוותים שלא עדכנו שנים: הם מגלים שהשרת שלהם על 4.0 (גרסה שסוף החיים שלה הגיע), רוצים לקפוץ ל-7.0 — ומקבלים חמישה שלבים במקום אחד. הניסיון שלנו מראה שתכנון נכון ו-runbook מקצרים את לוחות הזמנים ב-30%. צור קשר — נעזור לתכנן שדרוג גם בתשתית legacy מורכבת. החיסכון בעלויות מהימנעות מהשבתה יכול לעלות משמעותית על ההשקעה בשדרוג.

כיצד לבצע שדרוג מתגלגל של Replica Set ללא השבתה?

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

רצף עבור PSS (Primary + 2 Secondaries):

1. שדרג את ה-Secondary הראשון: עצור את mongod, החלף את החבילה, הפעל. המתן עד שהצומת חוזר ל-SECONDARY ומשלים את פער השכפול.
2. שדרג את ה-Secondary השני באופן דומה.
3. הורד את ה-Primary: rs.stepDown(60) — ה-Primary הנוכחי הופך ל-Secondary.
4. שדרג את ה-Primary לשעבר (כיום Secondary).
5. ודא שכל שלושת הצמתים ב-Replica Set פועלים כראוי.
6. בצע db.adminCommand({ setFeatureCompatibilityVersion: "5.0" }).

רק לאחר שלב 6 ה-Replica Set מתחיל להשתמש בתכונות הגרסה החדשה. עד אז, הוא פועל במצב תאימות. זה מאפשר לחזור לגרסה הקודמת אם משהו משתבש (לפני שינוי FCV, rollback אפשרי).

// Проверка текущего FCV перед обновлением
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
// Ожидаемый ответ: { featureCompatibilityVersion: { version: "4.4" } }

בדיקות קריטיות לפני השדרוג

אזהרות deprecation ביומנים. MongoDB מתעד אזהרות על תכונות מיושנות הרבה מראש. בגרסה 4.4, אזהרות מצביעות על מה שיוסר ב-5.0. סקור את היומנים של // Проверка текущего FCV перед обновлением db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) // Ожидаемый ответ: { featureCompatibilityVersion: { version: "4.4" } } מהימים האחרונים:

grep -i "deprecat\|WARN" /var/log/mongodb/mongod.log | grep -v "^#" | sort -u 

תאימות דרייברים. MongoDB Server 6.0 דורש גרסת תאימות דרייבר 4.0 ומעלה. דרייברים ישנים יותר עשויים לעבוד אך ללא תכונות חדשות. mongod וגרסאות ישנות יותר של grep -i "deprecat\|WARN" /var/log/mongodb/mongod.log | grep -v "^#" | sort -u עשויים שלא לעבוד כראוי עם שרתים חדשים. בדוק את כל האפליקציות.

אינדקסים עם סוגים מיושנים. ב-MongoDB 4.4, אינדקסים מסוג pymongo < 3.12 הוצאו משימוש; ב-5.0 הם הוסרו. אם קיימים אינדקסים כאלה, mongod 5.0 יסרב להתחיל.

// Поиск устаревших типов индексов
db.getCollectionNames().forEach(name => {
    db[name].getIndexes().forEach(idx => {
        if (idx.key.hasOwnProperty("$**") || idx.type === "hashed") {
            print(name + ": " + JSON.stringify(idx))
        }
    })
})

מה הופך שדרוגי Sharded Cluster למורכבים יותר?

עבור cluster מפוצל (sharded), סדר השדרוג מוגדר בקפדנות:

1. שדרג את שרתי ה-Config (CSRS)
2. שדרג את נתבי mongos
3. שדרג את ה-shards (כל אחד מתגלגל)
4. שנה FCV לגרסה החדשה

סטייה מסדר זה עלולה לגרום לאי-תאימות גרסאות בין רכיבים. זמנית, רכיבים בגרסאות שונות (n ו-n-1) יכולים לעבוד יחד, אך לא יותר מתקופת השדרוג.

בדיקות לפני ייצור

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

לאחר השדרוג בסביבת הבדיקה: הרץ עומסי עבודה אופייניים, בדוק aggregation pipelines, וודא ש-mongo-go-driver מציג תוכניות שאילתה צפויות.

מתי Rollback אפשרי וכיצד לבצע אותו?

Rollback אפשרי רק אם ה-FCV לא שונה. לאחר geoHaystack לגרסה החדשה, חזרה לגרסה הקודמת בלתי אפשרית ללא שחזור מגיבוי.

לכן: צלם snapshot לפני כל שלב שדרוג, ובצע // Поиск устаревших типов индексов db.getCollectionNames().forEach(name => { db[name].getIndexes().forEach(idx => { if (idx.key.hasOwnProperty("$**") || idx.type === "hashed") { print(name + ": " + JSON.stringify(idx)) } }) }) אחרון, לאחר אימות הפונקציונליות.

כיצד להתכונן לשדרוג? השוואת גישות

שדרוג מתגלגל על Replica Set אמין פי 3 משדרוג עצמאי פשוט מכיוון שהוא מאפשר rollback בכל שלב.

מה כלול בעבודה שלנו?

• בדיקת גרסה נוכחית ובניית מפת שדרוג
• בדיקת אזהרות deprecation ותאימות דרייברים
• פיתוח runbook לכל שלב עם תוכנית rollback
• פריסת סביבת staging עם נתוני ייצור ובדיקות
• שדרוג מתגלגל בייצור עם ניטור בזמן אמת
• אימות פונקציונלי ושינוי FCV
• תיעוד והדרכת צוות

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

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