הגדרת שרת תצורה של MongoDB עבור אשכולות מפוצלים

הגדרת שרת תצורה של MongoDB עבור אשכולות Sharded

תארו לעצמכם: אשכול ה-sharded שלכם של MongoDB מטפל ב-50,000 שאילתות בשנייה, אבל לפתע מופעי mongos חדשים מפסיקים להתחבר, כתיבות מתחילות להיכשל — שרת התצורה הפך לבלתי זמין. ללא CSRS מוגדר כראוי, אתם מסתכנים באובדן יכולת איזון וכתיבה. אנו מגדירים את שרת התצורה עבור אשכולות sharded של MongoDB — קטלוג המטא-דאטה המרכזי. הוא מאחסן מידע על אילו נתחי נתונים נמצאים על אילו shards, הגדרות balancer, ואזורי sharding. ללא שרת תצורה נגיש, האשכול נכנס למצב קריאה בלבד: כתיבות נחסמות, חיבורים חדשים דרך mongos לא נוצרים. הניסיון שלנו עם למעלה מ-80 פרויקטי clustering מראה שהגדרת CSRS נכונה היא הבסיס ליציבות האשכול. מפתח shard שגוי או דיסק איטי עלולים לגרום לשהיות של עד 200 אלפיות השנייה לכל פעולה.

לפי תיעוד MongoDB, CSRS הוא חובה עבור אשכולות sharded: Config Servers.

מה זה CSRS ובמה הוא שונה מ-Replica Set רגיל?

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

ב-mongod.conf, הפרמטרים הבאים הם חובה עבור שרת תצורה:

---
sharding:
  clusterRole: configsvr
replication:
  replSetName: "configRS"
storage:
  dbPath: /var/lib/mongodb/config
net:
  port: 27019
  bindIp: cfg1.internal,127.0.0.1
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/configsvr.log
  logAppend: true

הפרמטר sharding: clusterRole: configsvr replication: replSetName: "configRS" storage: dbPath: /var/lib/mongodb/config net: port: 27019 bindIp: cfg1.internal,127.0.0.1 security: keyFile: /etc/mongodb/cluster-keyfile systemLog: destination: file path: /var/log/mongodb/configsvr.log logAppend: true חוסם פעולות כתיבת נתוני משתמש ישירות ומפעיל לוגיקה ספציפית לשרת תצורה.

כיצד להבטיח זמינות גבוהה של CSRS?

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

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

זמן השבתה של האשכול עקב אי-זמינות CSRS יכול לעלות $10,000 לשעה עבור פלטפורמת מסחר אלקטרוני גדולה. ללא גיבוי CSRS, שחזור יכול לקחת 8+ שעות, וכתוצאה מכך הפסד של $80,000 ב-$10,000 לשעה. הגדרת CSRS עמיד לתקלות מונעת הפסדים כאלה.

הגדרת CSRS שלב אחר שלב

1. ביקורת תשתית — בדיקת גישה לרשת, אזורי זמינות, דיסקים.
2. תכנון — בחירת שמות מארחים, פורטים, נתיבי נתונים.
3. הכנת קבצי תצורה — יצירת mongod.conf עם clusterRole: configsvr.
4. הפעלת mongod — על כל שלושת הצמתים.
5. אתחול Replica Set — התחברות לצומת הראשון והרצת rs.initiate עם configsvr: true.
6. אימות סטטוס — לוודא שכל הצמתים הם PRIMARY/SECONDARY.
7. אינטגרציה עם mongos — ציון CSRS בתצורת mongos באמצעות פרמטר configDB.
8. בדיקת failover — עצירה מלאכותית של ה-primary, אימות שהכתיבות נמשכות.
9. הגדרת ניטור וגיבויים.

אתחול CSRS:

rs.initiate({
  _id: "configRS",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1.internal:27019" },
    { _id: 1, host: "cfg2.internal:27019" },
    { _id: 2, host: "cfg3.internal:27019" }
  ]
})

---
sharding:
  clusterRole: configsvr
replication:
  replSetName: "configRS"
storage:
  dbPath: /var/lib/mongodb/config
net:
  port: 27019
  bindIp: cfg1.internal,127.0.0.1
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/configsvr.log
  logAppend: true

תחזוקה וגיבוי

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

לגיבוי אנו משתמשים ב-clusterRole: configsvr עם אפשרויות ספציפיות לשרת תצורה:

mongodump \
  --host configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019 \
  --db config \
  --out /backup/configsvr/$(date +%Y%m%d)

בסיס הנתונים rs.initiate({ _id: "configRS", configsvr: true, members: [ { _id: 0, host: "cfg1.internal:27019" }, { _id: 1, host: "cfg2.internal:27019" }, { _id: 2, host: "cfg3.internal:27019" } ] }) מכיל אוספים sharding: clusterRole: configsvr replication: replSetName: "configRS" storage: dbPath: /var/lib/mongodb/config net: port: 27019 bindIp: cfg1.internal,127.0.0.1 security: keyFile: /etc/mongodb/cluster-keyfile systemLog: destination: file path: /var/log/mongodb/configsvr.log logAppend: true , mongodump, mongodump \ --host configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019 \ --db config \ --out /backup/configsvr/$(date +%Y%m%d) , config, chunks — כל מה שדרוש לשחזור. עבור תחזוקה מתוכננת על צומת CSRS אחד, עליכם לעצור את ה-balancer של האשכול: collections.

בעיה נפוצה: Split Storm

במהלך הכנסה כבדה של מסמכים חדשים, שרת התצורה מקבל מספר גדול של פעולות כתיבה — אלה פיצולי chunks כאשר chunks חורגים מהגודל המקסימלי (ברירת מחדל 128 MB). באשכול עמוס עם מפתח shard גרוע, זה יכול ליצור מאות פיצולים לדקה.

אבחון: יומני databases מציגים shards עם זמן השהיה, וה-CSRS Primary מציג lock כתיבה גבוה. פתרון: הגדלת גודל chunk באמצעות settings או בחינה מחדש של מפתח ה-shard.

מה כלול בהגדרת CSRS Turnkey

• ביקורת תשתית קיימת ועיצוב ארכיטקטורת CSRS.
• פריסת שלושה צמתי CSRS תוך התחשבות באזורי זמינות.
• הגדרת קבצי תצורה, אתחול Replica Set.
• אינטגרציה עם mongos ו-shards.
• בדיקות failover וביצועים.
• הגדרת גיבוי וניטור (Prometheus + Grafana).
• תיעוד והדרכת צוות.

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

אנו עובדים עם MongoDB מאז 2014 והשלמנו למעלה מ-80 פרויקטי clustering. המהנדסים שלנו מחזיקים בהסמכות MongoDB Professional ויש להם ניסיון עם פלטפורמות ענן (AWS, GCP, Yandex Cloud). אנו מבטיחים ארכיטקטורה עמידה לתקלות ותיעוד מקיף.

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