توفر MongoDB بشكل كبير في الإنتاج: مجموعات النسخ المتماثلة والمشاركة ومشغلي Kubernetes

MongoDB موقعًا فريدًا في مشهد قاعدة البيانات. يقوم نموذج المستند الخاص به بتعيين كائنات التطبيق بشكل طبيعي، ويستوعب مخططه المرن هياكل البيانات المتطورة دون عمليات الترحيل، كما توفر النسخ المتماثلة والتجزئة الأولية المضمنة أساسًا للتوفر العالي والقياس الأفقي الذي تتطلب قواعد البيانات العلائقية أدوات خارجية لتحقيقه. لكن الأساس ليس بناء مكتمل. إن تشغيل MongoDB في الإنتاج بتوافر حقيقي عالي - حيث لا يؤدي فشل العقدة أو قسم الشبكة أو عدم اتصال المنطقة بأكملها إلى التوقف عن العمل أو فقدان البيانات - يتطلب بنية متعمدة وضبطًا دقيقًا وانضباطًا تشغيليًا صارمًا.

يتجول هذا الدليل عبر كل طبقة من طبقات MongoDB HA: بدءًا من بروتوكول توافق مجموعة النسخ المتماثلة ونسخ oplog الذي يعمل على تشغيل تجاوز الفشل التلقائي، مروراً ببنية المجموعة المقسمة التي تتيح القياس الأفقي، إلى مشغلي Kubernetes الذين يقومون بأتمتة إدارة دورة الحياة، وعبر خيارات النشر على AWS، وAzure، وGCP، وk3s المعدني العاري مع Rancher. يتضمن كل قسم التكوين الملموس وبيانات YAML والإجراءات التشغيلية التي يمكنك تكييفها مع بيئتك.

MongoDB بنية

مجموعة النسخ المتماثلة هي الوحدة الأساسية لـ MongoDB ذات التوفر العالي. إنها مجموعة من عملياتmongodالتي تحافظ على نفس مجموعة البيانات. أحد الأعضاء هوالأساسي، الذي يتلقى جميع عمليات الكتابة. الأعضاء المتبقون همالمرتبات الثانوية، والتي تقوم بنسخ البيانات من الأساسي عن طريق ذيل سجل التشغيل الخاص به (oplog). إذا أصبح الملف الأساسي غير متاح، فستجري مجموعة النسخ المتماثلة اختيارًا لاختيار ملف أساسي جديد من الملفات الثانوية المؤهلة - عادةً خلال 10 إلى 12 ثانية.

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

ميكانيكا Oplog والنسخ المتماثل

إن oplog عبارة عن مجموعة محددة (local.oplog.rs) تسجل كل عملية تعديل بيانات على الملف الأساسي في شكل غير فعال. تقوم العناصر الثانوية باستمرار بتتبع سجل العمليات الأساسي وتطبيق العمليات محليًا. يحدد حجم سجل العمليات مدى التخلف عن المرحلة الثانوية قبل أن تحتاج إلى إعادة مزامنة كاملة - بالنسبة لأحمال عمل الإنتاج، قم بحجم سجل العمليات ليحتوي على ما لا يقل عن 24 إلى 72 ساعة من نشاط الكتابة. يدعم MongoDB 4.4+ تغيير حجم oplog الديناميكي عبرreplSetResizeOplog.

# Check current oplog size and window
rs.printReplicationInfo()

# Resize the oplog to 50 GB
db.adminCommand({ replSetResizeOplog: 1, size: 51200 })

# Check replication lag on secondaries
rs.printSecondaryReplicationInfo()

والبروتوكول القائم على الطوافة

MongoDB 4.0+ بروتوكول إجماع مستوحى من Raft لانتخابات مجموعة النسخ المتماثلة. عندما تكتشف المرحلة الثانوية أن المرحلة الأساسية غير قابلة للوصول (الافتراضيelectionTimeoutMillisيبلغ 10000 مللي ثانية)، فقد تستدعي إجراء انتخابات. للفوز، يجب على المرشح أن يحصل على أصوات أغلبية الأعضاء المصوتين. العضو الذي لديه أحدث إدخال في مدونة oplog والأولوية الأعلى يفوز إذا كان هناك عدة مرشحين مؤهلين. يمكنك التأثير على نتائج الانتخابات من خلال تحديد أولويات الأعضاء - لا يمكن للعضو الذي لديهpriority: 0أن يصبح أساسيًا أبدًا، وهو أمر مفيد للنسخ المتماثلة من التحليلات أو الأعضاء في المناطق النائية.

# Initiate a 3-member replica set
rs.initiate({
  _id: "rs-production",
  members: [
    { _id: 0, host: "mongo-0.mongo-svc:27017", priority: 10 },
    { _id: 1, host: "mongo-1.mongo-svc:27017", priority: 5 },
    { _id: 2, host: "mongo-2.mongo-svc:27017", priority: 5 }
  ],
  settings: {
    electionTimeoutMillis: 10000,
    heartbeatTimeoutSecs: 10,
    chainingAllowed: true
  }
})

# Check replica set status
rs.status()

# Step down the primary (for maintenance)
rs.stepDown(60)   // step down for 60 seconds

# Force reconfiguration (emergency)
rs.reconfig(newConfig, { force: true })

قراءة التفضيلات وكتابة الاهتمام

تفضيل القراءة يتحكمفي المكان الذي يرسل فيه برنامج التشغيل عمليات القراءة. الخيارات هي:

• primary— تذهب جميع القراءات إلى القراءة الأساسية. أقوى اتساق ولكن لا يوجد قياس للقراءة.
• primaryPreferred— تنتقل القراءات إلى القراءة الأساسية ما لم تكن غير متوفرة، ثم إلى القراءة الثانوية.
• secondary— تذهب جميع القراءات إلى المرتبات الثانوية. يوفر مقياسًا للقراءة ولكنه قد يُرجع بيانات قديمة.
• secondaryPreferred— تنتقل القراءات إلى المرتبات الثانوية ما لم لا يتوفر أي منها.
• nearest— تنتقل القراءات إلى العضو صاحب أقل زمن استجابة للشبكة بغض النظر عن الدور. الأفضل لعمليات النشر الموزعة جغرافيًا.

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

• w: 1- يجب أن يعترف الأساسي فقط. الأسرع ولكنه يخاطر بفقدان البيانات إذا فشل الملف الأساسي قبل النسخ المتماثل.
• w: "majority"— يجب أن تعترف أغلبية الأعضاء الحاملين للبيانات. هذا هو الإعداد الافتراضي للإنتاج الموصى به. إنه يضمن بقاء الكتابة على قيد الحياة في الانتخابات التمهيدية.
• w: <number>— يجب الاعتراف بعدد محدد من الأعضاء.
• j: true— يجب الالتزام بالكتابة في دفتر اليومية الموجود على القرص قبل الإقرار. بالاشتراك معw: "majority"، يوفر هذا أقوى ضمان للمتانة.

# Connection string with write concern and read preference
mongodb://mongo-0:27017,mongo-1:27017,mongo-2:27017/appdb?replicaSet=rs-production&w=majority&j=true&readPreference=secondaryPreferred&readPreferenceTags=region:us-east

# SRV connection string (DNS-based discovery)
mongodb+srv://appuser:password@cluster.example.com/appdb?w=majority&retryWrites=true&readPreference=nearest

MongoDB بنية المجموعة المجزأة

توفر مجموعة النسخ المتماثلة توفرًا عاليًا ولكن ليس مقياس الكتابة الأفقي - تنتقل جميع عمليات الكتابة إلى قاعدة أساسية واحدة. عندما تتجاوز مجموعة البيانات الخاصة بك سعة خادم واحد أو تتجاوز سرعة الكتابة الخاصة بك ما يمكن لقاعدة أساسية واحدة التعامل معه، فأنت بحاجة إلى التقسيم. تقوم المجموعة المقسمة بتوزيع البيانات عبر مجموعات النسخ المتماثلة المتعددة (الأجزاء) باستخدام مفتاح الجزء، مما يتيح التوسع الأفقي لكل من سعة التخزين وإنتاجية الكتابة.

تحتوي المجموعة المجزأة على ثلاثة أنواع من المكونات. أجهزة توجيهmongosعبارة عن أجهزة توجيه استعلام عديمة الحالة توجه عمليات العميل إلى القطعة (الأجزاء) المناسبة. نشر اثنين على الأقل للتكرار. تشكل خوادم تكوينمجموعة نسخ متماثلة تخزن البيانات التعريفية للمجموعة - والتي تعيش عليها القطع، ونطاقات مفاتيح القطعة، وحالة الموازن.​​خوادم Shardعبارة عن مجموعات متماثلة تحتوي كل منها على مجموعة فرعية من البيانات المجزأة.

اختيار مفتاح الجزء

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

# Enable sharding on a database
sh.enableSharding("appdb")

# Shard a collection with a hashed shard key (even distribution)
sh.shardCollection("appdb.events", { "event_id": "hashed" })

# Shard with a ranged shard key (supports range queries)
sh.shardCollection("appdb.orders", { "customer_id": 1, "order_date": 1 })

# Check shard distribution
db.orders.getShardDistribution()

# View chunk distribution across shards
use config
db.chunks.aggregate([
  { $group: { _id: "$shard", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
])

تتضمن إستراتيجيات مفاتيح الجزء الشائعة ما يلي: مفاتيحالمجزأةلتوزيع الكتابة الموحد (الأفضل عندما لا تحتاج إلى استعلامات نطاق على مفتاح الجزء)، ومفاتيحالمركبةالتي تجمع بين حقل التجميع الخشن وحقل ذو عدد كبير من العناصر (على سبيل المثال،{ tenant_id: 1, _id: 1 }للتطبيقات متعددة المستأجرين)، والمفاتيح المستندة إلى المنطقةالتي تعمل على محاذاة وضع البيانات مع المناطق الجغرافية.

لمناطق متعددة

على تقييد نطاقات محددة من مفتاح الجزء إلى أجزاء محددة، مما يتيح محلية البيانات. على سبيل المثال، يمكنك التأكد من أن بيانات العملاء الأوروبيين موجودة على أجزاء في منطقة الاتحاد الأوروبي بينما توجد بيانات عملاء الولايات المتحدة على أجزاء في منطقة الولايات المتحدة.

# Add shards to zones
sh.addShardTag("shard-us-east", "US")
sh.addShardTag("shard-eu-west", "EU")
sh.addShardTag("shard-ap-south", "APAC")

# Define zone ranges
sh.addTagRange("appdb.customers",
  { "region": "US", "customer_id": MinKey },
  { "region": "US", "customer_id": MaxKey },
  "US"
)
sh.addTagRange("appdb.customers",
  { "region": "EU", "customer_id": MinKey },
  { "region": "EU", "customer_id": MaxKey },
  "EU"
)
sh.addTagRange("appdb.customers",
  { "region": "APAC", "customer_id": MinKey },
  { "region": "APAC", "customer_id": MaxKey },
  "APAC"
)

# Verify zone configuration
sh.status()

نشر MongoDB متعدد المناطق

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

في مجموعة متماثلة مكونة من خمسة أعضاء موزعة على ثلاث مناطق (2 في المنطقة الأساسية، 2 في منطقة DR، 1 في منطقة القراءة)، لا يزال فقدان المنطقة الأساسية يترك ثلاثة أعضاء متاحين - وهو ما يكفي للأغلبية لانتخاب انتخابات تمهيدية جديدة. يجب أن يكون لدى العضو الموجود في منطقة القراءةpriority: 0لمنعه من أن يصبح أساسيًا (قد يؤدي زمن الوصول المرتفع عبر المنطقة إلى انخفاض أداء الكتابة). استخدمhidden: trueللأعضاء المخصصين للتحليلات والذين لا ينبغي أن يتلقوا قراءات منتظمة للتطبيق.

MongoDB مجتمع Kubernetes مشغل

يقوم مشغل MongoDB Community Kubernetes بنشر وإدارة مجموعات النسخ المتماثلة لـ MongoDB على Kubernetes. إنه المشغل مفتوح المصدر من شركة MongoDB Inc. الذي يتعامل مع إدارة StatefulSet، وتكوين مجموعة النسخ المتماثلة التلقائية، وتدوير شهادات TLS، وإدارة المستخدم، والترقيات المتجددة.

# Install the MongoDB Community Operator via Helm
helm repo add mongodb https://mongodb.github.io/helm-charts
helm repo update

helm install community-operator mongodb/community-operator \
  --namespace mongodb \
  --create-namespace \
  --set operator.watchNamespace="*"

MongoDBالمجتمع CRD

يحدد المورد المخصصMongoDBCommunityالحالة المطلوبة لمجموعة النسخ المتماثلة MongoDB. وفيما يلي مواصفات جاهزة للإنتاج.

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: production-mongodb
  namespace: databases
spec:
  members: 3
  type: ReplicaSet
  version: "7.0.12"

  security:
    authentication:
      modes: ["SCRAM"]
    tls:
      enabled: true
      certificateKeySecretRef:
        name: mongodb-tls-cert
      caCertificateSecretRef:
        name: mongodb-ca-cert

  users:
    - name: appuser
      db: admin
      passwordSecretRef:
        name: mongodb-appuser-password
      roles:
        - name: readWrite
          db: appdb
        - name: clusterMonitor
          db: admin
      scramCredentialsSecretName: appuser-scram
    - name: backup-user
      db: admin
      passwordSecretRef:
        name: mongodb-backup-password
      roles:
        - name: backup
          db: admin
        - name: restore
          db: admin
      scramCredentialsSecretName: backup-scram
    - name: monitoring
      db: admin
      passwordSecretRef:
        name: mongodb-monitoring-password
      roles:
        - name: clusterMonitor
          db: admin
      scramCredentialsSecretName: monitoring-scram

  additionalMongodConfig:
    storage.wiredTiger.engineConfig.cacheSizeGB: 4
    storage.wiredTiger.engineConfig.journalCompressor: snappy
    storage.wiredTiger.collectionConfig.blockCompressor: snappy
    net.maxIncomingConnections: 10000
    operationProfiling.mode: slowOp
    operationProfiling.slowOpThresholdMs: 100
    replication.oplogSizeMB: 51200
    setParameter.cursorTimeoutMillis: 600000

  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongod
              resources:
                requests:
                  cpu: "2"
                  memory: 8Gi
                limits:
                  cpu: "4"
                  memory: 16Gi
            - name: mongodb-agent
              resources:
                requests:
                  cpu: 250m
                  memory: 256Mi
                limits:
                  cpu: 500m
                  memory: 512Mi
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - topologyKey: topology.kubernetes.io/zone
                  labelSelector:
                    matchLabels:
                      app: production-mongodb-svc
          tolerations:
            - key: "workload"
              operator: "Equal"
              value: "database"
              effect: "NoSchedule"
      volumeClaimTemplates:
        - metadata:
            name: data-volume
          spec:
            storageClassName: gp3-csi
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 100Gi
        - metadata:
            name: logs-volume
          spec:
            storageClassName: gp3-csi
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 10Gi

تنشئ هذه المواصفات مجموعة نسخ متماثلة مكونة من ثلاثة أعضاء تعمل بنظام MongoDB 7.0 مع مصادقة SCRAM، وتشفير TLS، وأحجام البيانات والسجلات المنفصلة، ومكافحة التقارب عبر مناطق التوفر، وضبط WiredTiger المناسب لعقدة ذات ذاكرة وصول عشوائي سعة 16 جيجابايت. يعالج المشغل تهيئة مجموعة النسخ المتماثلة وتكوين الأعضاء والترقيات المتجددة عندما تقوم بتغيير الحقلversion.

Percona لمشغل MongoDB

يوفر مشغل Percona لـ MongoDB (مشغل PSMDB) بديلاً أكثر ثراءً بالميزات لمشغل المجتمع. إنه ينشر Percona Server لـ MongoDB (بديل مباشر لـ MongoDB مع ميزات مؤسسية إضافية)، ويدير المجموعات المقسمة بالإضافة إلى مجموعات النسخ المتماثلة، ويدمج النسخ الاحتياطي عبر Percona Backup لـ MongoDB (PBM)، ويدعم الاسترداد في الوقت المناسب.

# Install Percona Operator
helm repo add percona https://percona.github.io/percona-helm-charts/
helm repo update

helm install psmdb-operator percona/psmdb-operator \
  --namespace psmdb \
  --create-namespace

# Percona Server for MongoDB Cluster CRD
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDB
metadata:
  name: production-psmdb
  namespace: databases
spec:
  crVersion: "1.16.0"
  image: percona/percona-server-mongodb:7.0.12-7
  imagePullPolicy: IfNotPresent

  replsets:
    - name: rs0
      size: 3
      resources:
        requests:
          cpu: "2"
          memory: 8Gi
        limits:
          cpu: "4"
          memory: 16Gi
      volumeSpec:
        persistentVolumeClaim:
          storageClassName: gp3-csi
          accessModes: [ReadWriteOnce]
          resources:
            requests:
              storage: 100Gi
      nonvoting:
        enabled: false
      arbiter:
        enabled: false
      configuration: |
        storage:
          wiredTiger:
            engineConfig:
              cacheSizeGB: 4
              journalCompressor: snappy
            collectionConfig:
              blockCompressor: snappy
        operationProfiling:
          mode: slowOp
          slowOpThresholdMs: 100
        replication:
          oplogSizeMB: 51200
      affinity:
        antiAffinityTopologyKey: topology.kubernetes.io/zone

  sharding:
    enabled: false

  mongos: {}
  configsrv: {}

  backup:
    enabled: true
    image: percona/percona-backup-mongodb:2.5.0
    storages:
      s3-backup:
        type: s3
        s3:
          bucket: company-mongodb-backups
          region: us-east-1
          credentialsSecret: aws-s3-credentials
          prefix: production
          insecureSkipTLSVerify: false
    pitr:
      enabled: true
      oplogOnly: false
      compressionType: gzip
    tasks:
      - name: daily-full
        enabled: true
        schedule: "0 3 * * *"
        keep: 7
        storageName: s3-backup
        compressionType: gzip

  secrets:
    users: mongodb-users-secret

  pmm:
    enabled: true
    image: percona/pmm-client:2
    serverHost: pmm-server.monitoring

الميزة الرئيسية لمشغل Percona هي إدارة النسخ الاحتياطي المتكاملة مع Percona Backup لـ MongoDB (PBM). تدعم PBM النسخ الاحتياطية المنطقية والمادية، والنسخ الاحتياطية التزايدية، والاسترداد في الوقت المناسب من سجل العمليات - وكلها تم تكوينها بشكل تصريحي من خلال CRD.

AWS: DocumentDB مقابل Atlas مقابل الإدارة الذاتية على EKS

Amazon DocumentDBهي خدمة قاعدة بيانات مستندات متوافقة مع MongoDB. إنه ليس MongoDB - إنه محرك خاص ينفذ بروتوكول سلك MongoDB (متوافق حتى MongoDB 4.0 API). يفصل DocumentDB الحوسبة عن التخزين باستخدام طبقة تخزين موزعة مشابهة لـ Aurora. فهو يوفر تجاوزًا تلقائيًا للفشل داخل المنطقة، وما يصل إلى 15 نسخة متماثلة للقراءة، واستردادًا في الوقت المناسب. ومع ذلك، فهو يفتقر إلى العديد من ميزات MongoDB: تدفقات التغيير لها قيود، والمعاملات تعمل بشكل مختلف، والعديد من مراحل مسار التجميع غير مدعومة. استخدم DocumentDB فقط إذا كان التطبيق الخاص بك يستخدم مجموعة فرعية من MongoDB's API وكنت تقدر البساطة التشغيلية لخدمة مُدارة بالكامل.

MongoDB Atlas على AWSهي خدمة مُدارة خاصة بـ MongoDB تعمل على البنية التحتية لـ AWS. إنه يوفر MongoDB أصليًا مع جميع الميزات، وHA الآلي، والنسخ الاحتياطي المستمر، والاسترداد في الوقت المناسب، والقياس التلقائي، والمجموعات متعددة المناطق. يعد Atlas هو الطريق الأسهل لإنتاج MongoDB ولكنه الخيار الأكثر تكلفة على نطاق واسع.

ذاتية الإدارة على EKSالتحكم الكامل في إصدار MongoDB وتكوينه وتكلفته. استخدم مشغل مجتمع MongoDB أو مشغل Percona مع تخزين EBS gp3 وأدوار IAM لحسابات الخدمة (IRSA) للوصول الآمن للنسخ الاحتياطي S3.

# EBS StorageClass optimised for MongoDB
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-csi
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "250"
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

# IRSA for backup S3 access
eksctl create iamserviceaccount \
  --name mongodb-backup-sa \
  --namespace databases \
  --cluster my-eks-cluster \
  --attach-policy-arn arn:aws:iam::111122223333:policy/MongoDBBackupS3Policy \
  --approve

Azure: Cosmos DB مقابل Atlas مقابل الإدارة الذاتية على AKS

Azure Cosmos DB لـ MongoDB (vCore)هو أقرب عرض أصلي لـ Azure إلى MongoDB الحقيقي. على عكس Cosmos DB API الأقدم المستند إلى RU لـ MongoDB، يقوم طراز vCore بتشغيل مثيلات محرك MongoDB الفعلية على حساب مخصص، مما يوفر توافقًا عاليًا مع ميزات MongoDB 6.0+ بما في ذلك خط أنابيب التجميع الكامل وتدفقات التغيير والمعاملات. وهو يوفر HA زائدة عن الحاجة للمنطقة، والاسترداد في الوقت المناسب، والنسخ الاحتياطي التلقائي.

MongoDB Atlas على Azure يوفرنفس تجربة MongoDB المُدارة بالكامل كما هو الحال في AWS، حيث يعمل على البنية التحتية Azure مع VNET Peering، وAzure Private Link، وتكامل Azure AD.

مُدار ذاتيًا على AKS يستخدمالأقراص المُدارة Azure (يوصى بـ Premium SSD v2) مع مشغل MongoDB أو Percona.

# Azure Premium SSD StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-premium-mongodb
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  cachingMode: None
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

GCP: Atlas على GCP مقابل الإدارة الذاتية على GKE

MongoDB Atlas على GCP يعملعلى البنية التحتية لـ Google Cloud مع تكاملات GCP الأصلية: نظير VPC، واتصال الخدمة الخاصة، وتكامل مجموعة GKE. يدعم Atlas on GCP مجموعات متعددة المناطق تمتد عبر مناطق GCP مع تجاوز الفشل تلقائيًا.

المُدار ذاتيًا على GKEقرص SSD ثابتًا مع مشغل MongoDB أو Percona. توفر GKE Workload Identity مصادقة آمنة بدون مفتاح للنسخ الاحتياطي إلى GCS.

# GKE SSD StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-ssd-mongodb
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

المعدن العاري k3s/Rancher مع قرون طويلة

لتحقيق سيادة البيانات أو الامتثال أو تحسين التكلفة، يعمل MongoDB بفعالية على المعدن العاري Kubernetes باستخدام k3s مع إدارة Rancher والتخزين الموزع Longhorn. تعمل هذه البنية على التخلص من تبعيات موفر الخدمة السحابية مع الحفاظ على نفس نموذج الإدارة المعتمد على المشغل.

ذات القرون الطويلة لـ MongoDB

# Install Longhorn
helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.storageMinimalAvailablePercentage=15

# StorageClass for MongoDB on Longhorn
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-mongo
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  dataLocality: best-effort
  fsType: xfs
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Retain

XFS عبر ext4 لـ MongoDB على Linux. يستفيد محرك التخزين WiredTiger الخاص بـ MongoDB من أنماط تخصيص XFS، خاصة بالنسبة للسجلات وملفات البيانات. يوفر النسخ المتماثل ثلاثي الاتجاهات لـ Longhorn تكرارًا على مستوى الحجم بالإضافة إلى تكرار مستوى ضبط النسخ المتماثلة لـ MongoDB، مما يمنحك دفاعًا متعمقًا ضد فشل التخزين.

MetalLB والخدمات مقطوعة الرأس

# MetalLB IP Pool for MongoDB
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: mongo-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.220-192.168.1.225
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: mongo-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - mongo-pool

يقوم مشغل MongoDB بإنشاء خدمة مقطوعة الرأس تمنح كل جراب اسم DNS ثابتًا (mongo-0.mongo-svc.databases.svc.cluster.local). يعد هذا ضروريًا لاكتشاف أعضاء مجموعة النسخ المتماثلة. إذا كنت بحاجة إلى وصول خارجي، تقوم شركة MetalLB بتعيين عنوان IP قابل للتوجيه لخدمة LoadBalancer أمام أجهزة توجيه mongos (للمجموعات المقسمة) أو الأساسي (لمجموعات النسخ المتماثلة).

استراتيجيات النسخ الاحتياطي

MongoDB أساليب نسخ احتياطي متعددة، كل منها يناسب سيناريوهات مختلفة.

mongodump / mongorestore

النسخ الاحتياطية المنطقية التي تصدر مستندات BSON. محمولة ويمكن فحصها من قبل الإنسان، ولكنها بطيئة بالنسبة لمجموعات البيانات الكبيرة ولا تدعم الاسترداد في الوقت المناسب من تلقاء نفسها.

# Full logical backup with oplog for consistency
mongodump --uri="mongodb://backup-user:password@mongo-0:27017,mongo-1:27017,mongo-2:27017/appdb?replicaSet=rs-production&authSource=admin" \
  --oplog \
  --gzip \
  --out=/backups/$(date +%Y%m%d-%H%M%S)

# Restore
mongorestore --uri="mongodb://admin:password@mongo-0:27017/?replicaSet=rs-production&authSource=admin" \
  --oplogReplay \
  --gzip \
  /backups/20260412-030000/

النسخ الاحتياطي بيركونا لـ MongoDB (PBM)

PBM نسخًا احتياطية فعلية ونسخًا احتياطية تزايدية واستردادًا فوريًا. إنها أداة النسخ الاحتياطي الموصى بها لـ MongoDB المُدار ذاتيًا في الإنتاج.

# Configure PBM storage
pbm config --set storage.type=s3 \
  --set storage.s3.bucket=company-mongodb-backups \
  --set storage.s3.region=us-east-1 \
  --set storage.s3.credentials.access-key-id=$AWS_ACCESS_KEY \
  --set storage.s3.credentials.secret-access-key=$AWS_SECRET_KEY

# Full backup
pbm backup --type=logical --compression=gzip

# Physical backup (faster, requires WiredTiger)
pbm backup --type=physical --compression=gzip

# Incremental backup
pbm backup --type=incremental --base-snapshot=2026-04-12T03:00:00Z

# Point-in-time recovery
pbm restore --time="2026-04-12T09:30:00Z"

# List backups
pbm list

# Check backup status
pbm status

في موفري الخدمات السحابية، توفر لقطات EBS (AWS) ولقطات القرص المُدارة (Azure) ولقطات القرص المستمرة (GCP) نسخًا احتياطية سريعة على مستوى التخزين. ومعdb.fsyncLock()لتحقيق الاتساق في الوقت المناسب، فإنها توفر أسرع أوقات النسخ الاحتياطي والاستعادة لمجموعات البيانات الكبيرة.

# Kubernetes VolumeSnapshot for MongoDB
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mongodb-snapshot-$(date +%Y%m%d)
  namespace: databases
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: data-volume-production-mongodb-0

استعادة النقاط في الوقت المناسب المستندة إلى Oplog

يتيح oplog إمكانية الاسترداد في الوقت المناسب (PITR) عند دمجه مع نسخة احتياطية أساسية. يقوم PBM بأرشفة إدخالات oplog بشكل مستمر إلى مخزن النسخ الاحتياطي. لاستعادة نقطة زمنية محددة، يستعيد PBM أحدث نسخة احتياطية أساسية ثم يعيد تشغيل إدخالات سجل العمليات حتى الطابع الزمني المستهدف. تم تكوين هذا في Percona Operator CRD عبر قسمpitr.

لـ HA

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

# Standard connection string with all replica set members
mongodb://appuser:password@mongo-0.mongo-svc:27017,mongo-1.mongo-svc:27017,mongo-2.mongo-svc:27017/appdb?replicaSet=rs-production&w=majority&j=true&readPreference=secondaryPreferred&retryWrites=true&retryReads=true&connectTimeoutMS=10000&socketTimeoutMS=30000&serverSelectionTimeoutMS=15000&maxPoolSize=100&minPoolSize=10

# SRV-based connection string (DNS discovery)
mongodb+srv://appuser:password@mongo-cluster.databases.svc.cluster.local/appdb?w=majority&retryWrites=true&readPreference=nearest

# For sharded clusters (connect through mongos)
mongodb://appuser:password@mongos-0:27017,mongos-1:27017/appdb?w=majority&retryWrites=true&readPreference=nearest

لـ HA: يتيحretryWrites=trueوretryReads=trueإعادة المحاولة التلقائية للعمليات التي تفشل أثناء تجاوز الفشل. يضمنw=majorityبقاء الكتابة في الانتخابات التمهيدية. يتحكمserverSelectionTimeoutMSفي المدة التي ينتظرها السائق للعثور على خادم مناسب - اضبطه على وقت أعلى من وقت الاختيار المتوقع (15 ثانية على الأقل). يحدmaxPoolSizeمن تجمع الاتصال لكل عضو في مجموعة mongos/النسخة المتماثلة لمنع استنفاد الاتصال.

تحسين الفهرس وأداء الاستعلام

هي الرافعة الأساسية لأداء استعلام MongoDB. يفرض الفهرس المفقود في الحقل الذي يتم الاستعلام عنه بشكل متكرر إجراء فحص للمجموعة يتحلل خطيًا مع حجم البيانات.

# Create compound index for common query pattern
db.orders.createIndex(
  { customer_id: 1, order_date: -1, status: 1 },
  { name: "idx_customer_orders", background: true }
)

# Partial index (only index documents matching a filter)
db.events.createIndex(
  { timestamp: 1 },
  { name: "idx_active_events", partialFilterExpression: { status: "active" } }
)

# TTL index for automatic document expiration
db.sessions.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400, name: "idx_session_ttl" }
)

# Text index for search
db.products.createIndex(
  { name: "text", description: "text" },
  { weights: { name: 10, description: 5 }, name: "idx_product_search" }
)

# Analyze query performance
db.orders.find({ customer_id: "c123" }).sort({ order_date: -1 }).explain("executionStats")

# Find unused indexes
db.orders.aggregate([ { $indexStats: {} } ])

قم بمراجعة$indexStatsبانتظام لتحديد الفهارس غير المستخدمة التي تهدر التخزين وتبطئ عملية الكتابة. استخدم طريقةexplain()للتحقق من أن الاستعلامات تستخدم الفهرس المتوقع وتحقق من ارتفاعtotalDocsExaminedبالنسبة إلىnReturned، مما يشير إلى خطة استعلام غير فعالة.

ضبط محرك التخزين WiredTiger

WiredTiger هو محرك تخزين الإنتاج الافتراضي والوحيد لـ MongoDB منذ MongoDB 4.2. تتأثر خصائص أدائه بشكل كبير بحجم ذاكرة التخزين المؤقت والضغط وتكوين دفتر اليومية.

# WiredTiger configuration in mongod.conf
storage:
  dbPath: /data/db
  journal:
    enabled: true
    commitIntervalMs: 100
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4            # ~50% of (RAM - 1GB), max 80%
      journalCompressor: snappy
      directoryForIndexes: true  # separate dir for index files
    collectionConfig:
      blockCompressor: snappy   # or zstd for better ratio
    indexConfig:
      prefixCompression: true

operationProfiling:
  mode: slowOp
  slowOpThresholdMs: 100

replication:
  oplogSizeMB: 51200            # 50 GB oplog
  replSetName: rs-production

net:
  maxIncomingConnections: 10000
  compression:
    compressors: snappy,zstd,zlib

setParameter:
  wiredTigerConcurrentReadTransactions: 128
  wiredTigerConcurrentWriteTransactions: 128

يجب أن يكون حجم ذاكرة التخزين المؤقت WiredTiger لاستيعاب مجموعة العمل الخاصة بك - البيانات والفهارس التي يتم الوصول إليها بشكل نشط من خلال استعلاماتك. إذا كانت ذاكرة التخزين المؤقت صغيرة جدًا، فسيقوم WiredTiger بمسح الصفحات بشكل متكرر، مما يتسبب في ارتفاع مستوى الإدخال/الإخراج. إذا كان حجمه كبيرًا جدًا، فإنه لا يترك ذاكرة كافية لذاكرة التخزين المؤقت لنظام ملفات نظام التشغيل والعمليات الأخرى. نقطة البداية هي 50% من ذاكرة الوصول العشوائي المتوفرة مطروحًا منها 1 جيجابايت (لنظام التشغيل والعمليات الأخرى)، مع تحديد حجم مجموعة العمل.

وتشفير TLS

# Generate TLS certificates for MongoDB
# CA certificate
openssl req -x509 -newkey rsa:4096 -days 3650 -nodes \
  -keyout ca.key -out ca.crt \
  -subj "/CN=MongoDB-CA"

# Server certificate (include all member hostnames in SAN)
openssl req -newkey rsa:4096 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=mongo-0.mongo-svc.databases.svc.cluster.local" \
  -addext "subjectAltName=DNS:mongo-0.mongo-svc.databases.svc.cluster.local,DNS:mongo-1.mongo-svc.databases.svc.cluster.local,DNS:mongo-2.mongo-svc.databases.svc.cluster.local,DNS:localhost,IP:127.0.0.1"

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365

# Combine cert and key into PEM
cat server.crt server.key > server.pem

# Create Kubernetes secrets
kubectl create secret tls mongodb-tls-cert \
  --cert=server.crt --key=server.key -n databases

kubectl create secret generic mongodb-ca-cert \
  --from-file=ca.crt=ca.crt -n databases

# MongoDB TLS configuration (mongod.conf)
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/tls/server.pem
    CAFile: /etc/mongodb/tls/ca.crt
    allowConnectionsWithoutCertificates: false

security:
  authorization: enabled
  clusterAuthMode: x509

مع Prometheus وGrafana

MongoDB المقاييس من خلالmongodb_exporter(من Percona) الذي يتكامل مع Prometheus. تتضمن المقاييس الرئيسية التي يجب مراقبتها عدد الاتصالات ومعدلات التشغيل وتأخر النسخ المتماثل واستخدام ذاكرة التخزين المؤقت WiredTiger وكفاءة استهداف الاستعلام.

# Deploy mongodb_exporter as a sidecar or standalone
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-exporter
  namespace: databases
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb-exporter
  template:
    metadata:
      labels:
        app: mongodb-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9216"
    spec:
      containers:
        - name: exporter
          image: percona/mongodb_exporter:0.40.0
          args:
            - --mongodb.uri=mongodb://monitoring:password@production-mongodb-0.production-mongodb-svc:27017,production-mongodb-1.production-mongodb-svc:27017,production-mongodb-2.production-mongodb-svc:27017/?replicaSet=rs-production&authSource=admin
            - --collect-all
            - --compatible-mode
          ports:
            - containerPort: 9216
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

# ServiceMonitor for Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mongodb-metrics
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: mongodb-exporter
  endpoints:
    - port: metrics
      interval: 15s
      scrapeTimeout: 10s

# Critical Prometheus alert rules for MongoDB
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: mongodb-alerts
  namespace: databases
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: mongodb-health
      rules:
        - alert: MongoDBReplicationLagHigh
          expr: mongodb_mongod_replset_member_replication_lag > 30
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "MongoDB replica {{ $labels.name }} lag exceeds 30s"

        - alert: MongoDBConnectionsHigh
          expr: mongodb_connections{state="current"} / mongodb_connections{state="available"} > 0.8
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "MongoDB connections above 80% capacity"

        - alert: MongoDBWiredTigerCacheEvictions
          expr: rate(mongodb_wiredtiger_cache_evicted_pages_total[5m]) > 100
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "High WiredTiger cache eviction rate"

        - alert: MongoDBReplicaSetNoPrimary
          expr: mongodb_mongod_replset_number_of_members{state="PRIMARY"} == 0
          for: 1m
          labels:
            severity: critical
          annotations:
            summary: "MongoDB replica set has no primary"

        - alert: MongoDBQueryTargetingInefficient
          expr: rate(mongodb_mongod_metrics_query_executor_total{state="scanned_objects"}[5m]) / rate(mongodb_mongod_metrics_query_executor_total{state="returned"}[5m]) > 100
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "MongoDB scanning 100x more documents than returned"

تغيير التدفقات لتطبيقات الوقت الفعلي

آلية إشعار في الوقت الفعلي لتغييرات البيانات في MongoDB. إنهم يستفيدون من oplog لدفع أحداث التغيير إلى التطبيقات، وتمكين البنى التي تعتمد على الأحداث، ولوحات المعلومات في الوقت الحقيقي، وخطوط أنابيب مزامنة البيانات دون الاقتراع.

// Watch changes on a collection
const pipeline = [
  { $match: { operationType: { $in: ["insert", "update", "replace"] } } },
  { $match: { "fullDocument.status": "active" } }
];

const changeStream = db.collection("orders").watch(pipeline, {
  fullDocument: "updateLookup",  // include full document on updates
  resumeAfter: resumeToken       // resume from last processed event
});

changeStream.on("change", (change) => {
  console.log("Change detected:", change.operationType);
  console.log("Document:", change.fullDocument);
  // Store resume token for crash recovery
  saveResumeToken(change._id);
});

changeStream.on("error", (error) => {
  console.error("Change stream error:", error);
  // Reconnect using saved resume token
});

تتطلب تدفقات التغيير مجموعة نسخ متماثلة أو مجموعة مجزأة (لا تعمل على مثيلات mongod المستقلة). إنهم يبقون على قيد الحياة في الانتخابات التمهيدية - يقوم السائق تلقائيًا بإعادة الاتصال واستئناف العمل من آخر رمز مميز للسيرة الذاتية تم استلامه. لاستخدام الإنتاج، استمر دائمًا في رمز السيرة الذاتية حتى يتمكن تطبيقك من التعافي من عمليات إعادة التشغيل دون فقدان الأحداث.

المتداولة وترقية الإصدار

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

# Rolling upgrade procedure for self-managed replica set
# 1. Upgrade each secondary one at a time
# On secondary (mongo-2):
sudo systemctl stop mongod
sudo yum install -y mongodb-org-7.0.14  # or apt-get
sudo systemctl start mongod
# Wait for the member to reach SECONDARY state
rs.status()

# 2. Step down the primary
rs.stepDown()

# 3. Upgrade the old primary (now a secondary)
sudo systemctl stop mongod
sudo yum install -y mongodb-org-7.0.14
sudo systemctl start mongod

# 4. Verify cluster health
rs.status()
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

# 5. Set feature compatibility version (irreversible)
db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

مع مشغل مجتمع MongoDB أو مشغل Percona على Kubernetes، تتم الترقيات المتدرجة تلقائيًا - ما عليك سوى تحديث حقلversionفي CRD ويتولى المشغل التحديث المتجدد لكل حجرة، في انتظار أن يصبح كل عضو بصحة جيدة قبل المتابعة.

التعافي من الكوارث واختبار الفشل

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

# Test 1: Step down the primary
rs.stepDown(120)  // 120-second election hold
// Monitor: election should complete in ~10-12s
// Verify: application reconnects and resumes operations

# Test 2: Kill a secondary pod in Kubernetes
kubectl delete pod production-mongodb-1 -n databases --grace-period=0 --force
// The StatefulSet recreates the pod
// The operator rejoins it to the replica set

# Test 3: Simulate network partition
kubectl exec production-mongodb-0 -n databases -- \
  iptables -A INPUT -p tcp --dport 27017 -j DROP
// The isolated primary should step down (cannot reach majority)
// Remaining members elect a new primary
// Cleanup: remove iptables rule and let member rejoin

# Test 4: Simulate storage failure
kubectl exec production-mongodb-2 -n databases -- \
  chmod 000 /data/db
// mongod should crash; Kubernetes restarts the pod
// The member resyncs from the primary's oplog

ما يجب قياسه أثناء تجاوز الفشل

• RTO (هدف وقت الاسترداد)- الوقت من الفشل الأساسي إلى عمليات الكتابة الأساسية الجديدة. الهدف: أقل من 30 ثانية لمجموعات النسخ المتماثلة.
• RPO (هدف نقطة الاسترداد)— فقدان البيانات أثناء تجاوز الفشل. معw: majority، يكون RPO صفرًا لعمليات الكتابة المعترف بها. معw: 1، يساوي RPO تأخر النسخ المتماثل في وقت الفشل.
• معدل خطأ التطبيق— النسبة المئوية للطلبات التي تفشل أثناء نافذة تجاوز الفشل. معretryWrites=true، تتم إعادة محاولة معظم حالات فشل الكتابة تلقائيًا بواسطة برنامج التشغيل.
• تغيير استمرارية الدفق- تحقق من استئناف مستهلكي دفق التغيير من الرمز المميز المحفوظ الخاص بهم دون فقدان الأحداث.

دليل التشغيل للتعافي من الكوارث

1. فشل عضو واحد- الاسترداد التلقائي عبر إعادة تشغيل جراب Kubernetes ومتابعة oplog. لا يلزم اتخاذ أي إجراء يدوي إلا إذا كان العضو يحتاج إلى إعادة مزامنة كاملة.
2. فشل أساسي— يعمل الاختيار التلقائي على تعزيز الثانوي في غضون 10-12 ثانية. تحقق من اتصال التطبيق وتأخر النسخ المتماثل في المرتبات الثانوية المتبقية.
3. فشل الأغلبية— إذا كانت أغلبية الأعضاء معطلة، تصبح مجموعة النسخ المتماثلة للقراءة فقط (لا توجد انتخابات ممكنة). قم باستعادة الأعضاء أو استخدمrs.reconfig({ force: true })كملاذ أخير (قد يتسبب ذلك في فقدان البيانات).
4. خسارة كاملة للمجموعة— نشر مجموعة جديدة، والاستعادة من أحدث نسخة احتياطية لـ PBM، وإعادة تشغيل oplog إلى النقطة المستهدفة في الوقت المناسب. تحديث سلاسل الاتصال وسجلات DNS.
5. تجاوز الفشل الإقليمي— في حالة فقدان المنطقة الأساسية، يتم تلقائيًا انتخاب منطقة ثانوية في منطقة أخرى كرئيسية (إذا كانت لها أولوية كافية وكان الأعضاء الباقون يشكلون أغلبية). قم بتحديث DNS لتوجيه حركة المرور إلى المنطقة الأساسية الجديدة.

ضبط مستوى نظام التشغيل

# Disable Transparent Huge Pages (critical for MongoDB)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Set readahead to 8-32 sectors for SSD
blockdev --setra 32 /dev/sda

# Increase file descriptor limits
ulimit -n 64000
ulimit -u 64000

# Swappiness
vm.swappiness = 1

# Dirty page ratio
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# Network tuning
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_keepalive_time = 120

• ذاكرة التخزين المؤقت WiredTiger: 50% من ذاكرة الوصول العشوائي المتاحة ناقص 1 جيجابايت، أو حجم مجموعة العمل الخاصة بك، أيهما أصغر.
• حجم Oplog: يكفي لإجراء 24-72 ساعة من عمليات الكتابة. ابدأ بـ 50 جيجابايت وراقب باستخدامrs.printReplicationInfo().
• تخزين IOPS: MongoDB كثيف الإدخال/الإخراج، خاصة أثناء الضغط ونقاط التفتيش. استخدم NVMe SSD أو التخزين السحابي مع IOPS المتوفر (gp3 مع 6000+ IOPS على AWS، Premium SSD v2 على Azure، pd-ssd على GCP).
• CPU: يستفيد MongoDB من النوى المتعددة لعمليات القراءة/الكتابة المتزامنة، ومعاملات WiredTiger المتزامنة، ومهام الخلفية (تحديد النقاط، والضغط، والنسخ المتماثل).
شبكة
• : يمكن أن تكون حركة النسخ المتماثل مهمة بالنسبة لأحمال العمل كثيفة الكتابة. تأكد من وجود شبكة ذات زمن وصول منخفض ونطاق ترددي عالٍ بين أعضاء مجموعة النسخ المتماثلة.

# Application-side connection pool configuration
const client = new MongoClient(uri, {
  maxPoolSize: 100,
  minPoolSize: 10,
  maxIdleTimeMS: 60000,
  waitQueueTimeoutMS: 5000,
  connectTimeoutMS: 10000,
  socketTimeoutMS: 30000,
  serverSelectionTimeoutMS: 15000,
  retryWrites: true,
  retryReads: true,
  w: "majority",
  readPreference: "secondaryPreferred",
  compressors: ["snappy", "zstd"]
});

• تأخر النسخ— تنبيه عندما يتجاوز أي ثانوي 30 ثانية من التأخير.
• تشبع الاتصال— تنبيه عندما تتجاوز الاتصالات الحالية 80% منmaxIncomingConnections.
• ذاكرة التخزين المؤقت WiredTiger- تنبيه عندما تتجاوز نسبة التعبئة المتسخة لذاكرة التخزين المؤقت 20% (يشير إلى أن ضغط الكتابة يتجاوز إنتاجية نقطة التفتيش).
• نافذة Oplog— تنبيه عندما تنخفض نافذة oplog إلى أقل من 12 ساعة (خطر احتياج العناصر الثانوية إلى إعادة المزامنة الكاملة بعد الصيانة).
• استعلام يستهدف— تنبيه عندما تتجاوز نسبة المستندات الممسوحة ضوئيًا إلى المستندات التي تم إرجاعها 100 (فهرس مفقود).
• استخدام القرص- تنبيه عند عتبات 70% و85%. يمكن لـ MongoDB استخدام مساحة قرص مؤقتة كبيرة أثناء الضغط.
• نضارة النسخ الاحتياطي- تنبيه عندما تكون آخر نسخة احتياطية ناجحة أقدم من نافذة RPO الخاصة بك.
• توفر التذاكر- مراقبة WiredTiger لقراءة التذاكر وكتابتها. يؤدي الإرهاق إلى قائمة انتظار العمليات وزيادة زمن الوصول.

مرجع سريع للأوامر التشغيلية

# Replica set status
rs.status()
rs.conf()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

# Cluster health (sharded)
sh.status()
db.adminCommand({ balancerStatus: 1 })
db.adminCommand({ listShards: 1 })

# Server diagnostics
db.serverStatus()
db.currentOp({ "$all": true })
db.adminCommand({ hostInfo: 1 })

# Kill long-running operations
db.killOp(opId)

# Compaction (reclaim disk space)
db.runCommand({ compact: "orders" })

# Profiler (identify slow queries)
db.setProfilingLevel(1, { slowms: 100 })
db.system.profile.find().sort({ ts: -1 }).limit(10)

# Index management
db.orders.getIndexes()
db.orders.createIndex({ field: 1 }, { background: true })
db.orders.dropIndex("index_name")

# Kubernetes-specific
kubectl get mongodbcommunity -n databases
kubectl describe mongodbcommunity production-mongodb -n databases
kubectl logs production-mongodb-0 -n databases -c mongod
kubectl exec -it production-mongodb-0 -n databases -c mongod -- mongosh

: اختيار بنية MongoDB HA الخاصة بك

• سحابة واحدة، تفضيل مُدار— استخدم MongoDB Atlas. فهو يتعامل مع HA والنسخ الاحتياطي والمراقبة والقياس بأقل قدر من الحمل التشغيلي.
يحتاج
• AWS المتوافق مع MongoDB إلىفقط - فكر في Amazon DocumentDB إذا كان تطبيقك يستخدم مجموعة فرعية أساسية من MongoDB API وتريد تجربة مُدارة بالكامل. خلاف ذلك، أطلس أو الإدارة الذاتية على EKS.
• Azure مع ميزات MongoDB الكاملة- استخدم Cosmos DB لـ MongoDB vCore للحصول على تجربة مُدارة، أو Atlas على Azure للخدمة المُدارة MongoDB الأصلية.
• متعدد السحابة أو مختلط - تتم إدارته ذاتيًا باستخدام مشغل مجتمع MongoDB أو مشغل Percona. يتيح تجريد Kubernetes النشر المتسق عبر مقدمي الخدمات.
• المعدن العاري أو الحافة— k3s + Rancher + Longhorn + MongoDB مشغل المجتمع أو مشغل Percona. لا توجد تبعيات سحابية مطلوبة.
• تحجيم أفقي واسع النطاق— مجموعة مقسمة مع تقسيم المنطقة لمحلية البيانات. استخدم مشغل Percona الذي يدعم عمليات النشر المجزأة محليًا.
• التطبيقات المستندة إلى الأحداث في الوقت الحقيقي- توفر تدفقات التغيير MongoDB مراكز السيطرة على الأمراض (CDC) مدمجة. تأكد من استخدام مجموعة النسخ المتماثلة أو المجموعة المجزأة (غير المستقلة).

MongoDB ميزة معمارية للتوفر العالي - مجموعات النسخ المتماثلة مع تجاوز الفشل التلقائي والمجموعات المقسمة ذات القياس الأفقي هي إمكانات أصلية، وليست أفكارًا لاحقة مثبتة. ولكن يجب تكوين هذه البدائيات بشكل صحيح وتشغيلها بانضباط لتقديم ضمانات التوفر التي تتطلبها أنظمة الإنتاج.

يتطلب نشر MongoDB للإنتاج ثلاثة أعضاء لمجموعة النسخ المتماثلة الحاملة للبيانات عبر نطاقات الفشل، وw: majorityيكتب اهتمامًا بالمتانة، وحجم سجل التشغيل المناسب لمرونة النسخ المتماثل، وضبط ذاكرة التخزين المؤقت WiredTiger لمجموعة العمل الخاصة بك، واستراتيجية نسخ احتياطي تم اختبارها مع إمكانية الاسترداد في الوقت المناسب. يقوم مشغلو Kubernetes - سواء كان مشغل مجتمع MongoDB لمجموعات النسخ المتماثلة أو مشغل Percona لعمليات النشر كاملة الميزات بما في ذلك التقسيم والنسخ الاحتياطية المتكاملة - بأتمتة إدارة دورة الحياة التي قد تتطلب استثمارًا تشغيليًا كبيرًا.

تشترك أنماط النشر عبر AWS وAzure وGCP والمعادن العارية في نفس تكوين MongoDB الأساسي. ما يتغير هو فئة التخزين ووجهة النسخ الاحتياطي وطبقة الشبكة. هذا الاتساق هو قيمة النهج القائم على المشغل: يتعلم فريقك أداة واحدة، ونموذج تشغيلي واحد، ومجموعة واحدة من أدلة التشغيل التي تعمل في كل مكان.

ابدأ بمجموعة نسخ متماثلة مكونة من ثلاثة أعضاء، كما يكتبw: majority، ونسخة احتياطية يومية لـ PBM مع أرشفة مستمرة لسجل العمليات، وتنبيهات Prometheus الأساسية لتأخر النسخ المتماثل، وتشبع الاتصال، وضغط ذاكرة التخزين المؤقت. اختبر تجاوز الفشل في اليوم الأول، وليس أثناء الحادث الأول. قم بالتوسيع إلى التقسيم، ومحلية البيانات المستندة إلى المنطقة، وعمليات النشر متعددة المناطق مع نمو حجم البيانات ومتطلبات التوفر. البنية التحتية تتعامل مع الميكانيكا. مسؤوليتك هي فهم البنية بعمق كافٍ لإجراء المقايضات الصحيحة لعبء العمل الخاص بك واختبار تلك الافتراضات بلا هوادة.