MongoDB: النسخ الاحتياطي والاستعادة، والأمن، والعمليات

آخر تحديث: 2026-08-26

تعد العمليات عنصراً أساسياً في عمليات نشر MongoDB في بيئة الإنتاج — حيث إن إتقان إجراءات النسخ الاحتياطي والأمن والمراقبة يمكن أن يمنع 90% من الحوادث التي تحدث في بيئة الإنتاج.

1. ما ستتعلمه


100%
graph TB
    subgraph "Backup Strategy"
        A1[Daily Full Backup<br/>mongodump] --> S3[(S3/OSS<br/>Object Storage)]
        A2[oplog Continuous<br/>Incremental] --> S3
        A3[Atlas PITR<br/>Point-in-Time Recovery] --> S3
    end

    subgraph "Restore Scene"
        R1[Accidental Data Deletion] --> R2[mongorestore]
        R3[Entire database lost] --> R2
        R4[A specific point in time] --> R5[oplogReplay]
        R2 --> R6[✅ Data Recovery]
        R5 --> R6
    end

    style R6 fill:#d4edda

2. النسخ الاحتياطي المنطقي باستخدام mongodump

شرح المفهوم: mongodump هي أداة النسخ الاحتياطي المنطقي الرسمية لـ MongoDB — فهي تقرأ بيانات المجموعات وتصدرها إلى ملفات BSON/JSON. يعمل النسخ الاحتياطي المنطقي على «تصدير البيانات» بدلاً من «نسخ الملفات»، مما يتيح استعادتها عبر الإصدارات والأنظمة الأساسية المختلفة، لكن عملية النسخ الاحتياطي لقواعد البيانات الكبيرة تكون بطيئة نسبيًا.

كيفية العمل: يتصل برنامج mongodump بقاعدة بيانات MongoDB، ويقرأ البيانات مجموعةً تلو الأخرى ووثيقةً تلو الأخرى، ويحولها إلى تنسيق BSON، ثم يكتبها على القرص. وهو يدعم ضغط gzip، والتصفية الشرطية، وتضمين سجل oplog (لغرض الاستعادة الكاملة بعد الفشل (PITR)). لا يتم قفل المجموعات أثناء عملية النسخ الاحتياطي (النسخ الاحتياطي السريع)، لكن نسخ المجموعات الكبيرة احتياطيًا قد يؤثر على الأداء.

النسخ الاحتياطي المنطقي مقابل النسخ الاحتياطي المادي:

البعد النسخ الاحتياطي المنطقي (mongodump) النسخ الاحتياطي المادي (نسخ الملفات)
التنفيذ قراءة البيانات → التسلسل → الكتابة إلى ملف نسخ ملف البيانات مباشرةً
السرعة بطيئة (تتطلب القراءة + التسلسل) سريعة (نسخ على مستوى الملف)
عبر الإصدارات ✅ مدعوم ❌ مرتبط بإصدار محدد من المحرك
الانتقائية ✅ حسب قاعدة البيانات/المجموعة/الشروط ❌ كاملة
الحجم صغير (مضغوط) كبير (الملف الأصلي)
الاتساق اتساق المجموعة الواحدة يتطلب أقفالًا أو لقطات لمجموعة النسخ المتماثلة
دقة الاستعادة مرنة (قاعدة البيانات/المجموعة/المستند) قاعدة البيانات بأكملها

مفاهيم RPO/RTO:

المفهوم المعنى مثال
RPO (هدف نقطة الاستعادة) الحد الأقصى المقبول لفقدان البيانات RPO=1h = فقدان البيانات لمدة تصل إلى ساعة واحدة
RTO (الهدف الزمني للاستعادة) أقصى وقت مقبول للاستعادة RTO=4 ساعات = يجب استعادة الخدمة في غضون 4 ساعات
BASH
# === Back up the entire database ===
mongodump --uri="mongodb://localhost:27017/shopdb" --out=/backup/2026-07-01

# === Back Up a Specified Set ===
mongodump --uri="mongodb://localhost:27017/shopdb" --collection=users --out=/backup/users

# === Compressed Backup ===
mongodump --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz

# === Back up metadata only ===
mongodump --uri="mongodb://localhost:27017" --db=shopdb --collection=users --query='{"role":"admin"}'

المعلمات الرئيسية لـ mongodump:

المعلمة الوصف مثال
--uri سلسلة الاتصال mongodb://user:pass@host:port/db
--out دليل الإخراج /backup/2026-07-01
--gzip ضغط gzip يقلل حجم الملف بنسبة 60–80%
--archive أرشيف ملف واحد --archive=backup.gz
--oplog يتضمن سجل التشغيل (يتطلب PITR) --oplog
--collection مجموعة محددة --collection=users
--query مرشح الحالة --query='{"role":"admin"}'


3. استعادة البيانات باستخدام mongorestore

نظرة عامة على المفهوم: يُعد mongorestore النظير لـ mongodump — فهو يستورد ملفات النسخ الاحتياطي بتنسيق BSON/JSON إلى MongoDB. وهو يدعم الاستعادة الكاملة، والاستعادة الانتقائية، والاستعادة إلى نقطة زمنية محددة (PITR)، بالإضافة إلى أوضاع أخرى.

كيفية العمل: يقوم mongorestore بالقراءة من دليل النسخ الاحتياطي أو ملف الأرشيف وإدراج المستندات مجموعة واحدة في كل مرة. أما الخيار --drop فيقوم أولاً بحذف المجموعات الموجودة ثم استعادتها (وضع الكتابة فوق). وعند استخدامه بالاقتران مع --oplogReplay، فإنه يعيد تشغيل سجل العمليات (oplog) لإجراء استعادة إلى نقطة زمنية محددة.

مقارنة بين أوضاع الاسترداد:

الوضع خيارات الأوامر حالات الاستخدام
استعادة كاملة mongorestore /backup/db استعادة قاعدة البيانات بأكملها إلى حالة النسخة الاحتياطية في ذلك الوقت
الكتابة فوق والاستعادة --drop الاستعادة بعد المسح (بيئة الاختبار)
الاسترداد الانتقائي --nsInclude استرداد مجموعات محددة فقط
استعادة PITR --oplogReplay الاستعادة إلى نقطة زمنية محددة
الاستعادة من أرشيف مضغوط --gzip --archive=file.gz الاستعادة من أرشيف مضغوط
BASH
# === Restore the entire backup ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01

# === Restore a Specified Database ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01/shopdb

# === Restore gzip Compressed Backup ===
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz

# === Restore and overwrite existing data ===
mongorestore --uri="mongodb://localhost:27017" --drop /backup/2026-07-01

تحليل النقاط الرئيسية:

  1. --drop سيؤدي هذا أولاً إلى حذف المجموعة ثم استعادتها؛ لذا يجب توخي الحذر عند استخدامه في بيئات الإنتاج (قد تُفقد البيانات الجديدة التي تمت إضافتها بعد النسخ الاحتياطي).
  2. يؤدي إدخال البيانات في mongorestore إلى إعادة بناء الفهرس، مما يؤدي إلى إبطاء عملية استعادة المجموعات الكبيرة.
  3. عند الاستعادة إلى قاعدة بيانات موجودة، سيؤدي تعارض _id إلى تخطي المستندات المكررة؛ استخدم --drop لتجنب هذا التعارض.


4. استراتيجية النسخ الاحتياطي

شرح المفهوم: تُعد استراتيجيات النسخ الاحتياطي جوهر عمليات التشغيل والصيانة — فهي تحدد RPO (الحد الأقصى لفقدان البيانات) وRTO (الحد الأقصى لوقت الاستعادة). وتتطلب السيناريوهات التجارية المختلفة تواترًا مختلفًا للنسخ الاحتياطي، وسياسات احتفاظ مختلفة، وخطط استعادة مختلفة.

مقارنة بين استراتيجيات النسخ الاحتياطي:

الاستراتيجية التكرار الاحتفاظ RPO RTO قابلية التطبيق التكلفة
نسخ احتياطي يومي كامل في الصباح الباكر كل يوم 7–30 يومًا 24 ساعة عدة ساعات قواعد بيانات صغيرة منخفض
التزايد في الساعة في الساعة 24–48 ساعة ساعة واحدة عدة ساعات قاعدة بيانات متوسطة الحجم متوسطة
استمرارية سجلات oplog في الوقت الفعلي 7 أيام < 1 ثانية على مستوى الدقيقة قواعد البيانات الكبيرة عالية
Atlas PITR تلقائي 35 يومًا ثوانٍ دقائق خدمة Atlas Cloud الدفع حسب الاستخدام
لقطات الملفات عند الطلب 7–30 يومًا تواتر اللقطات كل دقيقة دعم LVM/EBS منخفض

عملية اختيار استراتيجية النسخ الاحتياطي:

100%
graph TB
    A{Business Type?} -->|Non-critical<br/>Log/Cache| B[Daily Total<br/>RPO=24h]
    A -->|General Business<br/>User/Order| C{Data volume?}
    A -->|Core Business<br/>Finance/Payment| D[oplogContinuous<br/>RPO<1s]
    C -->|< 100GB| E[Daily Total+<br/>oplog PITR]
    C -->|> 100GB| F[File Snapshot+<br/>oplogContinuous]

    style D fill:#d4edda
    style B fill:#fff3cd

مبدأ PITR (الاستعادة إلى نقطة زمنية محددة): أولاً، يتم استعادة النسخة الاحتياطية الكاملة، ثم إعادة تشغيل إدخالات سجل العمليات (oplog) بدءًا من وقت النسخ الاحتياطي وحتى النقطة الزمنية المستهدفة، وبذلك يتم تحقيق استعادة إلى نقطة زمنية محددة بدقة تصل إلى الثانية.

100%
sequenceDiagram
    participant Full as Full Backup
    participant Oplog as oplog Incremental
    participant Target as Target Date

    Note over Full: Backup Time T0
    Full->>Oplog: RestoreT0Full Data Set

    Note over Oplog: T0 → T1 betweenoplog

    loop Replayoplog
        Oplog->>Target: Replay write operations one by one
    end

    Note over Target: Restore to a Specific Point in Time T1
الاستراتيجية التكرار الاحتفاظ قابلية التطبيق
نسخ احتياطي كامل يومي كل صباح 7–30 يومًا قواعد البيانات الصغيرة
الزيادة لكل ساعة لكل ساعة 24–48 ساعة قاعدة بيانات متوسطة الحجم
استمرارية سجل العمليات (Oplog) في الوقت الفعلي 7 أيام قواعد البيانات الكبيرة (بناءً على سجل العمليات لمجموعة النسخ المتماثلة)
Atlas PITR تلقائي 35 يومًا خدمة Atlas Cloud

▶ المثال 1: تجربة عملية لاستعادة البيانات في وقت محدد (PITR)

BASH
# ShopHub Accidentally deleted 2026-07-01 10:00-10:30 Order Data,Need to revert to 10:00 Status

# 1. Restore the full backup from the previous day
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --drop /backup/2026-06-30/shopdb

# 2. Replay oplog By the target date
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --oplogReplay --oplogLimit=1750604400 /backup/2026-06-30/oplog.bson

# 3. Verify the restored data
mongosh --port 27017 shopdb_recovery --eval 'db.orders.count()'

# 4. Export the recovered data and import it into the production environment
mongodump --uri="mongodb://localhost:27017/shopdb_recovery" --collection=orders --query='{"createdAt":{"$gte":{"$date":"2026-07-01T10:00:00Z"},"$lt":{"$date":"2026-07-01T10:30:00Z"}}}' --out=/recovery/orders
mongorestore --uri="mongodb://localhost:27017/shopdb" /recovery/orders

الإخراج:

TEXT 📖 للعرض فقط
2026-07-01T10:00:00Z - Orders recovered: 156
Restore completed successfully


5. المستخدمون والمصادقة

نظرة عامة على المفهوم: يُعد الأمن خط الدفاع الأول لـ MongoDB في عمليات النشر في بيئات الإنتاج. وتُعد آلية SCRAM (آلية المصادقة القائمة على التحدي والاستجابة المُملحة) آلية المصادقة الافتراضية لـ MongoDB، في حين يتحكم نظام RBAC (التحكم في الوصول القائم على الأدوار) في الأذونات بناءً على الأدوار. ويُعد مبدأ «أقل الامتيازات» عنصراً أساسياً في الأمن — حيث يُمنح كل مستخدم الحد الأدنى من الامتيازات اللازمة لأداء مهامه فقط.

كيفية عمل مصادقة SCRAM: يرسل العميل اسم المستخدم، فيرد الخادم بـ«سولت» عشوائي وعدد التكرارات. يقوم العميل بإجراء عدة عمليات تجزئة باستخدام كلمة المرور و«السولت» لتوليد دليل، ثم يتحقق الخادم مما إذا كان الدليل يطابق التجزئة المخزنة. ولا يتم أبدًا إرسال كلمة المرور بنص عادي عبر الشبكة.

100%
sequenceDiagram
    participant C as Client
    participant S as MongoDBServer

    C->>S: 1. Username
    S-->>C: 2. salt + iterationCount + storedKey
    C->>C: 3. password + salt → PBKDF2 → clientKey → storedKey
    C->>S: 4. clientProof(Digital Signature)
    S->>S: 5. Verification clientProof
    S-->>C: 6. Authentication Successful ✅ / Failure ❌

    Note over C,S: Passwords are never transmitted over the network

نموذج أذونات RBAC:

المستوى الوصف
المستخدم كيان تمت مصادقته ويشغل دورًا واحدًا أو أكثر
الدور مجموعة من الصلاحيات التي يمكن أن ترثها أدوار أخرى
الامتياز مزيج من الموارد والإجراءات
المورد مستوى قاعدة البيانات/المجموعة/المجموعة المجمعة

(1) شهادة SCRAM

JAVASCRIPT
// === Create an Administrator User ===
db.createUser({
  user: 'admin',
  pwd: 'SecurePass123!',
  roles: [
    { role: 'userAdminAnyDatabase', db: 'admin' },
    { role: 'readWriteAnyDatabase', db: 'admin' }
  ]
});

// === Create an Application User ===
db.createUser({
  user: 'app_user',
  pwd: 'AppPass456!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// === Enable Authentication(mongod Startup Parameters)===
mongod --auth --bind_ip_all

(2) أدوار RBAC

الدور المدمج الأذونات المستخدمون المعنيون
read قراءة جميع المجموعات محلل
readWrite قراءة وكتابة جميع المجموعات التطبيق
dbAdmin إدارة قواعد البيانات DBA
userAdmin إدارة المستخدمين مسؤول قواعد البيانات
dbOwner جميع الأذونات المذكورة أعلاه المسؤول
readAnyDatabase قراءة جميع قواعد البيانات محلل متعدد قواعد البيانات
readWriteAnyDatabase القراءة والكتابة في جميع قواعد البيانات التطبيقات التي تعمل عبر قواعد البيانات
userAdminAnyDatabase إدارة جميع مستخدمي قاعدة البيانات Super DBA
dbAdminAnyDatabase إدارة جميع قواعد البيانات Super DBA
backup أذونات النسخ الاحتياطي نصوص النسخ الاحتياطي
restore استعادة الأذونات استعادة البرنامج النصي
root مستخدم متميز صيانة طارئة

مبدأ الحد الأدنى من الصلاحيات:

المستخدم الدور الموصى به الوصف
مستخدم التطبيق readWrite (قاعدة بيانات واحدة) حق الوصول للقراءة/الكتابة إلى قاعدة بيانات الأعمال فقط
مستخدم النسخ الاحتياطي backup + readAnyDatabase الحد الأدنى من الصلاحيات المطلوبة لإجراء النسخ الاحتياطي
تحليل المستخدم read (قاعدة بيانات واحدة) أذونات القراءة فقط
DBA userAdmin + dbAdmin امتيازات إدارية، وليس مستخدمًا متميزًا
JAVASCRIPT
// === Custom Characters ===
db.createRole({
  role: 'orderManager',
  privileges: [
    { resource: { db: 'shopdb', collection: 'orders' }, actions: ['find', 'insert', 'update'] },
    { resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
  ],
  roles: []
});

// === Authorization ===
db.grantRolesToUser('app_user', [{ role: 'orderManager', db: 'shopdb' }]);

▶ المثال 2: تكوين نموذج RBAC القائم على مبدأ «أدنى امتياز»

JAVASCRIPT
// TechCorp:Assign the minimum necessary permissions to different teams
// 1. Application Service Account(Read-write only shopdb)
db.createUser({
  user: 'app_service',
  pwd: 'AppSecurePass!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// 2. Backup Service Account(Backup-only permissions)
db.createUser({
  user: 'backup_service',
  pwd: 'BackupSecurePass!',
  roles: [
    { role: 'backup', db: 'admin' },
    { role: 'readAnyDatabase', db: 'admin' }
  ]
});

// 3. Data Analytics Team(Read-only + Specific Set)
db.createRole({
  role: 'analyticsReader',
  privileges: [
    { resource: { db: 'shopdb', collection: 'orders' }, actions: ['find'] },
    { resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
  ],
  roles: []
});
db.createUser({
  user: 'analyst',
  pwd: 'AnalystPass!',
  roles: [{ role: 'analyticsReader', db: 'shopdb' }]
});

// 4. Verify Permissions
db.auth('analyst', 'AnalystPass!');
db.orders.find({}); // ✅ Can be read
db.orders.insertOne({}); // ❌ Insufficient permissions

الإخراج:

TEXT 📖 للعرض فقط
{ ok: 1 }
Error: not authorized on shopdb to execute command

  1. تشفير TLS/SSL

شرح المفهوم: يعمل تشفير TLS/SSL على تأمين الاتصالات الشبكية لـ MongoDB — مما يمنع هجمات «الرجل في الوسط» والتجسس على البيانات والتلاعب بها. يجب تمكين TLS في بيئات الإنتاج، خاصةً في حالة الاتصالات عبر مراكز البيانات أو عبر السحابة.

كيفية العمل: يقوم بروتوكول TLS بالتحقق من هوية الخادم باستخدام الشهادات وإقامة اتصال مشفر. يدعم MongoDB المصادقة باستخدام شهادات X.509 (كبديل لـ SCRAM)، كما أن بروتوكول TLS المتبادل (mTLS) يتحقق من هويات كل من العميل والخادم.

مستويات التشفير:

المستوى طريقة التشفير نطاق الحماية
طبقة النقل TLS/SSL الاتصالات الشبكية (العميل ↔ الخادم، بين العقد)
طبقة التخزين تشفير WiredTiger ملفات البيانات (التشفير الثابت)
مستوى الحقل التشفير على مستوى التطبيق الحقول الحساسة (مثل: كلمات المرور، أرقام الهوية)
BASH
# === Start mongod with SSL ===
mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem

# === Client Connection ===
mongosh "mongodb://localhost:27017/shopdb?ssl=true&sslCertificateKeyFile=/etc/ssl/client.pem"

معلمات تكوين TLS:

المعلمة الوصف القيمة الموصى بها
--tlsMode وضع TLS requireTLS (الإنتاج)
--tlsCertificateKeyFile شهادة الخادم + المفتاح الخاص تنسيق PEM
--tlsCAFile شهادة CA تُستخدم للتحقق من شهادات العملاء
--tlsAllowInvalidCertificates السماح بالشهادات غير الصالحة ❌ معطل في بيئة الإنتاج

تحليل النقاط الرئيسية:

  1. يمكن للمجموعات المُستضافة ذاتيًا استخدام شهادات موقعة ذاتيًا؛ ويتم تمكين بروتوكول TLS افتراضيًّا في Atlas.
  2. يتيح بروتوكول mTLS (Mutual TLS) المصادقة القائمة على الشهادات كبديل للمصادقة القائمة على كلمة المرور.
  3. يزيد بروتوكول TLS من زمن انتقال الاتصال بنسبة تتراوح بين 5 و10٪ تقريبًا، لكنه ضروري لضمان أمن البيانات.


6. العمليات والرصد

شرح المفهوم: تعمل مراقبة العمليات بمثابة «لوحة معلومات الحالة» لنظم MongoDB قيد التشغيل — وذلك باستخدام أدوات مثل serverStatus وdbStats وتحليل الاستعلامات البطيئة لمراقبة حالة قاعدة البيانات في الوقت الفعلي، والكشف عن المشكلات ومنعها على الفور.

نظام المراقبة:

مستوى المراقبة الأداة المقاييس الرئيسية
مستوى المثيل serverStatus() عدد الاتصالات، عدد العمليات، الذاكرة
مستوى قاعدة البيانات db.stats() حجم البيانات، عدد الفهارس، عدد المجموعات
مستوى المجموعة collStats() عدد الوثائق، الحجم، كفاءة الفهرسة
مستوى الاستعلام أداة تحليل الأداء / Explain الاستعلامات البطيئة، خطط التنفيذ
مستوى المؤشر $indexStats استخدام المؤشر

(1) حالة الخادم

المؤشرات الرئيسية:

وحدة القياس الوصف النطاق الصحي عتبة التنبيه
connections.current العدد الحالي للاتصالات < 1000 > 8000
connections.available عدد الاتصالات المتاحة > 50,000 < 1,000
opcounters.query عدد الاستعلامات في الثانية المستوى الأساسي ارتفاع بمقدار 10 أضعاف
opcounters.insert عدد العمليات في الثانية القيمة الأساسية زيادة بمقدار 10 أضعاف
mem.resident الذاكرة المستخدمة (ميجابايت) أقل من 80% من إجمالي الذاكرة أكثر من 95% من إجمالي الذاكرة
uptime مدة التشغيل (بالثواني) > 86,400 < 3,600 (إعادة تشغيل متكررة)
JAVASCRIPT
db.serverStatus();
// {
//   host: 'mongo1',
//   version: '7.0.5',
//   process: 'mongod',
//   uptime: 864000,
//   connections: { current: 150, available: 83860 },
//   opcounters: {
//     insert: 1234567,
//     query: 9876543,
//     update: 234567,
//     delete: 12345
//   },
//   mem: { resident: 1024, virtual: 4096 },
//   ...
// }

(2) إحصائيات قاعدة البيانات

JAVASCRIPT
db.stats();
// {
//   db: 'shopdb',
//   collections: 10,
//   objects: 1000000,
//   dataSize: 524288000,
//   storageSize: 268435456,
//   indexes: 20,
//   indexSize: 52428800
// }

(3) تحليل الاستعلامات البطيئة

شرح المفهوم: تُعد الاستعلامات البطيئة المؤشر الرئيسي لمشكلات الأداء في MongoDB. وتتضمن العملية القياسية لتحسين الأداء استخدام أداة Profiler لتسجيل الاستعلامات التي تتجاوز عتبة معينة، ثم تحليل خطط تنفيذها واستخدام الفهارس فيها.

مستوى تحديد الخصائص الوصف التأثير على الأداء
0 إغلاق لا شيء
1 الاستعلامات البطيئة فقط منخفض جدًا
2 تسجيل جميع العمليات متوسط (لأغراض التصحيح فقط)
JAVASCRIPT
// === Enable the slow query log(>100ms)===
db.setProfilingLevel(2, { slowms: 100 });

// === View Slow Queries ===
db.system.profile.find({ millis: { $gt: 100 } })
  .sort({ ts: -1 })
  .limit(10);

(4) إحصائيات استخدام الفهرس

JAVASCRIPT
db.products.aggregate([{ $indexStats: {} }]);
// Identify unused indexes

توصيات بشأن مراقبة إعدادات التنبيهات:

عنصر التنبيه الحد طريقة الإخطار
عدد الاتصالات > 80% من الحد الأقصى عدد الاتصالات الحالية > 64,000 البريد الإلكتروني + الرسائل القصيرة
الاستعلامات البطيئة > 10 في الدقيقة تستغرق 5 دقائق Slack
الذاكرة > 90% الذاكرة المقيمة > 90% من إجمالي الذاكرة البريد الإلكتروني
القرص > 85% حجم التخزين > 85% من سعة القرص البريد الإلكتروني + الرسائل النصية
تأخير النسخ > 10 ثوانٍ انحراف تاريخ «optimeDate» البريد الإلكتروني


7. الأوامر الشائعة للتشغيل والصيانة

نظرة عامة على المفهوم: تشمل العمليات اليومية والصيانة إدارة العمليات الجارية، والمعاملات طويلة الأمد، وصيانة الفهارس، وضغط المجموعات، وغيرها من المسائل. يوفر MongoDB مجموعة من الأوامر التشغيلية لمساعدة مسؤولي قواعد البيانات (DBAs) على تشخيص مشكلات بيئة الإنتاج وحلها بسرعة.

دليل مرجعي سريع لأوامر التشغيل والصيانة:

السيناريو الأمر الوصف
عرض العمليات الحالية db.currentOp() البحث عن الاستعلامات الطويلة/حالات التعطل
عملية الإيقاف db.killOp(opId) إنهاء العملية التي تسبب المشكلة
مجموعة «Compress» db.runCommand({compact:'col'}) استعادة المساحات المجزأة
إعادة إنشاء الفهرس db.col.reIndex() إصلاح تجزئة الفهرس
عرض الاتصالات db.serverStatus().connections عدد الاتصالات
سجلات المحولات db.adminCommand({logRotate:1}) تدوير السجلات
المزامنة القسرية rs.syncFrom('host:port') تحديد مصدر المزامنة
JAVASCRIPT
// === Current Operation ===
db.currentOp({ "op": "query" });

// === Kill a process ===
db.killOp(opId);

// === Compressed Sets ===
db.runCommand({ compact: 'products' });

// === Rebuild Index ===
db.products.reIndex();

// === View Link ===
db.serverStatus().connections;

إرشادات التشغيل والصيانة:

العملية نوع القفل خطر الانسداد التوصية
compact قفل حصري عالي التنفيذ خلال فترة الصيانة
reIndex قفل حصري عالي التنفيذ خلال فترة الصيانة
killOp غير مقفل لا شيء يمكن تنفيذه في أي وقت
currentOp غير مقفل لا شيء يمكن تنفيذه في أي وقت
logRotate غير مقفل لا شيء يمكن تنفيذه في أي وقت

إجراءات استكشاف الأعطال وإصلاحها في حالات الطوارئ:

  1. db.currentOp() تم العثور على عملية طويلة
  2. db.killOp(opId) إيقاف العملية التي تسبب المشكلة
  3. db.serverStatus().connections التحقق من عدد الاتصالات
  4. إذا وصل عدد الاتصالات إلى السعة القصوى، ففكر في تقليل حجم مجموعة اتصالات التطبيق مؤقتًا.
  5. استخدم أداة Profiler لتحليل السبب الجذري بعد ذلك، ثم قم بإضافة فهارس أو تحسين الاستعلامات

▶ مثال: سياسة النسخ الاحتياطي الكاملة + تكوين أمان RBAC

BASH
# === 1. Daily Automatic Backup Script(backup-daily.sh)===
#!/bin/bash
set -e

DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/mongodb/$DATE
RETENTION_DAYS=7

# 1.1 Full Backup(gzip Compression)
mongodump   --uri="mongodb://backup_user:SecurePass@mongo1:27017,mongo2:27017,mongo3:27017/shopdb?replicaSet=rs0"   --gzip   --archive=$BACKUP_DIR.gz   --oplog  # Includes oplog,Support PITR

# 1.2 Upload to S3
aws s3 cp $BACKUP_DIR.gz s3://my-bucket/mongodb-backups/$DATE/

# 1.3 Cleanup 7 Local backup from X days ago
find /backup/mongodb/ -name "*.gz" -mtime +$RETENTION_DAYS -delete

# 1.4 Record Backup Logs
echo "[$(date)] Backup completed: $BACKUP_DIR.gz ($(du -h $BACKUP_DIR.gz | cut -f1))" >> /var/log/mongodb-backup.log

# 1.5 Add to crontab (Daily at 2 AM)
# 0 2 * * * /usr/local/bin/backup-daily.sh

# === 2. Recovery Drill ===
# 2.1 View Available Backups
ls -lh /backup/mongodb/

# 2.2 Restore to the test environment
mongorestore   --uri="mongodb://localhost:27017/shopdb_test"   --gzip   --archive=/backup/mongodb/20260701.gz   --drop  # Overwrite existing data

# 2.3 PITR Restore to a Specific Point in Time
mongorestore   --uri="mongodb://localhost:27017"   --gzip   --archive=/backup/mongodb/20260701.gz   --oplogReplay   --pointInTime=2026-07-01T10:30:00
JAVASCRIPT
// === 3. Enable Authentication + Create RBAC User ===
// 3.1 Create an Administrator User(The first must)
db.createUser({
  user: 'root',
  pwd: 'RootSecurePass!',
  roles: [{ role: 'root', db: 'admin' }]
});

// 3.2 Create a User Dedicated to Backups(Least Privilege)
db.createUser({
  user: 'backup_user',
  pwd: 'BackupPass!',
  roles: [
    { role: 'backup', db: 'admin' },
    { role: 'readAnyDatabase', db: 'admin' }
  ]
});

// 3.3 Create an Application User(Reading and Writing shopdb)
db.createUser({
  user: 'app_user',
  pwd: 'AppPass!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// 3.4 Create a read-only analysis user
db.createUser({
  user: 'analytics_user',
  pwd: 'AnalyticsPass!',
  roles: [{ role: 'read', db: 'shopdb' }]
});

// 3.5 Enable TLS/SSL(mongod Startup Parameters)
// mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem --auth

// === 4. Monitoring Alerts ===
// Enable the slow query log
db.setProfilingLevel(2, { slowms: 100 });

// View Slow Queries Top 10
db.system.profile.find({ millis: { $gt: 100 } })
  .sort({ ts: -1 })
  .limit(10)
  .forEach(p => print(`[${p.ts}] ${p.command.find}: ${p.millis}ms`));

// Monitor Connection Count
const stats = db.serverStatus();
print(`Active connections: ${stats.connections.current}/${stats.connections.available}`);
// Alert Thresholds:current > 1000 → Email Alerts

// === 5. Automated Inspection Script ===
function dailyHealthCheck() {
  print('=== MongoDB Daily Health Check ===');

  // 5.1 Dungeon Collection Status
  const rsStatus = rs.status();
  const primary = rsStatus.members.find(m => m.stateStr === 'PRIMARY');
  print(`Primary: ${primary.name}`);

  // 5.2 oplog Window(Avoid Overwriting)
  const oplogWindow = primary.optimeDate ? (Date.now() - primary.optimeDate.getTime()) / 1000 : 0;
  print(`Oplog window: ${Math.floor(oplogWindow / 3600)} hours`);
  if (oplogWindow > 24 * 3600) print('⚠️  WARNING: oplog window > 24h');

  // 5.3 Index Usage Rate
  const indexes = db.products.aggregate([{ $indexStats: {} }]).toArray();
  const unused = indexes.filter(i => i.accesses.ops === 0);
  print(`Unused indexes: ${unused.length}`);
  if (unused.length > 0) {
    unused.forEach(i => print(`  - ${i.name}`));
  }
}

dailyHealthCheck();

الإخراج:

TEXT 📖 للعرض فقط
=== MongoDB Daily Health Check ===
Primary: mongo1:27017
Oplog window: 72 hours
Unused indexes: 2
  - old_index_1
  - deprecated_index


❓ أسئلة شائعة

س هل يعتبر mongodump نسخة احتياطية سريعة؟
ج نعم، لا يتطلب mongodump توقف الخدمة. ومع ذلك، قد يؤثر إجراء النسخ الاحتياطي للمجموعات الكبيرة على الأداء، لذا يُنصح بتشغيله خلال ساعات الذروة.
س هل يؤثر نظام RBAC على الأداء؟
ج لا يوجد أي تأثير عمليًا. يقوم نظام RBAC بالتحقق من الأذونات في الذاكرة.
س كيف تتم مراقبة بيئة الإنتاج؟
ج استخدم MongoDB Atlas (الذي يتضمن ميزات مراقبة مدمجة) أو Prometheus + mongo_exporter (المستضاف ذاتيًا).

📖 ملخص


📝 تمارين

  1. تمرين أساسي (⭐): قم بعمل نسخة احتياطية لقاعدة البيانات shopdb باستخدام mongodump، ثم قم باستعادتها باستخدام mongorestore.
  2. تمرين أساسي (⭐): قم بإنشاء المستخدمين «admin» و«app_user» ومنحهما الأذونات.
  3. تمرين متقدم (⭐⭐): قم بتنفيذ برنامج نصي للنسخ الاحتياطي اليومي (cron + mongodump + ضغط + حذف البيانات التي يزيد عمرها عن 7 أيام).
  4. تمرين متقدم (⭐⭐): قم بتمكين تحليل الاستعلامات البطيئة وحدد أهم 10 استعلامات بطيئة.
  5. التحدي (⭐⭐⭐): إكمال خطة التشغيل والصيانة (نص برمجي للنسخ الاحتياطي + أذونات المستخدمين + TLS + المراقبة والتنبيهات).
Web-Tutorial.com

فريق Web-Tutorial التقني

منصة دروس برمجية يديرها عدة مطورين. كل درس يتم كتابته ومراجعته بواسطة مطورين متخصصين في المجال. نعمل على ضمان دقة وموثوقية المحتوى — إذا لاحظت أي مشكلة، فيرجى إخبارنا.

100%