MongoDB: النسخ الاحتياطي والاستعادة، والأمن، والعمليات
آخر تحديث: 2026-08-26
تعد العمليات عنصراً أساسياً في عمليات نشر MongoDB في بيئة الإنتاج — حيث إن إتقان إجراءات النسخ الاحتياطي والأمن والمراقبة يمكن أن يمنع 90% من الحوادث التي تحدث في بيئة الإنتاج.
1. ما ستتعلمه
- النسخ الاحتياطية المنطقية باستخدام mongodump و mongorestore
- مدير العمليات / سياسات النسخ الاحتياطي في Atlas
- شهادة SCRAM ونظام RBAC
- تشفير TLS/SSL
- مراقبة العمليات (حالة الخادم / إحصائيات قاعدة البيانات / الاستعلامات البطيئة)
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 ساعات |
# === 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 |
الاستعادة من أرشيف مضغوط |
# === 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
تحليل النقاط الرئيسية:
--dropسيؤدي هذا أولاً إلى حذف المجموعة ثم استعادتها؛ لذا يجب توخي الحذر عند استخدامه في بيئات الإنتاج (قد تُفقد البيانات الجديدة التي تمت إضافتها بعد النسخ الاحتياطي).- يؤدي إدخال البيانات في mongorestore إلى إعادة بناء الفهرس، مما يؤدي إلى إبطاء عملية استعادة المجموعات الكبيرة.
- عند الاستعادة إلى قاعدة بيانات موجودة، سيؤدي تعارض
_idإلى تخطي المستندات المكررة؛ استخدم--dropلتجنب هذا التعارض.
4. استراتيجية النسخ الاحتياطي
شرح المفهوم: تُعد استراتيجيات النسخ الاحتياطي جوهر عمليات التشغيل والصيانة — فهي تحدد RPO (الحد الأقصى لفقدان البيانات) وRTO (الحد الأقصى لوقت الاستعادة). وتتطلب السيناريوهات التجارية المختلفة تواترًا مختلفًا للنسخ الاحتياطي، وسياسات احتفاظ مختلفة، وخطط استعادة مختلفة.
مقارنة بين استراتيجيات النسخ الاحتياطي:
| الاستراتيجية | التكرار | الاحتفاظ | RPO | RTO | قابلية التطبيق | التكلفة |
|---|---|---|---|---|---|---|
| نسخ احتياطي يومي كامل | في الصباح الباكر كل يوم | 7–30 يومًا | 24 ساعة | عدة ساعات | قواعد بيانات صغيرة | منخفض |
| التزايد في الساعة | في الساعة | 24–48 ساعة | ساعة واحدة | عدة ساعات | قاعدة بيانات متوسطة الحجم | متوسطة |
| استمرارية سجلات oplog | في الوقت الفعلي | 7 أيام | < 1 ثانية | على مستوى الدقيقة | قواعد البيانات الكبيرة | عالية |
| Atlas PITR | تلقائي | 35 يومًا | ثوانٍ | دقائق | خدمة Atlas Cloud | الدفع حسب الاستخدام |
| لقطات الملفات | عند الطلب | 7–30 يومًا | تواتر اللقطات | كل دقيقة | دعم LVM/EBS | منخفض |
عملية اختيار استراتيجية النسخ الاحتياطي:
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) بدءًا من وقت النسخ الاحتياطي وحتى النقطة الزمنية المستهدفة، وبذلك يتم تحقيق استعادة إلى نقطة زمنية محددة بدقة تصل إلى الثانية.
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)
# 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: يرسل العميل اسم المستخدم، فيرد الخادم بـ«سولت» عشوائي وعدد التكرارات. يقوم العميل بإجراء عدة عمليات تجزئة باستخدام كلمة المرور و«السولت» لتوليد دليل، ثم يتحقق الخادم مما إذا كان الدليل يطابق التجزئة المخزنة. ولا يتم أبدًا إرسال كلمة المرور بنص عادي عبر الشبكة.
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
// === 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 |
امتيازات إدارية، وليس مستخدمًا متميزًا |
// === 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 القائم على مبدأ «أدنى امتياز»
// 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
- تشفير TLS/SSL
شرح المفهوم: يعمل تشفير TLS/SSL على تأمين الاتصالات الشبكية لـ MongoDB — مما يمنع هجمات «الرجل في الوسط» والتجسس على البيانات والتلاعب بها. يجب تمكين TLS في بيئات الإنتاج، خاصةً في حالة الاتصالات عبر مراكز البيانات أو عبر السحابة.
كيفية العمل: يقوم بروتوكول TLS بالتحقق من هوية الخادم باستخدام الشهادات وإقامة اتصال مشفر. يدعم MongoDB المصادقة باستخدام شهادات X.509 (كبديل لـ SCRAM)، كما أن بروتوكول TLS المتبادل (mTLS) يتحقق من هويات كل من العميل والخادم.
مستويات التشفير:
| المستوى | طريقة التشفير | نطاق الحماية |
|---|---|---|
| طبقة النقل | TLS/SSL | الاتصالات الشبكية (العميل ↔ الخادم، بين العقد) |
| طبقة التخزين | تشفير WiredTiger | ملفات البيانات (التشفير الثابت) |
| مستوى الحقل | التشفير على مستوى التطبيق | الحقول الحساسة (مثل: كلمات المرور، أرقام الهوية) |
# === 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 |
السماح بالشهادات غير الصالحة | ❌ معطل في بيئة الإنتاج |
تحليل النقاط الرئيسية:
- يمكن للمجموعات المُستضافة ذاتيًا استخدام شهادات موقعة ذاتيًا؛ ويتم تمكين بروتوكول TLS افتراضيًّا في Atlas.
- يتيح بروتوكول mTLS (Mutual TLS) المصادقة القائمة على الشهادات كبديل للمصادقة القائمة على كلمة المرور.
- يزيد بروتوكول 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 (إعادة تشغيل متكررة) |
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) إحصائيات قاعدة البيانات
db.stats();
// {
// db: 'shopdb',
// collections: 10,
// objects: 1000000,
// dataSize: 524288000,
// storageSize: 268435456,
// indexes: 20,
// indexSize: 52428800
// }
(3) تحليل الاستعلامات البطيئة
شرح المفهوم: تُعد الاستعلامات البطيئة المؤشر الرئيسي لمشكلات الأداء في MongoDB. وتتضمن العملية القياسية لتحسين الأداء استخدام أداة Profiler لتسجيل الاستعلامات التي تتجاوز عتبة معينة، ثم تحليل خطط تنفيذها واستخدام الفهارس فيها.
| مستوى تحديد الخصائص | الوصف | التأثير على الأداء |
|---|---|---|
| 0 | إغلاق | لا شيء |
| 1 | الاستعلامات البطيئة فقط | منخفض جدًا |
| 2 | تسجيل جميع العمليات | متوسط (لأغراض التصحيح فقط) |
// === 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) إحصائيات استخدام الفهرس
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') |
تحديد مصدر المزامنة |
// === 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 |
غير مقفل | لا شيء | يمكن تنفيذه في أي وقت |
إجراءات استكشاف الأعطال وإصلاحها في حالات الطوارئ:
db.currentOp()تم العثور على عملية طويلةdb.killOp(opId)إيقاف العملية التي تسبب المشكلةdb.serverStatus().connectionsالتحقق من عدد الاتصالات- إذا وصل عدد الاتصالات إلى السعة القصوى، ففكر في تقليل حجم مجموعة اتصالات التطبيق مؤقتًا.
- استخدم أداة Profiler لتحليل السبب الجذري بعد ذلك، ثم قم بإضافة فهارس أو تحسين الاستعلامات
▶ مثال: سياسة النسخ الاحتياطي الكاملة + تكوين أمان RBAC
# === 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
// === 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/mongorestore
- استراتيجية النسخ الاحتياطي: نسخ احتياطي كامل يومي + نسخ احتياطي مستمر لسجل العمليات (oplog) + Atlas PITR
- شهادة SCRAM + أذونات قائمة على الأدوار (RBAC)
- تشفير TLS/SSL
- المراقبة: حالة الخادم / إحصائيات قاعدة البيانات / الاستعلامات البطيئة / إحصائيات الفهرس
- أوامر العمليات: currentOp / killOp / compact / reIndex
📝 تمارين
- تمرين أساسي (⭐): قم بعمل نسخة احتياطية لقاعدة البيانات
shopdbباستخدامmongodump، ثم قم باستعادتها باستخدامmongorestore. - تمرين أساسي (⭐): قم بإنشاء المستخدمين «admin» و«app_user» ومنحهما الأذونات.
- تمرين متقدم (⭐⭐): قم بتنفيذ برنامج نصي للنسخ الاحتياطي اليومي (cron + mongodump + ضغط + حذف البيانات التي يزيد عمرها عن 7 أيام).
- تمرين متقدم (⭐⭐): قم بتمكين تحليل الاستعلامات البطيئة وحدد أهم 10 استعلامات بطيئة.
- التحدي (⭐⭐⭐): إكمال خطة التشغيل والصيانة (نص برمجي للنسخ الاحتياطي + أذونات المستخدمين + TLS + المراقبة والتنبيهات).