النسخ المتماثلة والتوسّع الأفقي

Replica Set — التوفّر العالي

Replica Set مجموعة من خوادم MongoDB (mongod) تحتفظ بنفس البيانات، لحماية تطبيقك من فقدان خادم واحد:

• Primary — الخادم الوحيد الذي يستقبل الكتابة.
• Secondary (واحد أو أكثر) — نسخة محدّثة تلقائيًّا من Primary عبر سجلّ العمليات (oplog)، بشكل غير متزامن (async).

Primary ──كتابة + oplog──▶ Secondary 1
                        └─▶ Secondary 2

الانتخاب التلقائي (Election)

إذا توقّف Primary عن الاستجابة، تنتخب الأعضاء المتبقّون Secondary جديدًا ليصبح Primary — تلقائيًّا وخلال ثوانٍ، بلا تدخّل يدوي:

rs.status()    // حالة الأعضاء الحاليّة ومن هو Primary

💡 الحد الأدنى الموصى به إنتاجيًّا: 3 أعضاء (Primary + Secondary اثنان) — يضمن أغلبية تصويت حتى لو سقط عضو واحد. MongoDB Atlas ينشئ Replica Set بهذا الشكل تلقائيًّا (راجع درس Atlas).

القراءة من Secondary

افتراضيًّا القراءة من Primary فقط لضمان أحدث بيانات. يمكن توجيه القراءة لـ Secondary لتوزيع الحمل، لكن مع احتمال بيانات متأخّرة قليلًا (replication lag):

db.orders.find().readPref("secondary")

⚠️ لا تقرأ من Secondary لبيانات تحتاج دقّة فورية (مثل رصيد حساب بعد عملية دفع).

Sharding — التوسّع الأفقي

عندما تكبر البيانات عن طاقة خادم واحد (تخزينًا أو حمل قراءة/كتابة)، Sharding يوزّع المجموعة عبر عدّة خوادم بدل ترقية خادم واحد باستمرار.

المكوّنات الثلاثة

• Shard — يخزّن جزءًا من البيانات، وكل shard هو Replica Set بحدّ ذاته.
• mongos — راوتر يوجّه كل استعلام من التطبيق إلى الـ shard الصحيح — التطبيق لا يتّصل بالـ shards مباشرة.
• Config Servers — تخزّن بيانات وصفية (metadata) عن توزّع البيانات بين الـ shards.

التطبيق → mongos → [Shard A] [Shard B] [Shard C]
                         ↑ Config Servers

مفتاح التوزيع (Shard Key)

حقل (أو أكثر) تختاره MongoDB لتقرّر على أساسه في أي shard يُخزَّن كل مستند:

sh.shardCollection("store.orders", { customerId: 1 })

• استعلام يتضمّن customerId → mongos يوجّهه لـ shard محدّد (سريع).
• استعلام بلا customerId (مثل { status: "pending" }) → mongos يبثّه لكل الـ shards (أبطأ).

⚠️ اختيار مفتاح توزيع سيّئ (قيم قليلة التنوّع، أو تسلسلي كـ _id تلقائي) يكدّس البيانات على shard واحد ويُفشل الهدف من التوسّع. اختَره بعناية قبل التفعيل — تغييره لاحقًا ممكن لكنه مكلف.

متى تحتاج كلًّا منهما؟

💡 ابدأ دائمًا بـ Replica Set — أغلب التطبيقات لا تحتاج Sharding أبدًا. Atlas يفعّل Replica Set تلقائيًّا حتى في الطبقة المجّانية.

🎯 هذا آخر مواضيع البنية التحتية — راجع خلاصة المسار لمراجعة شاملة.