پیداوار میں MongoDB اعلی دستیابی: ریپلیکا سیٹ، شارڈنگ، اور Kubernetes آپریٹرز

Azure Cosmos DB برائے MongoDB (vCore)حقیقی MongoDB کی قریب ترین Azure مقامی پیشکش ہے۔ MongoDB کے لیے پرانے RU پر مبنی Cosmos DB API کے برعکس، vCore ماڈل ڈیڈیکیٹڈ کمپیوٹ پر اصل MongoDB انجن کی مثالیں چلاتا ہے، MongoDB 6.0+ خصوصیات کے ساتھ اعلی مطابقت فراہم کرتا ہے بشمول مکمل ایگریگیشن پائپ لائن، اسٹریمز کی تبدیلی، اور لین دین۔ یہ زون فالتو HA، پوائنٹ ان ٹائم ریکوری، اور خودکار بیک اپ پیش کرتا ہے۔

MongoDB اٹلس Azureپر وہی مکمل طور پر منظم MongoDB تجربہ فراہم کرتا ہے جو AWS پر ہے، Azure انفراسٹرکچر پر VNET پیئرنگ، Azure پرائیویٹ لنک، اور Azure AD انٹیگریشن کے ساتھ چل رہا ہے۔

ڈیٹا کی خودمختاری، تعمیل، یا لاگت کی اصلاح کے لیے، MongoDB رینچر مینجمنٹ اور Longhorn تقسیم شدہ اسٹوریج کے ساتھ k3s کا استعمال کرتے ہوئے ننگی دھات Kubernetes پر مؤثر طریقے سے چلتا ہے۔ یہ فن تعمیر ایک ہی آپریٹر پر مبنی مینجمنٹ ماڈل کو برقرار رکھتے ہوئے کلاؤڈ فراہم کنندہ کے انحصار کو ختم کرتا ہے۔

Longhorn Storage برائے 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 کی سفارش Linux پر MongoDB کے لیے ext4 پر کی جاتی ہے۔ MongoDB کا WiredTiger اسٹوریج انجن 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 تفویض کرتا ہے۔

بیک اپ کی حکمت عملی

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/

Percona بیک اپ 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) کو قابل بناتا ہے۔ پی بی ایم بیک اپ اسٹوریج میں اپلاگ اندراجات کو مسلسل آرکائیو کرتا ہے۔ وقت میں ایک مخصوص نقطہ پر بحال کرنے کے لیے، PBM تازہ ترین بیس بیک اپ کو بحال کرتا ہے اور پھر ٹارگٹ ٹائم اسٹیمپ تک oplog اندراجات کو دوبارہ چلاتا ہے۔ یہ پرکونا آپریٹر CRD میںpitrسیکشن کے ذریعے ترتیب دیا گیا ہے۔

کنکشن سٹرنگ کنفیگریشن

فیل اوور ایونٹس کے دوران ایپلیکیشن کی لچک کے لیے مناسب کنکشن سٹرنگ کنفیگریشن اہم ہے۔

# 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کو چیک کریں، جو کہ ایک غیر موثر استفسار پلان کی نشاندہی کرتا ہے۔

وائرڈ ٹائیگر اسٹوریج انجن ٹیوننگ

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 اکثر صفحات کو بے دخل کرتا ہے، جس کی وجہ سے I/O زیادہ ہوتا ہے۔ اگر یہ بہت بڑا ہے، تو یہ OS فائل سسٹم کیش اور دیگر عمل کے لیے ناکافی میموری چھوڑ دیتا ہے۔ نقطہ آغاز دستیاب RAM مائنس 1 GB کا 50% ہے (OS اور دیگر عملوں کے لیے)، ورکنگ سیٹ کے سائز پر بند ہے۔

توثیق اور 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

مانیٹرنگ

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
});

چینج اسٹریمز کو ایک ریپلیکا سیٹ یا شارڈ کلسٹر کی ضرورت ہوتی ہے (وہ اسٹینڈ اسٹون منگوڈ مثالوں پر کام نہیں کرتے ہیں)۔ وہ پرائمری انتخابات میں زندہ رہتے ہیں — ڈرائیور خود بخود دوبارہ جڑ جاتا ہے اور آخری موصول ہونے والے ریزیومے ٹوکن سے دوبارہ شروع ہو جاتا ہے۔ پروڈکشن کے استعمال کے لیے، ہمیشہ دوبارہ شروع کرنے والے ٹوکن کو برقرار رکھیں تاکہ آپ کی ایپلیکیشن غائب ہونے والے واقعات کے بغیر دوبارہ شروع ہونے سے بحال ہو سکے۔

رولنگ مینٹیننس اور ورژن اپ گریڈ

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" })

Kubernetes پر MongoDB کمیونٹی آپریٹر یا Percona آپریٹر کے ساتھ، رولنگ اپ گریڈ خودکار ہوتے ہیں — آپ CRD میںversionفیلڈ کو صرف اپ ڈیٹ کرتے ہیں اور آپریٹر ہر پوڈ کی رولنگ اپ ڈیٹ کو سنبھالتا ہے، آگے بڑھنے سے پہلے ہر ممبر کے صحت مند ہونے کا انتظار کرتا ہے۔

ڈیزاسٹر ریکوری اور فیل اوور ٹیسٹنگ

ایک اعلی دستیابی کی تعیناتی جس کی ناکامی کے تحت کبھی تجربہ نہیں کیا گیا ہے غیر ٹیسٹ شدہ ہے۔ باقاعدگی سے فیل اوور ٹیسٹنگ آپ کے فن تعمیر، آپ کی نگرانی کے انتباہات، اور آپ کی ٹیم کے واقعے کے ردعمل کے طریقہ کار کی توثیق کرتی ہے۔

کنٹرولڈ فیل اوور ٹیسٹ

# 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 پوڈ ری اسٹارٹ اور اوپلاگ کیچ اپ کے ذریعے خودکار بحالی۔ کسی دستی کارروائی کی ضرورت نہیں ہے جب تک کہ ممبر کو مکمل دوبارہ مطابقت پذیری کی ضرورت نہ ہو۔
2. بنیادی ناکامی— خودکار انتخابات 10-12 سیکنڈ کے اندر ثانوی کو فروغ دیتا ہے۔ ایپلیکیشن کنیکٹیویٹی کی توثیق کریں اور بقیہ ثانوی حصوں پر نقل تیار کریں۔
3. اکثریت کی ناکامی— اگر اراکین کی اکثریت کم ہے، تو ریپلیکا سیٹ صرف پڑھنے کے لیے بن جاتا ہے (کوئی انتخابات ممکن نہیں)۔ اراکین کو بحال کریں یا آخری حربے کے طور پرrs.reconfig({ force: true })استعمال کریں (اس سے ڈیٹا ضائع ہو سکتا ہے)۔
4. کلسٹر کا مکمل نقصان— ایک نیا کلسٹر تعینات کریں، تازہ ترین PBM بیک اپ سے بحال کریں، اور oplog کو وقت پر ٹارگٹ پوائنٹ پر دوبارہ چلائیں۔ کنکشن کے تار اور DNS ریکارڈز کو اپ ڈیٹ کریں۔
5. ریجنل فیل اوور— اگر پرائمری ریجن کھو جاتا ہے، تو دوسرے ریجن میں سیکنڈری خود بخود پرائمری منتخب ہو جاتا ہے (اگر اسے کافی ترجیح حاصل ہو اور باقی ممبران کی اکثریت ہو)۔ نئے پرائمری ریجن تک ٹریفک کو روٹ کرنے کے لیے DNS کو اپ ڈیٹ کریں۔

پروڈکشن ٹیوننگ کی سفارشات

OS-Level Tuning

# 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 cache: دستیاب RAM کا 50% مائنس 1 GB، یا آپ کے ورکنگ سیٹ کا سائز، جو بھی چھوٹا ہو۔
• Oplog سائز: تحریری کارروائیوں کے 24-72 گھنٹے منعقد کرنے کے لیے کافی ہے۔ 50 GB کے ساتھ شروع کریں اورrs.printReplicationInfo()کے ساتھ مانیٹر کریں۔
• اسٹوریج IOPS: MongoDB I/O-انتہائی ہے، خاص طور پر کمپیکشن اور چیک پوائنٹنگ کے دوران۔ پروویژنڈ IOPS کے ساتھ NVMe SSD یا کلاؤڈ اسٹوریج کا استعمال کریں (AWS پر 6000+ IOPS کے ساتھ gp3، Azure پر پریمیم SSD v2، GCP پر pd-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"]
});

مانیٹرنگ چیک لسٹ

• Replication lag— الرٹ جب کوئی ثانوی وقفہ کے 30 سیکنڈ سے زیادہ ہو۔
• کنکشن سنترپتی— الرٹ جب موجودہ کنکشنزmaxIncomingConnectionsکے 80% سے زیادہ ہوں۔
• وائرڈ ٹائیگر کیشے— الرٹ جب کیشے کے گندے بھرنے کا تناسب 20% سے زیادہ ہو جائے (یہ اشارہ کرتا ہے کہ تحریری دباؤ چیک پوائنٹ تھرو پٹ سے زیادہ ہے)۔
• اوپلاگ ونڈو— جب اوپلاگ ونڈو 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 خصوصیات کے ساتھ— ایک منظم تجربے کے لیے MongoDB vCore کے لیے Cosmos DB استعمال کریں، یا حقیقی MongoDB نظم شدہ سروس کے لیے Azure پر Atlas استعمال کریں۔
• ملٹی کلاؤڈ یا ہائبرڈ— MongoDB کمیونٹی آپریٹر یا پرکونا آپریٹر کے ساتھ خود کا انتظام۔ Kubernetes خلاصہ فراہم کنندگان میں مسلسل تعیناتی کو قابل بناتا ہے۔
• ننگی دھات یا کنارے— k3s + Rancher + Longhorn + MongoDB کمیونٹی آپریٹر یا پرکونا آپریٹر۔ بادل پر انحصار کی ضرورت نہیں ہے۔
• بڑے پیمانے پر افقی اسکیلنگ— ڈیٹا لوکلٹی کے لیے زون شارڈنگ کے ساتھ شارڈڈ کلسٹر۔ پرکونا آپریٹر استعمال کریں جو مقامی طور پر شارڈ ڈیپلائمنٹس کو سپورٹ کرتا ہے۔
• ریئل ٹائم ایونٹ سے چلنے والی ایپلی کیشنز— MongoDB تبدیلی کے سلسلے بلٹ ان CDC فراہم کرتے ہیں۔ یقینی بنائیں کہ آپ ریپلیکا سیٹ یا شارڈ کلسٹر استعمال کرتے ہیں (اسٹینڈ اکیلا نہیں)۔

نتیجہ

MongoDB کی بلٹ ان ریپلیکیشن اور شارڈنگ پرائمیٹوز اسے اعلیٰ دستیابی کے لیے ایک آرکیٹیکچرل فائدہ دیتے ہیں — خودکار فیل اوور کے ساتھ ریپلیکا سیٹس اور افقی اسکیلنگ کے ساتھ شارڈ کلسٹرز مقامی صلاحیتیں ہیں، نہ کہ بعد کے خیالات۔ لیکن ان ابتدائی چیزوں کو صحیح طریقے سے ترتیب دیا جانا چاہیے اور نظم و ضبط کے ساتھ چلنا چاہیے تاکہ دستیابی کی ضمانت فراہم کی جا سکے جس کی پیداواری نظام کی ضرورت ہے۔

ایک پروڈکشن MongoDB کی تعیناتی کے لیے ناکامی والے ڈومینز میں تین ڈیٹا بیئرنگ ریپلیکا سیٹ ممبرز کی ضرورت ہوتی ہے،w: majorityکو پائیداری کے لیے تشویش، نقل کی لچک کے لیے مناسب اوپلاگ سائزنگ، آپ کے ورکنگ سیٹ کے لیے وائرڈ ٹائیگر کیش ٹیوننگ، اور پوائنٹ ان ٹائم ریکوری کی اہلیت کے ساتھ بیک اپ کی آزمائشی حکمت عملی کی ضرورت ہوتی ہے۔ Kubernetes آپریٹرز - چاہے ریپلیکا سیٹس کے لیے MongoDB کمیونٹی آپریٹر ہو یا شارڈنگ اور انٹیگریٹڈ بیک اپ سمیت مکمل خصوصیات والی تعیناتیوں کے لیے پرکونا آپریٹر - لائف سائیکل مینجمنٹ کو خودکار بنائیں جس کے لیے بصورت دیگر اہم آپریشنل سرمایہ کاری کی ضرورت ہوگی۔

AWS، Azure، GCP، اور ننگی دھات میں تعیناتی پیٹرن ایک ہی بنیادی MongoDB کنفیگریشن کا اشتراک کرتے ہیں۔ اسٹوریج کلاس، بیک اپ کی منزل، اور نیٹ ورکنگ پرت میں کیا تبدیلیاں آتی ہیں۔ یہ مستقل مزاجی آپریٹر پر مبنی نقطہ نظر کی قدر ہے: آپ کی ٹیم ایک ٹول، ایک آپریشنل ماڈل، اور رن بکس کا ایک سیٹ سیکھتی ہے جو ہر جگہ کام کرتی ہے۔

تین رکنی ریپلیکا سیٹ کے ساتھ شروع کریں،w: majorityلکھتا ہے، مسلسل اوپلاگ آرکائیونگ کے ساتھ روزانہ PBM بیک اپ، اور ریپلیکیشن وقفہ، کنکشن سنترپتی، اور کیش پریشر کے لیے بنیادی Prometheus الرٹس۔ پہلے دن اپنے فیل اوور کی جانچ کریں - اپنے پہلے واقعے کے دوران نہیں۔ شارڈنگ، زون پر مبنی ڈیٹا لوکلٹی، اور ملٹی ریجن کی تعیناتیوں تک پھیلائیں کیونکہ آپ کے ڈیٹا کا حجم اور دستیابی کے تقاضے بڑھتے ہیں۔ بنیادی ڈھانچہ میکانکس کو سنبھالتا ہے؛ آپ کی ذمہ داری یہ ہے کہ آپ فن تعمیر کو اتنی گہرائی سے سمجھیں کہ آپ کے کام کے بوجھ کے لیے صحیح تجارت کی جائے اور ان مفروضوں کو مسلسل جانچیں۔