MongoDB HA उत्पादन | रेप्लिका सेट, शेयरिंग, K8s ऑपरेटर्स

MongoDB डेटाबेस परिदृश्य में एक अद्वितीय स्थान रखता है। इसका दस्तावेज़ मॉडल स्वाभाविक रूप से एप्लिकेशन ऑब्जेक्ट्स को मैप करता है, इसकी लचीली स्कीमा माइग्रेशन के बिना विकसित डेटा संरचनाओं को समायोजित करती है, और इसकी अंतर्निहित प्रतिकृति और शार्डिंग प्रिमिटिव उच्च उपलब्धता और क्षैतिज स्केलिंग के लिए एक आधार प्रदान करती है जिसे प्राप्त करने के लिए रिलेशनल डेटाबेस को बाहरी टूलींग की आवश्यकता होती है। लेकिन नींव कोई तैयार इमारत नहीं है। वास्तविक उच्च उपलब्धता के साथ उत्पादन में MongoDB चलाना - जहां एक नोड विफलता, एक नेटवर्क विभाजन, या पूरे क्षेत्र के ऑफ़लाइन होने से डाउनटाइम या डेटा हानि नहीं होती है - जानबूझकर वास्तुकला, सावधानीपूर्वक ट्यूनिंग और कठोर परिचालन अनुशासन की आवश्यकता होती है।

यह मार्गदर्शिका MongoDB HA की प्रत्येक परत से गुजरती है: प्रतिकृति सेट सर्वसम्मति प्रोटोकॉल और ओप्लॉग प्रतिकृति से जो स्वचालित विफलता को शक्ति प्रदान करती है, धारित क्लस्टर आर्किटेक्चर के माध्यम से जो क्षैतिज स्केलिंग को सक्षम करती है, Kubernetes ऑपरेटरों तक जो जीवनचक्र प्रबंधन को स्वचालित करती है, और AWS, Azure, GCP, और Rancher के साथ बेअर मेटल k3s पर तैनाती विकल्पों तक। प्रत्येक अनुभाग में ठोस कॉन्फ़िगरेशन, YAML मैनिफ़ेस्ट और परिचालन प्रक्रियाएं शामिल हैं जिन्हें आप अपने वातावरण के अनुसार अनुकूलित कर सकते हैं।

MongoDB रेप्लिका सेट आर्किटेक्चर

एक प्रतिकृति सेट MongoDB की उच्च उपलब्धता की मूलभूत इकाई है। यहmongodप्रक्रियाओं का एक समूह है जो समान डेटा सेट बनाए रखता है। एक सदस्यप्राथमिकहै, जो सभी लेखन संचालन प्राप्त करता है। शेष सदस्यद्वितीयकहैं, जो इसके ऑपरेशन लॉग (ओप्लॉग) को जोड़कर प्राथमिक से डेटा को दोहराते हैं। यदि प्राथमिक अनुपलब्ध हो जाता है, तो प्रतिकृति सेट पात्र माध्यमिक में से एक नया प्राथमिक चुनने के लिए चुनाव करता है - आमतौर पर 10 से 12 सेकंड के भीतर।

एक उत्पादन प्रतिकृति सेट में कम से कम तीन डेटा-असर वाले सदस्य होने चाहिए, जो आदर्श रूप से विभिन्न विफलता डोमेन (उपलब्धता क्षेत्र, रैक या डेटा केंद्र) में फैले हुए हों। यह सुनिश्चित करता है कि प्रतिकृति सेट किसी भी एक सदस्य के नुकसान से बच सकता है और फिर भी चुनाव उद्देश्यों के लिए बहुमत बनाए रख सकता है। एक वैकल्पिकमध्यस्थचुनावों में भाग लेता है, लेकिन कोई डेटा नहीं रखता है - यह केवल संबंधों को तोड़ने के लिए मौजूद होता है जब आपके पास सम संख्या में डेटा-असर वाले सदस्य होते हैं, हालांकि MongoDB का सबसे अच्छा अभ्यास इसके बजाय विषम संख्या में डेटा-असर सदस्यों का उपयोग करना है।

ऑप्लॉग और प्रतिकृति यांत्रिकी

ओपलॉग एक कैप्ड संग्रह (local.oplog.rs) है जो प्राइमरी पर प्रत्येक डेटा-संशोधित ऑपरेशन को इडेम्पोटेंट रूप में रिकॉर्ड करता है। सेकेंडरी लगातार प्राथमिक के ओप्लॉग का पीछा करते हैं और स्थानीय स्तर पर संचालन लागू करते हैं। ओपलॉग का आकार यह निर्धारित करता है कि पूर्ण पुनर्सिंक की आवश्यकता से पहले एक सेकेंडरी कितना पीछे रह सकता है - उत्पादन कार्यभार के लिए, कम से कम 24 से 72 घंटे की लेखन गतिविधि रखने के लिए ओपलॉग का आकार रखें। MongoDB 4.4+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+ प्रतिकृति सेट चुनावों के लिए राफ्ट-प्रेरित सर्वसम्मति प्रोटोकॉल का उपयोग करता है। जब एक सेकेंडरी को पता चलता है कि प्राइमरी पहुंच योग्य नहीं है (10,000ms का डिफ़ॉल्टelectionTimeoutMillis), तो वह चुनाव बुला सकता है। जीतने के लिए, एक उम्मीदवार को मतदान करने वाले अधिकांश सदस्यों से वोट प्राप्त करना होगा। यदि एकाधिक उम्मीदवार पात्र हैं तो सबसे हालिया ओपलॉग प्रविष्टि और सर्वोच्च प्राथमिकता वाला सदस्य जीत जाता है। आप सदस्य प्राथमिकताओं को निर्धारित करके चुनाव परिणामों को प्रभावित कर सकते हैं -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राउटर स्टेटलेस क्वेरी राउटर हैं जो क्लाइंट ऑपरेशन को उचित शार्ड पर निर्देशित करते हैं। अतिरेक के लिए कम से कम दो तैनात करें।कॉन्फ़िग सर्वरएक प्रतिकृति सेट बनाते हैं जो क्लस्टर मेटाडेटा को संग्रहीत करता है - कौन सा हिस्सा किस शार्क पर रहता है, शार्क कुंजी रेंज और बैलेंसर स्थिति।शार्ड सर्वरप्रतिकृति सेट हैं जिनमें से प्रत्येक में शार्ड डेटा का एक सबसेट होता है।

शार्ड कुंजी चयन

शार्ड क्लस्टर में शार्ड कुंजी सबसे परिणामी निर्णय है। यह निर्धारित करता है कि डेटा को शार्क में कैसे वितरित किया जाता है और सीधे क्वेरी प्रदर्शन, लेखन वितरण और स्केल करने की क्षमता को प्रभावित करता है। एक अच्छी शार्ड कुंजी में उच्च कार्डिनैलिटी (कई अलग-अलग मान) होती हैं, जो शार्ड में समान रूप से राइट वितरित करती है, और स्कैटर-इकट्ठा करने के बजाय लक्षित संचालन के साथ सबसे आम क्वेरी पैटर्न का समर्थन करती है।

# 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, रीड क्षेत्र में 1) में वितरित पांच सदस्यीय प्रतिकृति सेट में, प्राथमिक क्षेत्र का नुकसान अभी भी तीन सदस्यों को उपलब्ध छोड़ता है - बहुमत के लिए एक नया प्राथमिक चुनने के लिए पर्याप्त है। इसे प्राथमिक बनने से रोकने के लिए पढ़ने वाले क्षेत्र में सदस्य के पासpriority: 0होना चाहिए (उच्च क्रॉस-क्षेत्र विलंबता लेखन प्रदर्शन को ख़राब कर देगी)। एनालिटिक्स-समर्पित सदस्यों के लिएhidden: trueका उपयोग करें जिन्हें नियमित एप्लिकेशन रीड्स प्राप्त नहीं होना चाहिए।

MongoDB समुदाय Kubernetes ऑपरेटर

MongoDB समुदाय Kubernetes ऑपरेटर Kubernetes पर MongoDB प्रतिकृति सेट को तैनात और प्रबंधित करता है। यह MongoDB Inc. का ओपन-सोर्स ऑपरेटर है जो स्टेटफुलसेट प्रबंधन, स्वचालित प्रतिकृति सेट कॉन्फ़िगरेशन, 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

यह विनिर्देश SCRAM प्रमाणीकरण, TLS एन्क्रिप्शन, अलग डेटा और लॉग वॉल्यूम, उपलब्धता क्षेत्रों में पॉड एंटी-एफ़िनिटी और 16 जीबी रैम वाले नोड के लिए उपयुक्त वायर्डटाइगर ट्यूनिंग के साथ MongoDB 7.0 पर चलने वाला तीन सदस्यीय प्रतिकृति सेट बनाता है। जब आपversionफ़ील्ड बदलते हैं तो ऑपरेटर प्रतिकृति सेट आरंभीकरण, सदस्य कॉन्फ़िगरेशन और रोलिंग अपग्रेड को संभालता है।

MongoDB ऑपरेटरके लिए

पर्कोना सर्वर

MongoDB के लिए पेरकोना ऑपरेटर (PSMDB ऑपरेटर) सामुदायिक ऑपरेटर के लिए अधिक सुविधा संपन्न विकल्प प्रदान करता है। यह MongoDB के लिए पेरकोना सर्वर तैनात करता है (अतिरिक्त एंटरप्राइज़ सुविधाओं के साथ MongoDB के लिए एक ड्रॉप-इन प्रतिस्थापन), शार्प क्लस्टर के साथ-साथ प्रतिकृति सेट का प्रबंधन करता है, 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

पेरकोना ऑपरेटर का मुख्य लाभ MongoDB (PBM) के लिए पेरकोना बैकअप के साथ इसका एकीकृत बैकअप प्रबंधन है। पीबीएम तार्किक और भौतिक बैकअप, वृद्धिशील बैकअप और ओपलॉग से पॉइंट-इन-टाइम रिकवरी का समर्थन करता है - सभी को CRD के माध्यम से घोषणात्मक रूप से कॉन्फ़िगर किया गया है।

AWS परिनियोजन: DocumentDB बनाम एटलस बनाम EKS

पर स्व-प्रबंधित

Amazon DocumentDBएक MongoDB-संगत दस्तावेज़ डेटाबेस सेवा है। यह MongoDB नहीं है - यह एक मालिकाना इंजन है जो MongoDB वायर प्रोटोकॉल (MongoDB 4.0 API तक संगत) लागू करता है। DocumentDB ऑरोरा के समान एक वितरित भंडारण परत का उपयोग करके गणना को भंडारण से अलग करता है। यह एक क्षेत्र के भीतर स्वचालित विफलता, 15 तक पढ़ी गई प्रतिकृतियां और पॉइंट-इन-टाइम पुनर्प्राप्ति प्रदान करता है। हालाँकि, इसमें कई MongoDB सुविधाओं का अभाव है: परिवर्तन धाराओं की सीमाएँ हैं, लेनदेन अलग तरीके से काम करते हैं, और कई एकत्रीकरण पाइपलाइन चरण असमर्थित हैं। DocumentDB का उपयोग केवल तभी करें जब आपका एप्लिकेशन MongoDB के API के सबसेट का उपयोग करता है और आप पूरी तरह से प्रबंधित सेवा की परिचालन सादगी को महत्व देते हैं।

यह सभी सुविधाओं, स्वचालित एचए, निरंतर बैकअप, पॉइंट-इन-टाइम रिकवरी, ऑटो-स्केलिंग और बहु-क्षेत्र क्लस्टर के साथ वास्तविक MongoDB प्रदान करता है। एटलस MongoDB के उत्पादन का सबसे आसान रास्ता है लेकिन पैमाने पर सबसे महंगा विकल्प है।

EKSपर स्व-प्रबंधित आपको MongoDB संस्करण, कॉन्फ़िगरेशन और लागत पर पूर्ण नियंत्रण देता है। सुरक्षित S3 बैकअप एक्सेस के लिए EBS gp3 स्टोरेज और IAM रोल्स फॉर सर्विस अकाउंट्स (IRSA) के साथ MongoDB कम्युनिटी ऑपरेटर या पेरकोना ऑपरेटर का उपयोग करें।

# 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 परिनियोजन: कॉसमॉस DB बनाम एटलस बनाम AKS

पर स्व-प्रबंधित
MongoDB के लिए पुराने RU-आधारित कॉसमॉस DB API के विपरीत, vCore मॉडल समर्पित गणना पर वास्तविक MongoDB इंजन इंस्टेंस चलाता है, जो पूर्ण एकत्रीकरण पाइपलाइन, परिवर्तन स्ट्रीम और लेनदेन सहित MongoDB 6.0+ सुविधाओं के साथ उच्च संगतता प्रदान करता है। यह ज़ोन-रिडंडेंट HA, पॉइंट-इन-टाइम रिकवरी और स्वचालित बैकअप प्रदान करता है।
Azure पर
AKSपर स्व-प्रबंधित MongoDB या पेरकोना ऑपरेटर के साथ Azure प्रबंधित डिस्क (प्रीमियम SSD v2 अनुशंसित) का उपयोग करता है।
# 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 परिनियोजन: GCP पर एटलस बनाम GKE
पर स्व-प्रबंधित GCP पर
जीसीपी पर एटलस स्वचालित विफलता के साथ जीसीपी क्षेत्रों में फैले बहु-क्षेत्रीय समूहों का समर्थन करता है।
GKEपर स्व-प्रबंधित MongoDB या पेरकोना ऑपरेटर के साथ पर्सिस्टेंट डिस्क SSD का उपयोग करता है। जीकेई वर्कलोड आइडेंटिटी जीसीएस के बैकअप के लिए सुरक्षित, बिना चाबी प्रमाणीकरण प्रदान करता है।
# 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/रंचर लॉन्गहॉर्न
के साथ
डेटा संप्रभुता, अनुपालन, या लागत अनुकूलन के लिए, MongoDB रंचर प्रबंधन और लॉन्गहॉर्न वितरित भंडारण के साथ k3s का उपयोग करके नंगे धातु Kubernetes पर प्रभावी ढंग से चलता है। यह आर्किटेक्चर समान ऑपरेटर-आधारित प्रबंधन मॉडल को बनाए रखते हुए क्लाउड प्रदाता निर्भरता को समाप्त करता है।
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
Linux पर MongoDB के लिए ext4 की तुलना में
XFS की अनुशंसा की जाती है। MongoDB का वायर्डटाइगर स्टोरेज इंजन XFS के आवंटन पैटर्न से लाभान्वित होता है, विशेष रूप से जर्नल और डेटा फ़ाइलों के लिए। लॉन्गहॉर्न की तीन-तरफा प्रतिकृति MongoDB की प्रतिकृति सेट-स्तरीय अतिरेक के शीर्ष पर वॉल्यूम-स्तरीय अतिरेक प्रदान करती है, जो आपको भंडारण विफलताओं के खिलाफ गहराई से सुरक्षा प्रदान करती है।
मेटलएलबी और हेडलेस सर्विसेज
# 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) देता है। प्रतिकृति सेट सदस्य खोज के लिए यह आवश्यक है। यदि आपको बाहरी पहुंच की आवश्यकता है, तो मेटलएलबी मोंगोस राउटर्स (शार्डेड क्लस्टर्स के लिए) या प्राथमिक (प्रतिकृति सेट के लिए) के सामने लोडबैलेंसर सेवा को एक रूटेबल आईपी प्रदान करता है।
बैकअप रणनीतियाँ
MongoDB कई बैकअप दृष्टिकोण प्रदान करता है, प्रत्येक अलग-अलग परिदृश्यों के लिए उपयुक्त है।
मोंगोडम्प / मोंगोरेस्टोर
तार्किक बैकअप जो 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
ऑप्लॉग-आधारित पॉइंट-इन-टाइम रिकवरी
बेस बैकअप के साथ संयुक्त होने पर ओपलॉग पॉइंट-इन-टाइम रिकवरी (PITR) सक्षम करता है। पीबीएम लगातार ओप्लॉग प्रविष्टियों को बैकअप स्टोरेज में संग्रहित करता रहता है। समय में एक विशिष्ट बिंदु को पुनर्स्थापित करने के लिए, पीबीएम सबसे हालिया बेस बैकअप को पुनर्स्थापित करता है और फिर लक्ष्य टाइमस्टैम्प तक ओप्लॉग प्रविष्टियों को फिर से चलाता है। इसेpitrअनुभाग के माध्यम से पेरकोना ऑपरेटर CRD में कॉन्फ़िगर किया गया है।
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कनेक्शन समाप्ति को रोकने के लिए प्रति मोंगोस/प्रतिकृति सेट सदस्य कनेक्शन पूल को सीमित करता है।
सूचकांक अनुकूलन और क्वेरी प्रदर्शन
इंडेक्स 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()विधि का उपयोग करें कि क्वेरीज़ अपेक्षित सूचकांक का उपयोग करती हैं औरnReturnedके सापेक्ष उच्चtotalDocsExaminedकी जांच करें, जो एक अक्षम क्वेरी योजना को इंगित करता है।
वायर्डटाइगर स्टोरेज इंजन ट्यूनिंग
वायर्डटाइगर 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
वायर्डटाइगर कैश का आकार आपके कामकाजी सेट को रखने के लिए होना चाहिए - आपके प्रश्नों द्वारा सक्रिय रूप से एक्सेस किए गए डेटा और इंडेक्स। यदि कैश बहुत छोटा है, तो वायर्डटाइगर बार-बार पेजों को हटा देता है, जिससे उच्च I/O उत्पन्न होता है। यदि यह बहुत बड़ा है, तो यह OS फ़ाइल सिस्टम कैश और अन्य प्रक्रियाओं के लिए अपर्याप्त मेमोरी छोड़ता है। प्रारंभिक बिंदु उपलब्ध रैम का 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के साथ
मॉनिटरिंग
MongoDBmongodb_exporter(पेरकोना से) के माध्यम से मेट्रिक्स को उजागर करता है जो Prometheus के साथ एकीकृत होता है। मॉनिटर करने के लिए मुख्य मेट्रिक्स में कनेक्शन गणना, संचालन दर, प्रतिकृति अंतराल, वायर्डटाइगर कैश उपयोग और क्वेरी लक्ष्यीकरण दक्षता शामिल हैं।
# 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 में डेटा परिवर्तनों के लिए एक वास्तविक समय अधिसूचना तंत्र प्रदान करती हैं। वे परिवर्तन की घटनाओं को अनुप्रयोगों में धकेलने के लिए ओप्लॉग का लाभ उठाते हैं, इवेंट-संचालित आर्किटेक्चर, रीयल-टाइम डैशबोर्ड और बिना मतदान के डेटा सिंक्रोनाइज़ेशन पाइपलाइनों को सक्षम करते हैं।
// 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 });
चेंज स्ट्रीम के लिए प्रतिकृति सेट या शार्ड क्लस्टर की आवश्यकता होती है (वे स्टैंडअलोन मोंगॉड इंस्टेंसेस पर काम नहीं करते हैं)। वे प्राथमिक चुनावों से बचे रहते हैं - ड्राइवर स्वचालित रूप से पुनः कनेक्ट होता है और अंतिम प्राप्त बायोडाटा टोकन से फिर से शुरू होता है। उत्पादन उपयोग के लिए, रेज़्युमे टोकन को हमेशा जारी रखें ताकि आपका एप्लिकेशन गुम घटनाओं के बिना पुनरारंभ से पुनर्प्राप्त हो सके।
रोलिंग रखरखाव और संस्करण उन्नयन
यह छोटे और बड़े संस्करण परिवर्तनों के लिए शून्य-डाउनटाइम अपग्रेड की अनुमति देता है।
# 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" })
आपदा पुनर्प्राप्ति और विफलता परीक्षण
एक उच्च उपलब्धता परिनियोजन जिसका विफलता के तहत कभी परीक्षण नहीं किया गया है, परीक्षण नहीं किया गया है। नियमित फेलओवर परीक्षण आपके आर्किटेक्चर, आपके मॉनिटरिंग अलर्ट और आपकी टीम की घटना प्रतिक्रिया प्रक्रियाओं को मान्य करता है।
नियंत्रित विफलता परीक्षण
# 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के साथ, अधिकांश लेखन विफलताएं ड्राइवर द्वारा स्वचालित रूप से पुनः प्रयास की जाती हैं।
परिवर्तन स्ट्रीम निरंतरता- सत्यापित करें कि परिवर्तन स्ट्रीम उपभोक्ता अपने सहेजे गए टोकन से बिना किसी घटना के गायब हुए फिर से शुरू करते हैं।
डिजास्टर रिकवरी रनबुक
एकल सदस्य विफलता- Kubernetes पॉड पुनरारंभ और ओपलॉग कैच-अप के माध्यम से स्वचालित पुनर्प्राप्ति। जब तक सदस्य को पूर्ण पुनर्समन्वयन की आवश्यकता न हो, तब तक किसी मैन्युअल कार्रवाई की आवश्यकता नहीं है।
प्राथमिक विफलता- स्वचालित चुनाव 10-12 सेकंड के भीतर एक माध्यमिक को बढ़ावा देता है। शेष सेकेंडरी पर एप्लिकेशन कनेक्टिविटी और प्रतिकृति अंतराल को सत्यापित करें।
बहुमत विफलता- यदि अधिकांश सदस्य नीचे हैं, तो प्रतिकृति सेट केवल पढ़ने के लिए बन जाता है (कोई चुनाव संभव नहीं)। सदस्यों को पुनर्स्थापित करें या अंतिम उपाय के रूप मेंrs.reconfig({ force: true })का उपयोग करें (इससे डेटा हानि हो सकती है)।
पूर्ण क्लस्टर हानि- एक नया क्लस्टर तैनात करें, नवीनतम पीबीएम बैकअप से पुनर्स्थापित करें, और समय पर लक्ष्य बिंदु पर ओप्लॉग को फिर से चलाएं। कनेक्शन स्ट्रिंग और DNS रिकॉर्ड अपडेट करें।
क्षेत्रीय विफलता- यदि प्राथमिक क्षेत्र खो जाता है, तो दूसरे क्षेत्र में एक माध्यमिक स्वचालित रूप से प्राथमिक चुना जाता है (यदि इसकी पर्याप्त प्राथमिकता है और शेष सदस्य बहुमत बनाते हैं)। ट्रैफ़िक को नए प्राथमिक क्षेत्र में रूट करने के लिए DNS को अपडेट करें।
उत्पादन ट्यूनिंग अनुशंसाएँ
OS-स्तरीय ट्यूनिंग
# 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
संसाधन आकार दिशानिर्देश
वायर्डटाइगर कैश: उपलब्ध रैम का 50% माइनस 1 जीबी, या आपके वर्किंग सेट का आकार, जो भी छोटा हो।
ऑप्लॉग आकार: 24-72 घंटे लिखने के संचालन के लिए पर्याप्त है। 50 जीबी से शुरू करें औरrs.printReplicationInfo()से मॉनिटर करें।
स्टोरेज IOPS: MongoDB I/O-सघन है, विशेष रूप से संघनन और चेकपॉइंटिंग के दौरान। प्रावधानित IOPS (AWS पर 6000+ IOPS के साथ gp3, Azure पर प्रीमियम SSD v2, GCP पर पीडी-एसएसडी) के साथ NVMe SSD या क्लाउड स्टोरेज का उपयोग करें।
CPU: MongoDB समवर्ती पढ़ने/लिखने के संचालन, वायर्डटाइगर के समवर्ती लेनदेन और पृष्ठभूमि कार्यों (चेकपॉइंटिंग, कॉम्पैक्शन, प्रतिकृति) के लिए एकाधिक कोर से लाभ उठाता है।
नेटवर्क: लेखन-भारी कार्यभार के लिए प्रतिकृति ट्रैफ़िक महत्वपूर्ण हो सकता है। प्रतिकृति सेट सदस्यों के बीच कम-विलंबता, उच्च-बैंडविड्थ नेटवर्किंग सुनिश्चित करें।
कनेक्शन प्रबंधन
# 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 सेकंड से अधिक हो तो अलर्ट।
कनेक्शन संतृप्ति- जब वर्तमान कनेक्शनmaxIncomingConnectionsके 80% से अधिक हो तो अलर्ट।
वायर्डटाइगर कैश- कैश गंदा भरण अनुपात 20% से अधिक होने पर अलर्ट (चेकपॉइंट थ्रूपुट से अधिक लिखने का दबाव इंगित करता है)।
ओपलॉग विंडो- जब ओपलॉग विंडो 12 घंटे से कम हो जाए तो अलर्ट करें (रखरखाव के बाद सेकेंडरी को पूर्ण पुन: समन्वयन की आवश्यकता का जोखिम)।
क्वेरी लक्ष्यीकरण- जब स्कैन किए गए दस्तावेज़ों और लौटाए गए दस्तावेज़ों का अनुपात 100 (अनुपलब्ध सूचकांक) से अधिक हो तो अलर्ट करें।
डिस्क उपयोग- 70% और 85% सीमा पर अलर्ट। MongoDB संघनन के दौरान महत्वपूर्ण अस्थायी डिस्क स्थान का उपयोग कर सकता है।
बैकअप ताजगी- जब अंतिम सफल बैकअप आपकी RPO विंडो से पुराना हो तो अलर्ट करें।
टिकट उपलब्धता- मॉनिटर वायर्डटाइगर टिकट पढ़ें और लिखें। थकावट ऑपरेशन कतार और विलंबता स्पाइक्स का कारण बनती है।
ऑपरेशनल कमांड त्वरित संदर्भ
# 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 एटलस का उपयोग करें। यह न्यूनतम परिचालन ओवरहेड के साथ HA, बैकअप, मॉनिटरिंग और स्केलिंग को संभालता है।
AWS केवल MongoDB-संगत आवश्यकताओं के साथ- यदि आपका एप्लिकेशन MongoDB API के मूल उपसमूह का उपयोग करता है और आप पूरी तरह से प्रबंधित अनुभव चाहते हैं तो Amazon DocumentDB पर विचार करें। अन्यथा, एटलस या ईकेएस पर स्व-प्रबंधित।
पूर्ण MongoDB सुविधाओं के साथ
Azure- प्रबंधित अनुभव के लिए MongoDB vCore के लिए Cosmos DB का उपयोग करें, या वास्तविक MongoDB प्रबंधित सेवा के लिए Azure पर एटलस का उपयोग करें।
मल्टी-क्लाउड या हाइब्रिड- MongoDB कम्युनिटी ऑपरेटर या पेरकोना ऑपरेटर के साथ स्व-प्रबंधित। Kubernetes एब्स्ट्रैक्शन सभी प्रदाताओं में लगातार तैनाती को सक्षम बनाता है।
नंगे धातु या किनारे- k3s + Rancher + Longhorn + MongoDB सामुदायिक ऑपरेटर या पेरकोना ऑपरेटर। किसी क्लाउड निर्भरता की आवश्यकता नहीं है.
बड़े पैमाने पर क्षैतिज स्केलिंग- डेटा इलाके के लिए जोन शार्डिंग के साथ साझा क्लस्टर। पेरकोना ऑपरेटर का उपयोग करें जो मूल रूप से शार्ड परिनियोजन का समर्थन करता है।
रीयल-टाइम इवेंट-संचालित एप्लिकेशन- MongoDB परिवर्तन धाराएं अंतर्निहित सीडीसी प्रदान करती हैं। सुनिश्चित करें कि आप प्रतिकृति सेट या शार्ड क्लस्टर का उपयोग करें (स्टैंडअलोन नहीं)।
निष्कर्ष
MongoDB की अंतर्निहित प्रतिकृति और शार्डिंग प्रिमिटिव इसे उच्च उपलब्धता के लिए एक वास्तुशिल्प लाभ देते हैं - स्वचालित विफलता के साथ प्रतिकृति सेट और क्षैतिज स्केलिंग के साथ शार्ड क्लस्टर मूल क्षमताएं हैं, बोल्ट-ऑन बाद के विचार नहीं हैं। लेकिन उत्पादन प्रणालियों द्वारा मांग की जाने वाली उपलब्धता की गारंटी देने के लिए इन प्राइमेटिव्स को सही ढंग से कॉन्फ़िगर किया जाना चाहिए और अनुशासन के साथ संचालित किया जाना चाहिए।
एक उत्पादन MongoDB परिनियोजन के लिए विफलता डोमेन में तीन डेटा-असर प्रतिकृति सेट सदस्यों की आवश्यकता होती है,w: majorityस्थायित्व के लिए चिंता लिखता है, प्रतिकृति लचीलेपन के लिए उचित ओपलॉग आकार, आपके कामकाजी सेट के लिए वायर्डटाइगर कैश ट्यूनिंग, और पॉइंट-इन-टाइम पुनर्प्राप्ति क्षमता के साथ एक परीक्षण बैकअप रणनीति। Kubernetes ऑपरेटर - चाहे प्रतिकृति सेट के लिए MongoDB सामुदायिक ऑपरेटर हो या शार्डिंग और एकीकृत बैकअप सहित पूर्ण-विशेषताओं वाली तैनाती के लिए पेरकोना ऑपरेटर - जीवनचक्र प्रबंधन को स्वचालित करते हैं जिसके लिए अन्यथा महत्वपूर्ण परिचालन निवेश की आवश्यकता होती है।
AWS, Azure, GCP और बेअर मेटल में परिनियोजन पैटर्न समान कोर MongoDB कॉन्फ़िगरेशन साझा करते हैं। स्टोरेज क्लास, बैकअप डेस्टिनेशन और नेटवर्किंग लेयर में क्या परिवर्तन होता है। यह स्थिरता एक ऑपरेटर-आधारित दृष्टिकोण का मूल्य है: आपकी टीम एक उपकरण, एक परिचालन मॉडल और रनबुक का एक सेट सीखती है जो हर जगह काम करती है।
तीन-सदस्यीय प्रतिकृति सेट के साथ प्रारंभ करें,w: majorityलिखता है, निरंतर ओप्लॉग संग्रह के साथ एक दैनिक पीबीएम बैकअप, और प्रतिकृति अंतराल, कनेक्शन संतृप्ति और कैश दबाव के लिए कोर Prometheus अलर्ट। अपने फेलओवर का परीक्षण पहले ही दिन करें - अपनी पहली घटना के दौरान नहीं। जैसे-जैसे आपकी डेटा मात्रा और उपलब्धता आवश्यकताएं बढ़ती हैं, शेयरिंग, ज़ोन-आधारित डेटा इलाके और बहु-क्षेत्र परिनियोजन तक विस्तार करें। बुनियादी ढांचा यांत्रिकी को संभालता है; आपकी जिम्मेदारी है कि आप अपने कार्यभार के लिए सही समझौता करने के लिए वास्तुकला को गहराई से समझें और उन धारणाओं का लगातार परीक्षण करें।

MongoDB रेप्लिका सेट आर्किटेक्चर

ऑप्लॉग और प्रतिकृति यांत्रिकी

# 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()

चुनाव और राफ्ट-आधारित प्रोटोकॉल

# 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 साझा क्लस्टर आर्किटेक्चर

शार्ड कुंजी चयन

# 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 } }
])

बहु-क्षेत्रके लिए
ज़ोन शेयरिंग
ज़ोन शार्डिंग शार्ड कुंजी की विशिष्ट श्रेणियों को विशिष्ट शार्ड तक सीमित करता है, जिससे डेटा स्थानीयता सक्षम होती है। उदाहरण के लिए, आप यह सुनिश्चित कर सकते हैं कि यूरोपीय ग्राहक डेटा यूरोपीय संघ क्षेत्र में टुकड़ों पर रहता है जबकि अमेरिकी ग्राहक डेटा अमेरिकी क्षेत्र में टुकड़ों पर रहता है।
# 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, रीड क्षेत्र में 1) में वितरित पांच सदस्यीय प्रतिकृति सेट में, प्राथमिक क्षेत्र का नुकसान अभी भी तीन सदस्यों को उपलब्ध छोड़ता है - बहुमत के लिए एक नया प्राथमिक चुनने के लिए पर्याप्त है। इसे प्राथमिक बनने से रोकने के लिए पढ़ने वाले क्षेत्र में सदस्य के पासpriority: 0होना चाहिए (उच्च क्रॉस-क्षेत्र विलंबता लेखन प्रदर्शन को ख़राब कर देगी)। एनालिटिक्स-समर्पित सदस्यों के लिएhidden: trueका उपयोग करें जिन्हें नियमित एप्लिकेशन रीड्स प्राप्त नहीं होना चाहिए।
MongoDB समुदाय Kubernetes ऑपरेटर
MongoDB समुदाय Kubernetes ऑपरेटर Kubernetes पर MongoDB प्रतिकृति सेट को तैनात और प्रबंधित करता है। यह MongoDB Inc. का ओपन-सोर्स ऑपरेटर है जो स्टेटफुलसेट प्रबंधन, स्वचालित प्रतिकृति सेट कॉन्फ़िगरेशन, 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
यह विनिर्देश SCRAM प्रमाणीकरण, TLS एन्क्रिप्शन, अलग डेटा और लॉग वॉल्यूम, उपलब्धता क्षेत्रों में पॉड एंटी-एफ़िनिटी और 16 जीबी रैम वाले नोड के लिए उपयुक्त वायर्डटाइगर ट्यूनिंग के साथ MongoDB 7.0 पर चलने वाला तीन सदस्यीय प्रतिकृति सेट बनाता है। जब आपversionफ़ील्ड बदलते हैं तो ऑपरेटर प्रतिकृति सेट आरंभीकरण, सदस्य कॉन्फ़िगरेशन और रोलिंग अपग्रेड को संभालता है।
MongoDB ऑपरेटरके लिए
पर्कोना सर्वर
MongoDB के लिए पेरकोना ऑपरेटर (PSMDB ऑपरेटर) सामुदायिक ऑपरेटर के लिए अधिक सुविधा संपन्न विकल्प प्रदान करता है। यह MongoDB के लिए पेरकोना सर्वर तैनात करता है (अतिरिक्त एंटरप्राइज़ सुविधाओं के साथ MongoDB के लिए एक ड्रॉप-इन प्रतिस्थापन), शार्प क्लस्टर के साथ-साथ प्रतिकृति सेट का प्रबंधन करता है, 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
पेरकोना ऑपरेटर का मुख्य लाभ MongoDB (PBM) के लिए पेरकोना बैकअप के साथ इसका एकीकृत बैकअप प्रबंधन है। पीबीएम तार्किक और भौतिक बैकअप, वृद्धिशील बैकअप और ओपलॉग से पॉइंट-इन-टाइम रिकवरी का समर्थन करता है - सभी को CRD के माध्यम से घोषणात्मक रूप से कॉन्फ़िगर किया गया है।
AWS परिनियोजन: DocumentDB बनाम एटलस बनाम EKS
पर स्व-प्रबंधित
Amazon DocumentDBएक MongoDB-संगत दस्तावेज़ डेटाबेस सेवा है। यह MongoDB नहीं है - यह एक मालिकाना इंजन है जो MongoDB वायर प्रोटोकॉल (MongoDB 4.0 API तक संगत) लागू करता है। DocumentDB ऑरोरा के समान एक वितरित भंडारण परत का उपयोग करके गणना को भंडारण से अलग करता है। यह एक क्षेत्र के भीतर स्वचालित विफलता, 15 तक पढ़ी गई प्रतिकृतियां और पॉइंट-इन-टाइम पुनर्प्राप्ति प्रदान करता है। हालाँकि, इसमें कई MongoDB सुविधाओं का अभाव है: परिवर्तन धाराओं की सीमाएँ हैं, लेनदेन अलग तरीके से काम करते हैं, और कई एकत्रीकरण पाइपलाइन चरण असमर्थित हैं। DocumentDB का उपयोग केवल तभी करें जब आपका एप्लिकेशन MongoDB के API के सबसेट का उपयोग करता है और आप पूरी तरह से प्रबंधित सेवा की परिचालन सादगी को महत्व देते हैं।
यह सभी सुविधाओं, स्वचालित एचए, निरंतर बैकअप, पॉइंट-इन-टाइम रिकवरी, ऑटो-स्केलिंग और बहु-क्षेत्र क्लस्टर के साथ वास्तविक MongoDB प्रदान करता है। एटलस MongoDB के उत्पादन का सबसे आसान रास्ता है लेकिन पैमाने पर सबसे महंगा विकल्प है।
EKSपर स्व-प्रबंधित आपको MongoDB संस्करण, कॉन्फ़िगरेशन और लागत पर पूर्ण नियंत्रण देता है। सुरक्षित S3 बैकअप एक्सेस के लिए EBS gp3 स्टोरेज और IAM रोल्स फॉर सर्विस अकाउंट्स (IRSA) के साथ MongoDB कम्युनिटी ऑपरेटर या पेरकोना ऑपरेटर का उपयोग करें।
# 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 परिनियोजन: कॉसमॉस DB बनाम एटलस बनाम AKS
पर स्व-प्रबंधित
MongoDB के लिए पुराने RU-आधारित कॉसमॉस DB API के विपरीत, vCore मॉडल समर्पित गणना पर वास्तविक MongoDB इंजन इंस्टेंस चलाता है, जो पूर्ण एकत्रीकरण पाइपलाइन, परिवर्तन स्ट्रीम और लेनदेन सहित MongoDB 6.0+ सुविधाओं के साथ उच्च संगतता प्रदान करता है। यह ज़ोन-रिडंडेंट HA, पॉइंट-इन-टाइम रिकवरी और स्वचालित बैकअप प्रदान करता है।
Azure पर
AKSपर स्व-प्रबंधित MongoDB या पेरकोना ऑपरेटर के साथ Azure प्रबंधित डिस्क (प्रीमियम SSD v2 अनुशंसित) का उपयोग करता है।
# 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 परिनियोजन: GCP पर एटलस बनाम GKE
पर स्व-प्रबंधित GCP पर
जीसीपी पर एटलस स्वचालित विफलता के साथ जीसीपी क्षेत्रों में फैले बहु-क्षेत्रीय समूहों का समर्थन करता है।
GKEपर स्व-प्रबंधित MongoDB या पेरकोना ऑपरेटर के साथ पर्सिस्टेंट डिस्क SSD का उपयोग करता है। जीकेई वर्कलोड आइडेंटिटी जीसीएस के बैकअप के लिए सुरक्षित, बिना चाबी प्रमाणीकरण प्रदान करता है।
# 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/रंचर लॉन्गहॉर्न
के साथ
डेटा संप्रभुता, अनुपालन, या लागत अनुकूलन के लिए, MongoDB रंचर प्रबंधन और लॉन्गहॉर्न वितरित भंडारण के साथ k3s का उपयोग करके नंगे धातु Kubernetes पर प्रभावी ढंग से चलता है। यह आर्किटेक्चर समान ऑपरेटर-आधारित प्रबंधन मॉडल को बनाए रखते हुए क्लाउड प्रदाता निर्भरता को समाप्त करता है।
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
Linux पर MongoDB के लिए ext4 की तुलना में
XFS की अनुशंसा की जाती है। MongoDB का वायर्डटाइगर स्टोरेज इंजन XFS के आवंटन पैटर्न से लाभान्वित होता है, विशेष रूप से जर्नल और डेटा फ़ाइलों के लिए। लॉन्गहॉर्न की तीन-तरफा प्रतिकृति MongoDB की प्रतिकृति सेट-स्तरीय अतिरेक के शीर्ष पर वॉल्यूम-स्तरीय अतिरेक प्रदान करती है, जो आपको भंडारण विफलताओं के खिलाफ गहराई से सुरक्षा प्रदान करती है।
मेटलएलबी और हेडलेस सर्विसेज
# 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) देता है। प्रतिकृति सेट सदस्य खोज के लिए यह आवश्यक है। यदि आपको बाहरी पहुंच की आवश्यकता है, तो मेटलएलबी मोंगोस राउटर्स (शार्डेड क्लस्टर्स के लिए) या प्राथमिक (प्रतिकृति सेट के लिए) के सामने लोडबैलेंसर सेवा को एक रूटेबल आईपी प्रदान करता है।
बैकअप रणनीतियाँ
MongoDB कई बैकअप दृष्टिकोण प्रदान करता है, प्रत्येक अलग-अलग परिदृश्यों के लिए उपयुक्त है।
मोंगोडम्प / मोंगोरेस्टोर
तार्किक बैकअप जो 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
ऑप्लॉग-आधारित पॉइंट-इन-टाइम रिकवरी
बेस बैकअप के साथ संयुक्त होने पर ओपलॉग पॉइंट-इन-टाइम रिकवरी (PITR) सक्षम करता है। पीबीएम लगातार ओप्लॉग प्रविष्टियों को बैकअप स्टोरेज में संग्रहित करता रहता है। समय में एक विशिष्ट बिंदु को पुनर्स्थापित करने के लिए, पीबीएम सबसे हालिया बेस बैकअप को पुनर्स्थापित करता है और फिर लक्ष्य टाइमस्टैम्प तक ओप्लॉग प्रविष्टियों को फिर से चलाता है। इसेpitrअनुभाग के माध्यम से पेरकोना ऑपरेटर CRD में कॉन्फ़िगर किया गया है।
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कनेक्शन समाप्ति को रोकने के लिए प्रति मोंगोस/प्रतिकृति सेट सदस्य कनेक्शन पूल को सीमित करता है।
सूचकांक अनुकूलन और क्वेरी प्रदर्शन
इंडेक्स 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()विधि का उपयोग करें कि क्वेरीज़ अपेक्षित सूचकांक का उपयोग करती हैं औरnReturnedके सापेक्ष उच्चtotalDocsExaminedकी जांच करें, जो एक अक्षम क्वेरी योजना को इंगित करता है।
वायर्डटाइगर स्टोरेज इंजन ट्यूनिंग
वायर्डटाइगर 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
वायर्डटाइगर कैश का आकार आपके कामकाजी सेट को रखने के लिए होना चाहिए - आपके प्रश्नों द्वारा सक्रिय रूप से एक्सेस किए गए डेटा और इंडेक्स। यदि कैश बहुत छोटा है, तो वायर्डटाइगर बार-बार पेजों को हटा देता है, जिससे उच्च I/O उत्पन्न होता है। यदि यह बहुत बड़ा है, तो यह OS फ़ाइल सिस्टम कैश और अन्य प्रक्रियाओं के लिए अपर्याप्त मेमोरी छोड़ता है। प्रारंभिक बिंदु उपलब्ध रैम का 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के साथ
मॉनिटरिंग
MongoDBmongodb_exporter(पेरकोना से) के माध्यम से मेट्रिक्स को उजागर करता है जो Prometheus के साथ एकीकृत होता है। मॉनिटर करने के लिए मुख्य मेट्रिक्स में कनेक्शन गणना, संचालन दर, प्रतिकृति अंतराल, वायर्डटाइगर कैश उपयोग और क्वेरी लक्ष्यीकरण दक्षता शामिल हैं।
# 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 में डेटा परिवर्तनों के लिए एक वास्तविक समय अधिसूचना तंत्र प्रदान करती हैं। वे परिवर्तन की घटनाओं को अनुप्रयोगों में धकेलने के लिए ओप्लॉग का लाभ उठाते हैं, इवेंट-संचालित आर्किटेक्चर, रीयल-टाइम डैशबोर्ड और बिना मतदान के डेटा सिंक्रोनाइज़ेशन पाइपलाइनों को सक्षम करते हैं।
// 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 });
चेंज स्ट्रीम के लिए प्रतिकृति सेट या शार्ड क्लस्टर की आवश्यकता होती है (वे स्टैंडअलोन मोंगॉड इंस्टेंसेस पर काम नहीं करते हैं)। वे प्राथमिक चुनावों से बचे रहते हैं - ड्राइवर स्वचालित रूप से पुनः कनेक्ट होता है और अंतिम प्राप्त बायोडाटा टोकन से फिर से शुरू होता है। उत्पादन उपयोग के लिए, रेज़्युमे टोकन को हमेशा जारी रखें ताकि आपका एप्लिकेशन गुम घटनाओं के बिना पुनरारंभ से पुनर्प्राप्त हो सके।
रोलिंग रखरखाव और संस्करण उन्नयन
यह छोटे और बड़े संस्करण परिवर्तनों के लिए शून्य-डाउनटाइम अपग्रेड की अनुमति देता है।
# 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" })
आपदा पुनर्प्राप्ति और विफलता परीक्षण
एक उच्च उपलब्धता परिनियोजन जिसका विफलता के तहत कभी परीक्षण नहीं किया गया है, परीक्षण नहीं किया गया है। नियमित फेलओवर परीक्षण आपके आर्किटेक्चर, आपके मॉनिटरिंग अलर्ट और आपकी टीम की घटना प्रतिक्रिया प्रक्रियाओं को मान्य करता है।
नियंत्रित विफलता परीक्षण
# 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के साथ, अधिकांश लेखन विफलताएं ड्राइवर द्वारा स्वचालित रूप से पुनः प्रयास की जाती हैं।
परिवर्तन स्ट्रीम निरंतरता- सत्यापित करें कि परिवर्तन स्ट्रीम उपभोक्ता अपने सहेजे गए टोकन से बिना किसी घटना के गायब हुए फिर से शुरू करते हैं।
डिजास्टर रिकवरी रनबुक
एकल सदस्य विफलता- Kubernetes पॉड पुनरारंभ और ओपलॉग कैच-अप के माध्यम से स्वचालित पुनर्प्राप्ति। जब तक सदस्य को पूर्ण पुनर्समन्वयन की आवश्यकता न हो, तब तक किसी मैन्युअल कार्रवाई की आवश्यकता नहीं है।
प्राथमिक विफलता- स्वचालित चुनाव 10-12 सेकंड के भीतर एक माध्यमिक को बढ़ावा देता है। शेष सेकेंडरी पर एप्लिकेशन कनेक्टिविटी और प्रतिकृति अंतराल को सत्यापित करें।
बहुमत विफलता- यदि अधिकांश सदस्य नीचे हैं, तो प्रतिकृति सेट केवल पढ़ने के लिए बन जाता है (कोई चुनाव संभव नहीं)। सदस्यों को पुनर्स्थापित करें या अंतिम उपाय के रूप मेंrs.reconfig({ force: true })का उपयोग करें (इससे डेटा हानि हो सकती है)।
पूर्ण क्लस्टर हानि- एक नया क्लस्टर तैनात करें, नवीनतम पीबीएम बैकअप से पुनर्स्थापित करें, और समय पर लक्ष्य बिंदु पर ओप्लॉग को फिर से चलाएं। कनेक्शन स्ट्रिंग और DNS रिकॉर्ड अपडेट करें।
क्षेत्रीय विफलता- यदि प्राथमिक क्षेत्र खो जाता है, तो दूसरे क्षेत्र में एक माध्यमिक स्वचालित रूप से प्राथमिक चुना जाता है (यदि इसकी पर्याप्त प्राथमिकता है और शेष सदस्य बहुमत बनाते हैं)। ट्रैफ़िक को नए प्राथमिक क्षेत्र में रूट करने के लिए DNS को अपडेट करें।
उत्पादन ट्यूनिंग अनुशंसाएँ
OS-स्तरीय ट्यूनिंग
# 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
संसाधन आकार दिशानिर्देश
वायर्डटाइगर कैश: उपलब्ध रैम का 50% माइनस 1 जीबी, या आपके वर्किंग सेट का आकार, जो भी छोटा हो।
ऑप्लॉग आकार: 24-72 घंटे लिखने के संचालन के लिए पर्याप्त है। 50 जीबी से शुरू करें औरrs.printReplicationInfo()से मॉनिटर करें।
स्टोरेज IOPS: MongoDB I/O-सघन है, विशेष रूप से संघनन और चेकपॉइंटिंग के दौरान। प्रावधानित IOPS (AWS पर 6000+ IOPS के साथ gp3, Azure पर प्रीमियम SSD v2, GCP पर पीडी-एसएसडी) के साथ NVMe SSD या क्लाउड स्टोरेज का उपयोग करें।
CPU: MongoDB समवर्ती पढ़ने/लिखने के संचालन, वायर्डटाइगर के समवर्ती लेनदेन और पृष्ठभूमि कार्यों (चेकपॉइंटिंग, कॉम्पैक्शन, प्रतिकृति) के लिए एकाधिक कोर से लाभ उठाता है।
नेटवर्क: लेखन-भारी कार्यभार के लिए प्रतिकृति ट्रैफ़िक महत्वपूर्ण हो सकता है। प्रतिकृति सेट सदस्यों के बीच कम-विलंबता, उच्च-बैंडविड्थ नेटवर्किंग सुनिश्चित करें।
कनेक्शन प्रबंधन
# 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 सेकंड से अधिक हो तो अलर्ट।
कनेक्शन संतृप्ति- जब वर्तमान कनेक्शनmaxIncomingConnectionsके 80% से अधिक हो तो अलर्ट।
वायर्डटाइगर कैश- कैश गंदा भरण अनुपात 20% से अधिक होने पर अलर्ट (चेकपॉइंट थ्रूपुट से अधिक लिखने का दबाव इंगित करता है)।
ओपलॉग विंडो- जब ओपलॉग विंडो 12 घंटे से कम हो जाए तो अलर्ट करें (रखरखाव के बाद सेकेंडरी को पूर्ण पुन: समन्वयन की आवश्यकता का जोखिम)।
क्वेरी लक्ष्यीकरण- जब स्कैन किए गए दस्तावेज़ों और लौटाए गए दस्तावेज़ों का अनुपात 100 (अनुपलब्ध सूचकांक) से अधिक हो तो अलर्ट करें।
डिस्क उपयोग- 70% और 85% सीमा पर अलर्ट। MongoDB संघनन के दौरान महत्वपूर्ण अस्थायी डिस्क स्थान का उपयोग कर सकता है।
बैकअप ताजगी- जब अंतिम सफल बैकअप आपकी RPO विंडो से पुराना हो तो अलर्ट करें।
टिकट उपलब्धता- मॉनिटर वायर्डटाइगर टिकट पढ़ें और लिखें। थकावट ऑपरेशन कतार और विलंबता स्पाइक्स का कारण बनती है।
ऑपरेशनल कमांड त्वरित संदर्भ
# 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 एटलस का उपयोग करें। यह न्यूनतम परिचालन ओवरहेड के साथ HA, बैकअप, मॉनिटरिंग और स्केलिंग को संभालता है।
AWS केवल MongoDB-संगत आवश्यकताओं के साथ- यदि आपका एप्लिकेशन MongoDB API के मूल उपसमूह का उपयोग करता है और आप पूरी तरह से प्रबंधित अनुभव चाहते हैं तो Amazon DocumentDB पर विचार करें। अन्यथा, एटलस या ईकेएस पर स्व-प्रबंधित।
पूर्ण MongoDB सुविधाओं के साथ
Azure- प्रबंधित अनुभव के लिए MongoDB vCore के लिए Cosmos DB का उपयोग करें, या वास्तविक MongoDB प्रबंधित सेवा के लिए Azure पर एटलस का उपयोग करें।
मल्टी-क्लाउड या हाइब्रिड- MongoDB कम्युनिटी ऑपरेटर या पेरकोना ऑपरेटर के साथ स्व-प्रबंधित। Kubernetes एब्स्ट्रैक्शन सभी प्रदाताओं में लगातार तैनाती को सक्षम बनाता है।
नंगे धातु या किनारे- k3s + Rancher + Longhorn + MongoDB सामुदायिक ऑपरेटर या पेरकोना ऑपरेटर। किसी क्लाउड निर्भरता की आवश्यकता नहीं है.
बड़े पैमाने पर क्षैतिज स्केलिंग- डेटा इलाके के लिए जोन शार्डिंग के साथ साझा क्लस्टर। पेरकोना ऑपरेटर का उपयोग करें जो मूल रूप से शार्ड परिनियोजन का समर्थन करता है।
रीयल-टाइम इवेंट-संचालित एप्लिकेशन- MongoDB परिवर्तन धाराएं अंतर्निहित सीडीसी प्रदान करती हैं। सुनिश्चित करें कि आप प्रतिकृति सेट या शार्ड क्लस्टर का उपयोग करें (स्टैंडअलोन नहीं)।
निष्कर्ष
MongoDB की अंतर्निहित प्रतिकृति और शार्डिंग प्रिमिटिव इसे उच्च उपलब्धता के लिए एक वास्तुशिल्प लाभ देते हैं - स्वचालित विफलता के साथ प्रतिकृति सेट और क्षैतिज स्केलिंग के साथ शार्ड क्लस्टर मूल क्षमताएं हैं, बोल्ट-ऑन बाद के विचार नहीं हैं। लेकिन उत्पादन प्रणालियों द्वारा मांग की जाने वाली उपलब्धता की गारंटी देने के लिए इन प्राइमेटिव्स को सही ढंग से कॉन्फ़िगर किया जाना चाहिए और अनुशासन के साथ संचालित किया जाना चाहिए।
एक उत्पादन MongoDB परिनियोजन के लिए विफलता डोमेन में तीन डेटा-असर प्रतिकृति सेट सदस्यों की आवश्यकता होती है,w: majorityस्थायित्व के लिए चिंता लिखता है, प्रतिकृति लचीलेपन के लिए उचित ओपलॉग आकार, आपके कामकाजी सेट के लिए वायर्डटाइगर कैश ट्यूनिंग, और पॉइंट-इन-टाइम पुनर्प्राप्ति क्षमता के साथ एक परीक्षण बैकअप रणनीति। Kubernetes ऑपरेटर - चाहे प्रतिकृति सेट के लिए MongoDB सामुदायिक ऑपरेटर हो या शार्डिंग और एकीकृत बैकअप सहित पूर्ण-विशेषताओं वाली तैनाती के लिए पेरकोना ऑपरेटर - जीवनचक्र प्रबंधन को स्वचालित करते हैं जिसके लिए अन्यथा महत्वपूर्ण परिचालन निवेश की आवश्यकता होती है।
AWS, Azure, GCP और बेअर मेटल में परिनियोजन पैटर्न समान कोर MongoDB कॉन्फ़िगरेशन साझा करते हैं। स्टोरेज क्लास, बैकअप डेस्टिनेशन और नेटवर्किंग लेयर में क्या परिवर्तन होता है। यह स्थिरता एक ऑपरेटर-आधारित दृष्टिकोण का मूल्य है: आपकी टीम एक उपकरण, एक परिचालन मॉडल और रनबुक का एक सेट सीखती है जो हर जगह काम करती है।
तीन-सदस्यीय प्रतिकृति सेट के साथ प्रारंभ करें,w: majorityलिखता है, निरंतर ओप्लॉग संग्रह के साथ एक दैनिक पीबीएम बैकअप, और प्रतिकृति अंतराल, कनेक्शन संतृप्ति और कैश दबाव के लिए कोर Prometheus अलर्ट। अपने फेलओवर का परीक्षण पहले ही दिन करें - अपनी पहली घटना के दौरान नहीं। जैसे-जैसे आपकी डेटा मात्रा और उपलब्धता आवश्यकताएं बढ़ती हैं, शेयरिंग, ज़ोन-आधारित डेटा इलाके और बहु-क्षेत्र परिनियोजन तक विस्तार करें। बुनियादी ढांचा यांत्रिकी को संभालता है; आपकी जिम्मेदारी है कि आप अपने कार्यभार के लिए सही समझौता करने के लिए वास्तुकला को गहराई से समझें और उन धारणाओं का लगातार परीक्षण करें।