MongoDB উৎপাদনে উচ্চ প্রাপ্যতা: রেপ্লিকা সেট, শার্ডিং এবং Kubernetes অপারেটর

Azure কসমস ডিবি MongoDB (vCore)হল আসল MongoDB-এর নিকটতম Azure নেটিভ অফার৷ MongoDB-এর জন্য পুরানো RU-ভিত্তিক Cosmos DB API-এর বিপরীতে, vCore মডেলটি ডেডিকেটেড কম্পিউটে প্রকৃত MongoDB ইঞ্জিন ইন্সট্যান্স চালায়, MongoDB 6.0+ বৈশিষ্ট্যগুলির সাথে উচ্চ সামঞ্জস্য প্রদান করে যার মধ্যে সম্পূর্ণ একত্রিত পাইপলাইন, স্ট্রিম পরিবর্তন এবং লেনদেন। এটি জোন-অপ্রয়োজনীয় HA, পয়েন্ট-ইন-টাইম পুনরুদ্ধার এবং স্বয়ংক্রিয় ব্যাকআপ অফার করে।

ডেটা সার্বভৌমত্ব, সম্মতি, বা খরচ অপ্টিমাইজেশনের জন্য, MongoDB কার্যকরভাবে বেয়ার মেটাল Kubernetes-এ k3s ব্যবহার করে রাঞ্চার ম্যানেজমেন্ট এবং লংহর্ন ডিস্ট্রিবিউটেড স্টোরেজ ব্যবহার করে। এই আর্কিটেকচার একই অপারেটর-ভিত্তিক ব্যবস্থাপনা মডেল বজায় রাখার সময় ক্লাউড প্রদানকারী নির্ভরতা দূর করে।

লংহর্ন স্টোরেজ

# 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-এর WiredTiger স্টোরেজ ইঞ্জিন XFS-এর বরাদ্দ প্যাটার্ন থেকে বিশেষ করে জার্নাল এবং ডেটা ফাইলের জন্য উপকারী। লংহর্নের থ্রি-ওয়ে রেপ্লিকেশন 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 মঙ্গোস রাউটারগুলির সামনে (শার্ড ক্লাস্টারগুলির জন্য) বা প্রাথমিক (প্রতিলিপি সেটগুলির জন্য) একটি লোডব্যালেন্সার পরিষেবাতে একটি রাউটেবল আইপি বরাদ্দ করে৷

ব্যাকআপ কৌশল

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/

পারকোনা ব্যাকআপ

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 ক্রমাগত ব্যাকআপ স্টোরেজে অপলগ এন্ট্রি সংরক্ষণ করে। নির্দিষ্ট সময়ে পুনরুদ্ধার করতে, PBM সাম্প্রতিকতম বেস ব্যাকআপ পুনরুদ্ধার করে এবং তারপরে টার্গেট টাইমস্ট্যাম্প পর্যন্ত অপলগ এন্ট্রিগুলিকে রিপ্লে করে। এটিpitrবিভাগের মাধ্যমে Percona অপারেটর CRD-এ কনফিগার করা হয়েছে।

সংযোগ স্ট্রিং কনফিগারেশন

সঠিক সংযোগ স্ট্রিং কনফিগারেশন ব্যর্থতা ইভেন্টের সময় অ্যাপ্লিকেশন স্থিতিস্থাপকতা জন্য গুরুত্বপূর্ণ।

# 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 স্টোরেজ ইঞ্জিন টিউনিং

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 ফাইল সিস্টেম ক্যাশে এবং অন্যান্য প্রক্রিয়াগুলির জন্য অপর্যাপ্ত মেমরি ছেড়ে দেয়। একটি প্রারম্ভিক বিন্দু হল উপলব্ধ র‍্যামের 50% বিয়োগ 1 GB (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(Percona থেকে) এর মাধ্যমে মেট্রিক্স প্রকাশ করে যা Prometheus এর সাথে একীভূত হয়। নিরীক্ষণের মূল মেট্রিক্সের মধ্যে রয়েছে সংযোগের সংখ্যা, অপারেশন রেট, রেপ্লিকেশন ল্যাগ, WiredTiger ক্যাশে ব্যবহার এবং কোয়েরি টার্গেটিং দক্ষতা।

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

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

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

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

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

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

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

রিয়েল-টাইম অ্যাপ্লিকেশনের জন্য স্ট্রীম পরিবর্তন করুন

পরিবর্তন স্ট্রীমগুলি MongoDB-এ ডেটা পরিবর্তনের জন্য একটি রিয়েল-টাইম বিজ্ঞপ্তি প্রক্রিয়া প্রদান করে। তারা ইভেন্টগুলিকে অ্যাপ্লিকেশনগুলিতে পরিবর্তন করতে, ইভেন্ট-চালিত আর্কিটেকচার, রিয়েল-টাইম ড্যাশবোর্ড এবং ভোট ছাড়াই ডেটা সিঙ্ক্রোনাইজেশন পাইপলাইন সক্ষম করতে অপলগ ব্যবহার করে।

// 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 কমিউনিটি অপারেটর বা পারকোনা অপারেটরের সাথে, রোলিং আপগ্রেডগুলি স্বয়ংক্রিয় হয় — আপনি কেবল 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 ব্যাকআপ থেকে পুনরুদ্ধার করুন, এবং সময়মত টার্গেট পয়েন্টে অপলগ রিপ্লে করুন। সংযোগ স্ট্রিং এবং DNS রেকর্ড আপডেট করুন।
5. আঞ্চলিক ব্যর্থতা— যদি প্রাথমিক অঞ্চল হারিয়ে যায়, অন্য অঞ্চলে একটি মাধ্যমিক স্বয়ংক্রিয়ভাবে প্রাথমিক নির্বাচিত হয় (যদি এটির যথেষ্ট অগ্রাধিকার থাকে এবং অবশিষ্ট সদস্যরা সংখ্যাগরিষ্ঠ হয়)। নতুন প্রাথমিক অঞ্চলে ট্রাফিক রুট করতে 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

রিসোর্স সাইজিং নির্দেশিকা

• WiredTiger ক্যাশে: উপলব্ধ RAM এর 50% বিয়োগ 1 GB, অথবা আপনার কাজের সেটের আকার, যেটি ছোট।
• অপলগ আকার: 24-72 ঘন্টা লেখার ক্রিয়াকলাপ ধরে রাখার জন্য যথেষ্ট। 50 GB দিয়ে শুরু করুন এবংrs.printReplicationInfo()দিয়ে মনিটর করুন।
• স্টোরেজ IOPS: MongoDB হল I/O-নিবিড়, বিশেষত কমপ্যাকশন এবং চেকপয়েন্টিংয়ের সময়। NVMe SSD বা ক্লাউড স্টোরেজ ব্যবহার করুন IOPS সহ (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"]
});

মনিটরিং চেকলিস্ট

• রেপ্লিকেশন ল্যাগ— কোনো সেকেন্ডারি 30 সেকেন্ডের ব্যবধান অতিক্রম করলে সতর্কতা।
• সংযোগ স্যাচুরেশন— সতর্কতা যখন বর্তমান সংযোগগুলিmaxIncomingConnections-এর 80% অতিক্রম করে।
• WiredTiger ক্যাশে— যখন ক্যাশে নোংরা ফিল অনুপাত 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 অ্যাটলাস ব্যবহার করুন। এটি এইচএ, ব্যাকআপ, মনিটরিং এবং ন্যূনতম অপারেশনাল ওভারহেড সহ স্কেলিং পরিচালনা করে।
• AWS সঙ্গে MongoDB-সামঞ্জস্যপূর্ণ প্রয়োজন শুধুমাত্র— আপনার অ্যাপ্লিকেশন যদি MongoDB API-এর একটি মৌলিক উপসেট ব্যবহার করে এবং আপনি একটি সম্পূর্ণরূপে পরিচালিত অভিজ্ঞতা চান তাহলে Amazon DocumentDB বিবেচনা করুন৷ অন্যথায়, EKS-এ Atlas বা স্ব-পরিচালিত।
• Azure সম্পূর্ণ MongoDB বৈশিষ্ট্য সহ— একটি পরিচালিত অভিজ্ঞতার জন্য MongoDB vCore-এর জন্য Cosmos DB ব্যবহার করুন, অথবা প্রকৃত MongoDB পরিচালিত পরিষেবার জন্য Azure-এ Atlas ব্যবহার করুন৷
• মাল্টি-ক্লাউড বা হাইব্রিড— MongoDB কমিউনিটি অপারেটর বা পারকোনা অপারেটরের সাথে স্ব-পরিচালিত। Kubernetes বিমূর্ততা প্রদানকারী জুড়ে ধারাবাহিক স্থাপনা সক্ষম করে।
• বেয়ার মেটাল বা প্রান্ত— k3s + Rancher + Longhorn + MongoDB কমিউনিটি অপারেটর বা Percona অপারেটর। কোন ক্লাউড নির্ভরতা প্রয়োজন.
• বড়-স্কেল অনুভূমিক স্কেলিং— ডেটা লোকেলিটির জন্য জোন শার্ডিং সহ শার্ডেড ক্লাস্টার৷ পারকোনা অপারেটর ব্যবহার করুন যা স্থানীয়ভাবে শার্ডেড স্থাপনার সমর্থন করে।
• রিয়েল-টাইম ইভেন্ট-চালিত অ্যাপ্লিকেশনগুলি— MongoDB পরিবর্তন স্ট্রীমগুলি অন্তর্নির্মিত CDC প্রদান করে৷ আপনি একটি রেপ্লিকা সেট বা শার্ড ক্লাস্টার ব্যবহার করেন তা নিশ্চিত করুন (স্বতন্ত্র নয়)।

উপসংহার

MongoDB-এর বিল্ট-ইন রেপ্লিকেশন এবং শার্ডিং প্রিমিটিভগুলি উচ্চ প্রাপ্যতার জন্য এটিকে একটি স্থাপত্যগত সুবিধা দেয় — স্বয়ংক্রিয় ফেইলওভার সহ রেপ্লিকা সেট এবং অনুভূমিক স্কেলিং সহ শার্ডেড ক্লাস্টারগুলি নেটিভ ক্ষমতা, বোল্ট-অন আফটার থট নয়। কিন্তু এই আদিম জিনিসগুলিকে অবশ্যই সঠিকভাবে কনফিগার করতে হবে এবং শৃঙ্খলার সাথে চালিত হতে হবে যাতে উৎপাদন ব্যবস্থার চাহিদার প্রাপ্যতা নিশ্চিত করা যায়।

একটি প্রোডাকশন MongoDB স্থাপনের জন্য ব্যর্থ ডোমেন জুড়ে তিনটি ডেটা-বহনকারী প্রতিরূপ সেট সদস্যের প্রয়োজন, স্থায়িত্বের জন্যw: majorityলিখতে উদ্বেগ, প্রতিলিপি স্থিতিস্থাপকতার জন্য সঠিক অপলগ সাইজিং, আপনার কাজের সেটের জন্য WiredTiger ক্যাশে টিউনিং এবং পয়েন্ট-ইন-টাইম পুনরুদ্ধারের ক্ষমতা সহ একটি পরীক্ষিত ব্যাকআপ কৌশল। Kubernetes অপারেটর - রেপ্লিকা সেটের জন্য MongoDB কমিউনিটি অপারেটর হোক বা শার্ডিং এবং ইন্টিগ্রেটেড ব্যাকআপ সহ পূর্ণ বৈশিষ্ট্যযুক্ত স্থাপনার জন্য পারকোনা অপারেটর হোক - জীবনচক্র ব্যবস্থাপনা স্বয়ংক্রিয় করুন যা অন্যথায় উল্লেখযোগ্য অপারেশনাল বিনিয়োগের প্রয়োজন হবে।

AWS, Azure, GCP, এবং বেয়ার মেটাল জুড়ে স্থাপনার ধরণগুলি একই মূল MongoDB কনফিগারেশন ভাগ করে। কি পরিবর্তন হয় স্টোরেজ ক্লাস, ব্যাকআপ গন্তব্য, এবং নেটওয়ার্কিং স্তর। এই সামঞ্জস্য হল একটি অপারেটর-ভিত্তিক পদ্ধতির মান: আপনার দল একটি টুল, একটি অপারেশনাল মডেল এবং এক সেট রানবুক শিখে যা সর্বত্র কাজ করে।

একটি তিন-সদস্যের রেপ্লিকা সেট দিয়ে শুরু করুন,w: majorityলিখেছেন, ক্রমাগত অপলগ সংরক্ষণাগার সহ একটি দৈনিক PBM ব্যাকআপ এবং প্রতিলিপি ল্যাগ, সংযোগ স্যাচুরেশন এবং ক্যাশে চাপের জন্য মূল Prometheus সতর্কতা। প্রথম দিনে আপনার ব্যর্থতা পরীক্ষা করুন - আপনার প্রথম ঘটনার সময় নয়। আপনার ডেটা ভলিউম এবং প্রাপ্যতার প্রয়োজনীয়তা বাড়ার সাথে সাথে শার্ডিং, জোন-ভিত্তিক ডেটা লোকেলিটি এবং বহু-অঞ্চল স্থাপনায় প্রসারিত করুন। অবকাঠামো যান্ত্রিকতা পরিচালনা করে; আপনার দায়িত্ব হল আর্কিটেকচারকে গভীরভাবে বোঝার জন্য আপনার কাজের চাপের জন্য সঠিক ট্রেড-অফ করতে এবং সেই অনুমানগুলিকে নিরলসভাবে পরীক্ষা করা।