MongoDB ความพร้อมใช้งานสูงในการผลิต: ชุดการจำลอง การแบ่งส่วน และตัวดำเนินการ Kubernetes

MongoDB ครองตำแหน่งที่ไม่ซ้ำกันในแนวนอนของฐานข้อมูล โมเดลเอกสารแมปกับออบเจ็กต์แอปพลิเคชันอย่างเป็นธรรมชาติ สคีมาที่ยืดหยุ่นรองรับโครงสร้างข้อมูลที่พัฒนาโดยไม่ต้องย้ายข้อมูล และการจำลองแบบในตัวและการแบ่งส่วนพื้นฐานให้รากฐานสำหรับความพร้อมใช้งานสูงและปรับขนาดแนวนอนที่ฐานข้อมูลเชิงสัมพันธ์ต้องใช้เครื่องมือภายนอกเพื่อให้บรรลุ แต่รากฐานไม่ใช่อาคารที่สร้างเสร็จ การใช้งาน MongoDB ในการผลิตด้วยความพร้อมใช้งานสูงของแท้ ในกรณีที่โหนดล้มเหลว พาร์ติชันเครือข่าย หรือทั้งภูมิภาคออฟไลน์ไม่ส่งผลให้เกิดการหยุดทำงานหรือการสูญเสียข้อมูล ต้องใช้สถาปัตยกรรมที่ตั้งใจ การปรับแต่งอย่างระมัดระวัง และความมีวินัยในการปฏิบัติงานที่เข้มงวด

คู่มือนี้จะอธิบายทุกเลเยอร์ของ MongoDB HA: ตั้งแต่โปรโตคอลฉันทามติชุดแบบจำลองและการจำลองแบบ oplog ที่ขับเคลื่อนระบบเมื่อเกิดข้อผิดพลาดอัตโนมัติ ผ่านสถาปัตยกรรมคลัสเตอร์แบบแบ่งส่วนที่ช่วยให้ปรับขนาดแนวนอนได้ ไปจนถึงตัวดำเนินการ Kubernetes ที่ทำให้การจัดการวงจรการใช้งานเป็นแบบอัตโนมัติ และทั่วทั้งตัวเลือกการใช้งานบน AWS, Azure, GCP และ Bare Metal k3s พร้อม Rancher ทุกส่วนประกอบด้วยการกำหนดค่าที่เป็นรูปธรรม รายการ YAML และขั้นตอนการปฏิบัติงานที่คุณสามารถปรับให้เข้ากับสภาพแวดล้อมของคุณได้

MongoDB

ชุดแบบจำลองคือหน่วยพื้นฐานของ MongoDB ที่มีความพร้อมใช้งานสูง เป็นกลุ่มของกระบวนการmongodที่รักษาชุดข้อมูลเดียวกัน สมาชิกหนึ่งรายคือหลักซึ่งรับการดำเนินการเขียนทั้งหมด สมาชิกที่เหลือคือตัวรองซึ่งจำลองข้อมูลจากสมาชิกหลักโดยปรับแต่งบันทึกการดำเนินการ (oplog) หากชุดหลักไม่พร้อมใช้งาน ชุดจำลองจะจัดการเลือกตั้งเพื่อเลือกชุดหลักใหม่จากชุดรองที่มีสิทธิ์ โดยปกติจะใช้เวลาภายใน 10 ถึง 12 วินาที

ชุดแบบจำลองการผลิตควรมีองค์ประกอบที่รองรับข้อมูลอย่างน้อยสามตัว โดยจะกระจายไปตามโดเมนความล้มเหลวที่แตกต่างกัน (โซนความพร้อมใช้งาน ชั้นวาง หรือศูนย์ข้อมูล) เพื่อให้แน่ใจว่าชุดแบบจำลองจะสามารถรอดพ้นจากการสูญเสียสมาชิกเพียงคนเดียวและยังคงรักษาเสียงข้างมากไว้เพื่อจุดประสงค์ในการเลือกตั้ง ตัวตัดสินซึ่งเป็นตัวเลือกเข้าร่วมในการเลือกตั้งแต่ไม่ได้เก็บข้อมูลไว้ — มันมีไว้เพื่อทำลายความสัมพันธ์เท่านั้นเมื่อคุณมีสมาชิกที่มีข้อมูลเป็นจำนวนคู่ แม้ว่าแนวทางปฏิบัติที่ดีที่สุดของ MongoDB คือการใช้สมาชิกที่มีข้อมูลเป็นจำนวนคี่แทน

Oplog และกลไกการจำลอง

oplog เป็นคอลเลกชันต่อยอด (local.oplog.rs) ที่บันทึกทุกการดำเนินการแก้ไขข้อมูลบนหลักในรูปแบบ idempotent รองติดตาม oplog ของหลักอย่างต่อเนื่องและใช้การดำเนินงานในเครื่อง ขนาดของ oplog จะกำหนดว่ารองจะตามหลังได้มากเพียงใดก่อนที่จะต้องมีการซิงค์ใหม่ทั้งหมด สำหรับปริมาณงานที่ใช้งานจริง ให้กำหนดขนาด oplog เพื่อรองรับกิจกรรมการเขียนอย่างน้อย 24 ถึง 72 ชั่วโมง MongoDB 4.4+ รองรับการกำหนดขนาด oplog แบบไดนามิกผ่านreplSetResizeOplog

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

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

# Check replication lag on secondaries
rs.printSecondaryReplicationInfo()

และพิธีสารที่ใช้แพ

MongoDB 4.0+ ใช้โปรโตคอลฉันทามติที่ได้รับแรงบันดาลใจจาก Raft สำหรับการเลือกตั้งชุดจำลอง เมื่อตัวรองตรวจพบว่าตัวหลักไม่สามารถเข้าถึงได้ (ค่าเริ่มต้นelectionTimeoutMillisที่ 10,000ms) ก็อาจเรียกการเลือกตั้ง หากต้องการชนะ ผู้สมัครจะต้องได้รับคะแนนเสียงจากเสียงข้างมากของสมาชิกที่มีสิทธิเลือกตั้ง สมาชิกที่มีรายการ oplog ล่าสุดและมีลำดับความสำคัญสูงสุดจะชนะหากมีผู้สมัครหลายคนมีสิทธิ์ คุณสามารถมีอิทธิพลต่อผลการเลือกตั้งได้โดยการกำหนดลำดับความสำคัญของสมาชิก สมาชิกที่มีpriority: 0ไม่สามารถกลายเป็นสมาชิกหลักได้ ซึ่งมีประโยชน์สำหรับแบบจำลองการวิเคราะห์หรือสมาชิกในพื้นที่ห่างไกล

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

# Check replica set status
rs.status()

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

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

อ่านการตั้งค่าและเขียนข้อกังวล

การตั้งค่าการอ่านควบคุมตำแหน่งที่ไดรเวอร์ส่งการดำเนินการอ่าน ตัวเลือกคือ:

• primary— การอ่านทั้งหมดไปที่หลัก ความสอดคล้องที่แข็งแกร่งที่สุดแต่ไม่มีการปรับขนาดการอ่าน
• primaryPreferred— การอ่านจะไปที่รายการหลัก เว้นแต่จะไม่พร้อมใช้งาน จากนั้นจึงไปที่รายการรอง
• secondary— การอ่านทั้งหมดไปที่ระดับรอง ให้มาตราส่วนการอ่าน แต่อาจส่งคืนข้อมูลเก่า
• secondaryPreferred— การอ่านไปที่ระดับรอง เว้นแต่ว่าไม่มีเลย
• nearest— การอ่านจะส่งไปยังสมาชิกที่มีเวลาแฝงของเครือข่ายต่ำที่สุดโดยไม่คำนึงถึงบทบาท ดีที่สุดสำหรับการปรับใช้แบบกระจายทางภูมิศาสตร์

ข้อกังวลในการเขียนควบคุมจำนวนสมาชิกชุดเรพลิกาที่ต้องรับทราบการเขียนก่อนที่การดำเนินการจะส่งคืนไปยังไคลเอนต์

• w: 1— เฉพาะรายการหลักเท่านั้นที่ต้องรับทราบ เร็วที่สุดแต่เสี่ยงต่อการสูญเสียข้อมูลหากระบบหลักล้มเหลวก่อนการจำลองแบบ
• w: "majority"— สมาชิกที่มีข้อมูลส่วนใหญ่ต้องรับทราบ นี่คือค่าเริ่มต้นการผลิตที่แนะนำ รับประกันว่าการเขียนจะรอดจากการเลือกตั้งขั้นต้น
• w: <number>— สมาชิกจำนวนหนึ่งต้องรับทราบ
• j: true— การเขียนจะต้องถูกส่งไปยังเจอร์นัลออนดิสก์ก่อนที่จะรับทราบ เมื่อใช้ร่วมกับw: "majority"จะรับประกันความทนทานสูงสุด

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

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

MongoDB สถาปัตยกรรมคลัสเตอร์แบบแบ่งส่วน

ชุดแบบจำลองมีความพร้อมใช้งานสูงแต่ไม่ได้ปรับขนาดการเขียนแนวนอน — การเขียนทั้งหมดไปที่หลักเดียว เมื่อชุดข้อมูลของคุณเกินความจุของเซิร์ฟเวอร์เดียวหรือปริมาณงานการเขียนของคุณเกินที่เซิร์ฟเวอร์หลักตัวใดตัวหนึ่งสามารถจัดการได้ คุณจะต้องมีการแบ่งส่วน คลัสเตอร์ที่แบ่งส่วนจะกระจายข้อมูลไปยังชุดแบบจำลอง (ชาร์ด) หลายชุดโดยใช้คีย์ชาร์ด ซึ่งช่วยให้สามารถขยายขนาดแนวนอนของทั้งพื้นที่จัดเก็บข้อมูลและปริมาณงานเขียนได้

คลัสเตอร์แบบแบ่งส่วนมีองค์ประกอบสามประเภท เราเตอร์mongosเป็นเราเตอร์แบบสอบถามไร้สัญชาติที่นำการดำเนินการของไคลเอ็นต์ไปยังชาร์ดที่เหมาะสม ปรับใช้อย่างน้อยสองรายการเพื่อความซ้ำซ้อนกำหนดค่าเซิร์ฟเวอร์สร้างชุดแบบจำลองที่จัดเก็บข้อมูลเมตาของคลัสเตอร์ ซึ่งชิ้นส่วนต่างๆ อาศัยอยู่บนชาร์ดใด ช่วงคีย์ชาร์ด และสถานะบาลานเซอร์ เซิร์ฟเวอร์​​Shardเป็นชุดแบบจำลองที่แต่ละชุดเก็บชุดย่อยของข้อมูลที่แบ่งส่วน

การเลือกชาร์ดคีย์

ชาร์ดคีย์คือการตัดสินใจที่เป็นผลสืบเนื่องมากที่สุดในคลัสเตอร์ที่แบ่งส่วน โดยจะกำหนดวิธีการกระจายข้อมูลข้ามส่วนต่างๆ และส่งผลโดยตรงต่อประสิทธิภาพของคิวรี การกระจายการเขียน และความสามารถในการปรับขนาด คีย์ชาร์ดที่ดีมีคาร์ดินัลลิตี้สูง (ค่าที่แตกต่างกันหลายค่า) กระจายการเขียนเท่าๆ กันทั่วทั้งชาร์ด และรองรับรูปแบบคิวรีทั่วไปที่มีการดำเนินการแบบกำหนดเป้าหมาย แทนที่จะรวบรวมแบบกระจาย

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

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

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

# Check shard distribution
db.orders.getShardDistribution()

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

ได้แก่: คีย์แฮชสำหรับการกระจายการเขียนแบบสม่ำเสมอ (ดีที่สุดเมื่อคุณไม่ต้องการการสืบค้นแบบช่วงบนคีย์ชาร์ด), คีย์ผสมที่รวมฟิลด์การจัดกลุ่มแบบหยาบเข้ากับฟิลด์ที่มีคาร์ดินัลลิตีสูง (เช่น{ tenant_id: 1, _id: 1 }สำหรับแอปพลิเคชันที่มีผู้เช่าหลายราย) และคีย์ตามโซนที่จัดตำแหน่งข้อมูลให้สอดคล้องกับภูมิภาคทางภูมิศาสตร์

Zone Sharding สำหรับหลายภูมิภาค

จะจำกัดช่วงเฉพาะของชาร์ดคีย์ไปยังชาร์ดเฉพาะ ทำให้สามารถใช้งานข้อมูลในพื้นที่ได้ ตัวอย่างเช่น คุณสามารถมั่นใจได้ว่าข้อมูลลูกค้าชาวยุโรปจะอยู่บนชาร์ดในภูมิภาคสหภาพยุโรป ในขณะที่ข้อมูลลูกค้าของสหรัฐอเมริกาจะอยู่บนชาร์ดในภูมิภาคสหรัฐอเมริกา

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

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

# Verify zone configuration
sh.status()

การปรับใช้ MongoDB หลายภูมิภาค

การกระจาย MongoDB ในหลายภูมิภาคมีจุดประสงค์สองประการ: การกู้คืนความเสียหาย (การเอาตัวรอดจากการสูญเสียทั้งภูมิภาค) และการปรับเวลาแฝงให้เหมาะสม (ให้บริการการอ่านจากแบบจำลองที่ใกล้ที่สุด) MongoDB รองรับการใช้งานหลายภูมิภาคผ่านสมาชิกชุดแบบจำลองที่กระจายไปตามภูมิภาค การแบ่งโซนสำหรับพื้นที่ข้อมูล และการกำหนดค่าการตั้งค่าการอ่านที่กำหนดเส้นทางการอ่านไปยังสมาชิกที่ใกล้ที่สุด

ในชุดแบบจำลองที่มีสมาชิกห้าคนซึ่งกระจายอยู่ในสามภูมิภาค (2 แห่งในภูมิภาคหลัก, 2 แห่งในภูมิภาค DR, 1 แห่งในภูมิภาคการอ่าน) การสูญเสียภูมิภาคหลักยังคงมีสมาชิกเหลืออยู่สามคน - เพียงพอสำหรับคนส่วนใหญ่ในการเลือกภูมิภาคหลักใหม่ สมาชิกในภูมิภาคการอ่านควรมีpriority: 0เพื่อป้องกันไม่ให้กลายเป็นสมาชิกหลัก (เวลาแฝงข้ามภูมิภาคที่สูงจะทำให้ประสิทธิภาพการเขียนลดลง) ใช้hidden: trueสำหรับสมาชิกเฉพาะด้านการวิเคราะห์ที่ไม่ควรได้รับการอ่านแอปพลิเคชันเป็นประจำ

MongoDB ชุมชน Kubernetes โอเปอเรเตอร์

ตัวดำเนินการ MongoDB Community Kubernetes ปรับใช้และจัดการชุดแบบจำลอง MongoDB บน Kubernetes เป็นโอเปอเรเตอร์โอเพ่นซอร์สจาก MongoDB Inc. ที่จัดการการจัดการ StatefulSet, การกำหนดค่าชุดแบบจำลองอัตโนมัติ, การหมุนเวียนใบรับรอง TLS, การจัดการผู้ใช้ และการอัปเกรดแบบต่อเนื่อง

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

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

MongoDBชุมชน CRD ข้อมูลจำเพาะ

ทรัพยากรที่กำหนดเองMongoDBCommunityกำหนดสถานะที่ต้องการของชุดแบบจำลอง MongoDB ด้านล่างนี้เป็นข้อมูลจำเพาะพร้อมการผลิต

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

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

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

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

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

ข้อมูลจำเพาะนี้สร้างชุดแบบจำลองสามสมาชิกที่ใช้ MongoDB 7.0 พร้อมการตรวจสอบสิทธิ์ SCRAM, การเข้ารหัส TLS, ข้อมูลและวอลุ่มบันทึกแยกกัน, การต่อต้านความสัมพันธ์ของพ็อดข้ามโซนความพร้อมใช้งาน และการปรับแต่ง WiredTiger ให้เหมาะสมกับโหนดที่มี RAM ขนาด 16 GB ตัวดำเนินการจัดการการเริ่มต้นชุดเรพลิกา การกำหนดค่าสมาชิก และการอัปเกรดแบบต่อเนื่องเมื่อคุณเปลี่ยนฟิลด์version

เซิร์ฟเวอร์ Percona สำหรับตัวดำเนินการ MongoDB

Percona Operator สำหรับ MongoDB (PSMDB Operator) มอบทางเลือกที่มีคุณลักษณะหลากหลายมากกว่า Community Operator โดยปรับใช้ Percona Server สำหรับ MongoDB (การแทนที่แบบดรอปอินสำหรับ MongoDB พร้อมฟีเจอร์ระดับองค์กรเพิ่มเติม) จัดการคลัสเตอร์ที่แบ่งส่วนและชุดแบบจำลอง รวมการสำรองข้อมูลผ่าน Percona Backup สำหรับ MongoDB (PBM) และรองรับการกู้คืน ณ เวลาใดเวลาหนึ่ง

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

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

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

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

  sharding:
    enabled: false

  mongos: {}
  configsrv: {}

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

  secrets:
    users: mongodb-users-secret

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

ข้อได้เปรียบหลักของ Percona Operator คือการจัดการการสำรองข้อมูลแบบผสานรวมกับ Percona Backup สำหรับ MongoDB (PBM) PBM รองรับการสำรองข้อมูลทั้งแบบลอจิคัลและฟิสิคัล การสำรองข้อมูลส่วนเพิ่ม และการกู้คืน ณ เวลาใดเวลาหนึ่งจาก oplog ซึ่งทั้งหมดได้รับการกำหนดค่าแบบเปิดเผยผ่าน CRD

AWS Deployment: DocumentDB กับ Atlas และ Self-Managed บน EKS

Amazon DocumentDBเป็นบริการฐานข้อมูลเอกสารที่เข้ากันได้กับ MongoDB ไม่ใช่ MongoDB — เป็นเครื่องมือที่เป็นกรรมสิทธิ์ซึ่งใช้โปรโตคอลสาย MongoDB (เข้ากันได้กับ MongoDB 4.0 API) DocumentDB แยกการประมวลผลออกจากพื้นที่จัดเก็บข้อมูลโดยใช้เลเยอร์พื้นที่จัดเก็บข้อมูลแบบกระจายที่คล้ายคลึงกับ Aurora โดยให้การเฟลโอเวอร์อัตโนมัติภายในภูมิภาค การจำลองการอ่านสูงสุด 15 รายการ และการกู้คืน ณ เวลาใดเวลาหนึ่ง อย่างไรก็ตาม ยังขาดคุณสมบัติ MongoDB มากมาย: สตรีมการเปลี่ยนแปลงมีข้อจำกัด ธุรกรรมทำงานแตกต่างออกไป และไม่รองรับขั้นตอนไปป์ไลน์การรวมหลายขั้นตอน ใช้ DocumentDB เฉพาะในกรณีที่แอปพลิเคชันของคุณใช้ชุดย่อยของ API ของ MongoDB และคุณให้ความสำคัญกับความเรียบง่ายในการดำเนินงานของบริการที่มีการจัดการเต็มรูปแบบ

MongoDB Atlas บน AWSเป็นบริการที่ได้รับการจัดการของ MongoDB ที่ทำงานบนโครงสร้างพื้นฐาน AWS โดยมอบ MongoDB ของแท้พร้อมคุณสมบัติทั้งหมด, HA อัตโนมัติ, การสำรองข้อมูลอย่างต่อเนื่อง, การกู้คืน ณ เวลาใดเวลาหนึ่ง, การปรับขนาดอัตโนมัติ และคลัสเตอร์หลายภูมิภาค Atlas เป็นเส้นทางที่ง่ายที่สุดในการผลิต MongoDB แต่เป็นตัวเลือกที่แพงที่สุดตามขนาด

จัดการด้วยตนเองบน EKSช่วยให้คุณควบคุมเวอร์ชัน MongoDB การกำหนดค่า และต้นทุนได้เต็มรูปแบบ ใช้ MongoDB Community Operator หรือ Percona Operator พร้อมพื้นที่จัดเก็บ EBS gp3 และบทบาท IAM สำหรับบัญชีบริการ (IRSA) เพื่อการเข้าถึงข้อมูลสำรอง S3 ที่ปลอดภัย

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

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

Azure Deployment: Cosmos DB กับ Atlas และ Self-Managed บน AKS

Azure Cosmos DB สำหรับ MongoDB (vCore)เป็น Azure Native ที่ใกล้เคียงที่สุดกับ MongoDB จริง ต่างจาก Cosmos DB API รุ่นเก่าที่ใช้ RU สำหรับ MongoDB รุ่น vCore รันอินสแตนซ์กลไก MongoDB จริงบนการประมวลผลเฉพาะ โดยให้ความเข้ากันได้สูงกับฟีเจอร์ MongoDB 6.0+ รวมถึงไปป์ไลน์การรวมแบบเต็ม สตรีมการเปลี่ยนแปลง และธุรกรรม มี HA ที่ซ้ำซ้อนแบบโซน การกู้คืนแบบ point-in-time และการสำรองข้อมูลอัตโนมัติ

MongoDB Atlas บน Azureมอบประสบการณ์ MongoDB ที่มีการจัดการเต็มรูปแบบเช่นเดียวกับบน AWS โดยทำงานบนโครงสร้างพื้นฐาน Azure พร้อม VNET peering, Azure Private Link และการบูรณาการ Azure AD

จัดการด้วยตนเองบน AKSใช้ดิสก์ที่ได้รับการจัดการ Azure (แนะนำ Premium SSD v2) พร้อมด้วยตัวดำเนินการ MongoDB หรือ Percona

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

GCP: Atlas บน GCP กับการจัดการด้วยตนเองบน GKE

MongoDB Atlas บน GCPทำงานบนโครงสร้างพื้นฐานของ Google Cloud พร้อมการผสานรวม GCP แบบเนทีฟ: การเพียร์ VPC, Private Service Connect และการผสานรวมคลัสเตอร์ GKE Atlas บน GCP รองรับคลัสเตอร์หลายภูมิภาคซึ่งครอบคลุมภูมิภาค GCP ด้วยการเฟลโอเวอร์อัตโนมัติ

จัดการด้วยตนเองบน GKEใช้ Persistent Disk SSD กับตัวดำเนินการ MongoDB หรือ Percona GKE Workload Identity ให้การตรวจสอบสิทธิ์แบบไม่ใช้คีย์ที่ปลอดภัยสำหรับการสำรองข้อมูลไปยัง GCS

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

Bare Metal k3s/Rancher พร้อมแตรยาว

สำหรับอธิปไตยของข้อมูล การปฏิบัติตามข้อกำหนด หรือการเพิ่มประสิทธิภาพต้นทุน MongoDB ทำงานอย่างมีประสิทธิภาพบน Bare Metal Kubernetes โดยใช้ k3s พร้อมด้วยการจัดการ Rancher และพื้นที่จัดเก็บแบบกระจาย Longhorn สถาปัตยกรรมนี้ช่วยลดการพึ่งพาผู้ให้บริการคลาวด์ในขณะที่ยังคงรักษารูปแบบการจัดการตามผู้ให้บริการแบบเดิม

ที่เก็บข้อมูล Longhorn สำหรับ MongoDB

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

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

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

XFS เหนือ ext4 สำหรับ MongoDB บน Linux ระบบจัดเก็บข้อมูล WiredTiger ของ MongoDB ได้รับประโยชน์จากรูปแบบการจัดสรรของ XFS โดยเฉพาะอย่างยิ่งสำหรับเจอร์นัลและไฟล์ข้อมูล การจำลองแบบสามทางของ Longhorn ให้ความซ้ำซ้อนในระดับเสียง นอกเหนือจากการทำซ้ำระดับชุดแบบจำลองของ MongoDB ทำให้คุณป้องกันในเชิงลึกจากความล้มเหลวในการจัดเก็บข้อมูล

MetalLB และบริการไร้หัว

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

ตัวดำเนินการ MongoDB สร้างบริการแบบไม่มีส่วนหัวซึ่งให้ชื่อ DNS ที่เสถียรแก่แต่ละพ็อด (mongo-0.mongo-svc.databases.svc.cluster.local) นี่เป็นสิ่งจำเป็นสำหรับการค้นพบสมาชิกชุดเรพพลิกา หากคุณต้องการการเข้าถึงจากภายนอก MetalLB จะกำหนด IP ที่กำหนดเส้นทางให้กับบริการ LoadBalancer ที่ด้านหน้าเราเตอร์ mongos (สำหรับคลัสเตอร์ที่แบ่งส่วน) หรือหลัก (สำหรับชุดแบบจำลอง)

กลยุทธ์การสำรองข้อมูล

MongoDB นำเสนอวิธีการสำรองข้อมูลที่หลากหลาย ซึ่งแต่ละวิธีเหมาะสมกับสถานการณ์ที่แตกต่างกัน

mongodump / mongorestore

การสำรองข้อมูลแบบลอจิคัลที่ส่งออกเอกสาร BSON พกพาสะดวกและมนุษย์ตรวจสอบได้ แต่ช้าสำหรับชุดข้อมูลขนาดใหญ่ และไม่รองรับการกู้คืน ณ เวลาใดเวลาหนึ่งด้วยตนเอง

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

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

การสำรองข้อมูล 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

การกู้คืนช่วงเวลาตาม Oplog

oplog เปิดใช้งานการกู้คืนแบบ point-in-time (PITR) เมื่อรวมกับการสำรองข้อมูลพื้นฐาน PBM เก็บถาวรรายการ oplog ไปยังที่จัดเก็บข้อมูลสำรองอย่างต่อเนื่อง หากต้องการกู้คืนไปยังจุดเวลาที่กำหนด PBM จะกู้คืนข้อมูลสำรองพื้นฐานล่าสุด จากนั้นเล่นซ้ำรายการ oplog จนถึงเวลาประทับเป้าหมาย สิ่งนี้ได้รับการกำหนดค่าใน Percona Operator CRD ผ่านทางส่วนpitr

สำหรับ HA

การกำหนดค่าสตริงการเชื่อมต่อที่เหมาะสมเป็นสิ่งสำคัญสำหรับความยืดหยุ่นของแอปพลิเคชันในระหว่างเหตุการณ์เฟลโอเวอร์

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

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

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

พารามิเตอร์สตริงการเชื่อมต่อคีย์สำหรับ HA:retryWrites=trueและretryReads=trueเปิดใช้งานการลองดำเนินการซ้ำอัตโนมัติที่ล้มเหลวระหว่างการเฟลโอเวอร์w=majorityช่วยให้มั่นใจได้ว่าการเขียนจะรอดจากการเลือกตั้งขั้นต้นserverSelectionTimeoutMSควบคุมระยะเวลาที่คนขับรอเพื่อค้นหาเซิร์ฟเวอร์ที่เหมาะสม โดยตั้งค่าให้สูงกว่าเวลาการเลือกตั้งที่คาดไว้ (อย่างน้อย 15 วินาที)maxPoolSizeจำกัดพูลการเชื่อมต่อต่อสมาชิกชุด mongos/replica เพื่อป้องกันการเชื่อมต่อหมด

และประสิทธิภาพการค้นหา

เป็นเครื่องมือหลักสำหรับประสิทธิภาพการค้นหา MongoDB ดัชนีที่ขาดหายไปในช่องที่มีการสืบค้นบ่อยครั้งจะบังคับให้มีการสแกนคอลเลกชันที่จะลดระดับลงเป็นเส้นตรงกับขนาดข้อมูล

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

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

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

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

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

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

ตรวจสอบ$indexStatsเป็นประจำเพื่อระบุดัชนีที่ไม่ได้ใช้ ซึ่งสิ้นเปลืองพื้นที่จัดเก็บและเขียนช้า ใช้เมธอดexplain()เพื่อตรวจสอบว่าเคียวรีใช้ดัชนีที่คาดไว้ และตรวจสอบtotalDocsExaminedที่สูงซึ่งสัมพันธ์กับnReturnedซึ่งบ่งชี้ถึงแผนการสืบค้นที่ไม่มีประสิทธิภาพ

WiredTiger การปรับแต่งเครื่องยนต์การจัดเก็บ

WiredTiger เป็นกลไกเริ่มต้นของ MongoDB และเป็นเพียงกลไกการจัดเก็บข้อมูลที่ใช้งานจริงเท่านั้นนับตั้งแต่ MongoDB 4.2 คุณลักษณะด้านประสิทธิภาพได้รับอิทธิพลอย่างมากจากขนาดแคช การบีบอัด และการกำหนดค่าเจอร์นัล

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

operationProfiling:
  mode: slowOp
  slowOpThresholdMs: 100

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

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

setParameter:
  wiredTigerConcurrentReadTransactions: 128
  wiredTigerConcurrentWriteTransactions: 128

แคช WiredTiger ควรมีขนาดเพื่อเก็บชุดการทำงานของคุณ — ข้อมูลและดัชนีที่แบบสอบถามของคุณเข้าถึงอย่างต่อเนื่อง หากแคชมีขนาดเล็กเกินไป WiredTiger จะไล่เพจออกบ่อยครั้ง ส่งผลให้ I/O สูง หากมีขนาดใหญ่เกินไป หน่วยความจำจะเหลือไม่เพียงพอสำหรับแคชระบบไฟล์ OS และกระบวนการอื่นๆ จุดเริ่มต้นคือ 50% ของ RAM ที่มีอยู่ลบ 1 GB (สำหรับระบบปฏิบัติการและกระบวนการอื่นๆ) โดยจำกัดไว้ที่ขนาดชุดการทำงาน

และการเข้ารหัส TLS

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

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

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

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

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

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

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

security:
  authorization: enabled
  clusterAuthMode: x509

ด้วย Prometheus และ Grafana

MongoDB เปิดเผยหน่วยเมตริกผ่านmongodb_exporter(จาก Percona) ที่ผสานรวมกับ Prometheus ตัววัดหลักที่ต้องตรวจสอบ ได้แก่ จำนวนการเชื่อมต่อ อัตราการดำเนินการ ความล่าช้าในการจำลอง การใช้แคช WiredTiger และประสิทธิภาพการกำหนดเป้าหมายแบบสอบถาม

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

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

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

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

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

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

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

เปลี่ยนสตรีมสำหรับแอปพลิเคชันแบบเรียลไทม์

Change streams มีกลไกการแจ้งเตือนแบบเรียลไทม์สำหรับการเปลี่ยนแปลงข้อมูลใน MongoDB พวกเขาใช้ประโยชน์จาก oplog เพื่อผลักดันเหตุการณ์การเปลี่ยนแปลงไปยังแอปพลิเคชัน เปิดใช้งานสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ แดชบอร์ดแบบเรียลไทม์ และไปป์ไลน์การซิงโครไนซ์ข้อมูลโดยไม่ต้องสำรวจ

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

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

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

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

สตรีมการเปลี่ยนแปลงจำเป็นต้องมีชุดเรพลิกาหรือคลัสเตอร์ที่แบ่งส่วน (ไม่ทำงานบนอินสแตนซ์ mongod แบบสแตนด์อโลน) พวกเขารอดจากการเลือกตั้งขั้นต้น — คนขับจะเชื่อมต่ออีกครั้งโดยอัตโนมัติและดำเนินการต่อจากโทเค็นประวัติย่อที่ได้รับครั้งล่าสุด สำหรับการใช้งานจริง ให้คงโทเค็นประวัติการทำงานไว้เสมอ เพื่อให้แอปพลิเคชันของคุณสามารถกู้คืนจากการรีสตาร์ทได้โดยไม่พลาดเหตุการณ์

การบำรุงรักษาแบบโรลลิ่งและการอัพเกรดเวอร์ชัน

MongoDB รองรับการอัปเกรดแบบต่อเนื่องโดยที่คุณอัปเกรดสมาชิกชุดแบบจำลองทีละรายการ โดยเริ่มจากสมาชิกชุดรองและสิ้นสุดด้วยสมาชิกหลัก (ซึ่งจะทำให้เกิดการลดขั้นตอนและการเลือก) ซึ่งช่วยให้สามารถอัปเกรดการหยุดทำงานเป็นศูนย์สำหรับการเปลี่ยนแปลงเวอร์ชันรองและเวอร์ชันหลัก

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

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

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

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

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

ด้วย MongoDB Community Operator หรือ Percona Operator บน Kubernetes การอัปเกรดแบบต่อเนื่องจะดำเนินการโดยอัตโนมัติ คุณเพียงอัปเดตฟิลด์versionใน CRD และผู้ปฏิบัติงานจะจัดการการอัปเดตแบบทีละส่วนของแต่ละพ็อด โดยรอให้สมาชิกแต่ละคนมีสุขภาพแข็งแรงก่อนดำเนินการต่อ

การกู้คืนความเสียหายและการทดสอบความล้มเหลว

การปรับใช้ความพร้อมใช้งานสูงที่ไม่เคยได้รับการทดสอบภายใต้ความล้มเหลวนั้นยังไม่ผ่านการทดสอบ การทดสอบเฟลโอเวอร์เป็นประจำจะตรวจสอบสถาปัตยกรรมของคุณ การแจ้งเตือนการตรวจสอบ และขั้นตอนการตอบสนองเหตุการณ์ของทีมของคุณ

การทดสอบเฟลโอเวอร์ที่ควบคุม

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

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

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

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

สิ่งที่ต้องวัดระหว่างการเฟลโอเวอร์

• RTO (วัตถุประสงค์เวลาการกู้คืน)— เวลาตั้งแต่ความล้มเหลวหลักไปจนถึงการยอมรับการเขียนหลักใหม่ เป้าหมาย: ต่ำกว่า 30 วินาทีสำหรับชุดแบบจำลอง
• RPO (วัตถุประสงค์จุดการกู้คืน)— ข้อมูลสูญหายระหว่างการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด ด้วยw: majorityRPO จะเป็นศูนย์สำหรับการเขียนที่ได้รับการยอมรับ ด้วยw: 1RPO จะเท่ากับความล่าช้าในการจำลอง ณ เวลาที่เกิดความล้มเหลว
• อัตราข้อผิดพลาดของแอปพลิเคชัน— เปอร์เซ็นต์ของคำขอที่ล้มเหลวในระหว่างกรอบเวลาเฟลโอเวอร์ ด้วยretryWrites=trueความล้มเหลวในการเขียนส่วนใหญ่จะถูกลองใหม่โดยอัตโนมัติโดยไดรเวอร์
• เปลี่ยนความต่อเนื่องของสตรีม— ตรวจสอบว่าผู้ใช้สตรีมที่เปลี่ยนแปลงกลับมาดำเนินการต่อจากโทเค็นที่บันทึกไว้โดยไม่พลาดกิจกรรม

คู่มือการกู้คืนความเสียหาย

1. สมาชิกเดี่ยวล้มเหลว— การกู้คืนอัตโนมัติผ่านการรีสตาร์ทพ็อด Kubernetes และการติดตามผล oplog ไม่จำเป็นต้องดำเนินการใดๆ เว้นแต่สมาชิกต้องการการซิงค์อีกครั้งโดยสมบูรณ์
2. ความล้มเหลวหลัก— การเลือกตั้งอัตโนมัติเลื่อนระดับรองภายใน 10-12 วินาที ตรวจสอบการเชื่อมต่อแอปพลิเคชันและความล่าช้าในการจำลองข้อมูลในรองที่เหลือ
3. ส่วนใหญ่ล้มเหลว— หากสมาชิกส่วนใหญ่ไม่ทำงาน ชุดแบบจำลองจะกลายเป็นแบบอ่านอย่างเดียว (ไม่สามารถเลือกได้) กู้คืนสมาชิกหรือใช้rs.reconfig({ force: true })เป็นทางเลือกสุดท้าย (ซึ่งอาจทำให้ข้อมูลสูญหายได้)
4. การสูญเสียคลัสเตอร์โดยสมบูรณ์— ปรับใช้คลัสเตอร์ใหม่ กู้คืนจากการสำรองข้อมูล PBM ล่าสุด และเล่นซ้ำ oplog ไปยังจุดเป้าหมายในเวลา อัปเดตสตริงการเชื่อมต่อและบันทึก 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: 50% ของ RAM ที่มีอยู่ ลบ 1 GB หรือขนาดของชุดการทำงานของคุณ แล้วแต่จำนวนใดจะเล็กกว่า
• Oplog ขนาด: เพียงพอสำหรับการดำเนินการเขียน 24-72 ชั่วโมง เริ่มต้นด้วย 50 GB และมอนิเตอร์ด้วยrs.printReplicationInfo()
• Storage IOPS: MongoDB เน้น I/O โดยเฉพาะในระหว่างการบดอัดและจุดตรวจสอบ ใช้ NVMe SSD หรือที่เก็บข้อมูลบนคลาวด์ที่มี IOPS ที่จัดเตรียมไว้ (gp3 ที่มี 6000+ IOPS บน AWS, Premium SSD v2 บน Azure, pd-ssd บน GCP)
• CPU: MongoDB ได้รับประโยชน์จากหลายคอร์สำหรับการดำเนินการอ่าน/เขียนพร้อมกัน ธุรกรรมที่เกิดขึ้นพร้อมกันของ WiredTiger และงานเบื้องหลัง (จุดตรวจสอบ การบีบอัดข้อมูล การจำลองแบบ)
• Network: การรับส่งข้อมูลการจำลองอาจมีความสำคัญสำหรับเวิร์กโหลดที่เขียนข้อมูลจำนวนมาก ตรวจสอบให้แน่ใจว่าเครือข่ายแบนด์วิธสูงมีเวลาแฝงต่ำระหว่างสมาชิกชุดเรพลิกา

การจัดการการเชื่อมต่อ

# 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 วินาที
• ความอิ่มตัวของการเชื่อมต่อ— แจ้งเตือนเมื่อการเชื่อมต่อปัจจุบันเกิน 80% ของmaxIncomingConnections
• แคช WiredTiger— แจ้งเตือนเมื่ออัตราส่วนการเติมแคชสกปรกเกิน 20% (บ่งชี้ถึงแรงกดดันในการเขียนเกินปริมาณงานของจุดตรวจสอบ)
• หน้าต่าง Oplog— แจ้งเตือนเมื่อหน้าต่าง oplog ลดลงต่ำกว่า 12 ชั่วโมง (ความเสี่ยงของตัวรองที่ต้องซิงค์ใหม่อีกครั้งหลังการบำรุงรักษา)
• การค้นหาเป้าหมาย— แจ้งเตือนเมื่ออัตราส่วนของเอกสารที่สแกนต่อเอกสารที่ส่งคืนเกิน 100 (ดัชนีหายไป)
• การใช้ดิสก์— แจ้งเตือนที่เกณฑ์ 70% และ 85% MongoDB สามารถใช้พื้นที่ดิสก์ชั่วคราวจำนวนมากระหว่างการบีบอัด
• ความใหม่ของการสำรองข้อมูล— แจ้งเตือนเมื่อการสำรองข้อมูลสำเร็จครั้งล่าสุดเก่ากว่าหน้าต่าง RPO ของคุณ
• ความพร้อมใช้งานของตั๋ว— ตรวจสอบตั๋วการอ่านและเขียน WiredTiger ความอ่อนล้าทำให้เกิดการเข้าคิวการดำเนินการและเวลาแฝงที่เพิ่มขึ้นอย่างรวดเร็ว

คำสั่งปฏิบัติการ อ้างอิงด่วน

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

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

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

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

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

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

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

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

Decision Matrix: การเลือกสถาปัตยกรรม MongoDB HA ของคุณ

• คลาวด์เดี่ยว, การตั้งค่าการจัดการ— ใช้ MongoDB Atlas โดยจะจัดการ HA การสำรองข้อมูล การตรวจสอบ และการปรับขนาดโดยมีค่าใช้จ่ายในการดำเนินงานน้อยที่สุด
• AWS ที่รองรับ MongoDB ต้องการเพียง— พิจารณา Amazon DocumentDB หากแอปพลิเคชันของคุณใช้ชุดย่อยพื้นฐานของ MongoDB API และคุณต้องการประสบการณ์ที่มีการจัดการเต็มรูปแบบ มิฉะนั้น Atlas หรือจัดการด้วยตนเองบน EKS
• Azure พร้อมคุณสมบัติ MongoDB เต็มรูปแบบ— ใช้ Cosmos DB สำหรับ MongoDB vCore สำหรับประสบการณ์ที่มีการจัดการ หรือใช้ Atlas บน Azure สำหรับบริการที่ได้รับการจัดการ MongoDB ของแท้
• มัลติคลาวด์หรือไฮบริด— จัดการด้วยตนเองด้วย MongoDB Community Operator หรือ Percona Operator Kubernetes abstraction ช่วยให้สามารถใช้งานผู้ให้บริการต่างๆ ได้อย่างสอดคล้องกัน
• โลหะเปลือยหรือขอบ— k3s + Rancher + Longhorn + MongoDB Community Operator หรือ Percona Operator ไม่จำเป็นต้องพึ่งพาระบบคลาวด์
• การปรับขนาดแนวนอนขนาดใหญ่— คลัสเตอร์แบบแบ่งส่วนพร้อมการแบ่งโซนสำหรับพื้นที่ข้อมูล ใช้ Percona Operator ที่รองรับการใช้งานแบบแบ่งส่วนโดยกำเนิด
• แอปพลิเคชันที่ขับเคลื่อนด้วยเหตุการณ์แบบเรียลไทม์— สตรีมการเปลี่ยนแปลง MongoDB มี CDC ในตัว ตรวจสอบให้แน่ใจว่าคุณใช้ชุดเรพลิกาหรือคลัสเตอร์ที่แบ่งส่วน (ไม่ใช่แบบสแตนด์อโลน)

สรุป

MongoDB ให้ความได้เปรียบทางสถาปัตยกรรมเพื่อความพร้อมใช้งานสูง ชุดแบบจำลองที่มีระบบเฟลโอเวอร์อัตโนมัติและคลัสเตอร์แบบแบ่งส่วนที่มีการปรับขนาดแนวนอนเป็นความสามารถดั้งเดิม ไม่มีการยึดติดในภายหลัง แต่พื้นฐานเหล่านี้ต้องได้รับการกำหนดค่าอย่างถูกต้องและดำเนินการอย่างมีระเบียบวินัยเพื่อรับประกันความพร้อมใช้งานที่ระบบการผลิตต้องการ

การใช้งาน MongoDB ที่ใช้งานจริงต้องใช้สมาชิกชุดแบบจำลองที่มีข้อมูลสามชุดทั่วทั้งโดเมนที่ล้มเหลวw: majorityเขียนข้อกังวลเรื่องความทนทาน การกำหนดขนาด oplog ที่เหมาะสมสำหรับความยืดหยุ่นในการจำลองแบบ การปรับแต่งแคช WiredTiger สำหรับชุดการทำงานของคุณ และกลยุทธ์การสำรองข้อมูลที่ผ่านการทดสอบพร้อมความสามารถในการกู้คืนแบบจุดต่อเวลา ตัวดำเนินการ Kubernetes ไม่ว่าจะเป็น MongoDB Community Operator สำหรับชุดแบบจำลองหรือ Percona Operator สำหรับการปรับใช้ที่มีคุณสมบัติครบถ้วน รวมถึงการแบ่งส่วนข้อมูลและการสำรองข้อมูลแบบรวม จะทำให้การจัดการวงจรการทำงานเป็นไปโดยอัตโนมัติ ซึ่งหากอย่างอื่นอาจต้องใช้การลงทุนในการดำเนินงานจำนวนมาก

รูปแบบการใช้งานทั้ง AWS, Azure, GCP และ Bare Metal มีการกำหนดค่า MongoDB หลักเหมือนกัน สิ่งที่เปลี่ยนแปลงคือคลาสพื้นที่จัดเก็บข้อมูล ปลายทางการสำรองข้อมูล และเลเยอร์เครือข่าย ความสม่ำเสมอนี้คือคุณค่าของแนวทางที่อิงจากผู้ปฏิบัติงาน: ทีมของคุณเรียนรู้เครื่องมือหนึ่งชิ้น โมเดลการปฏิบัติงานหนึ่งชุด และชุดการดำเนินการหนึ่งชุดที่ทำงานได้ทุกที่

เริ่มต้นด้วยชุดแบบจำลองสามสมาชิก, การเขียนw: majority, การสำรองข้อมูล PBM รายวันพร้อมการเก็บถาวร oplog อย่างต่อเนื่อง และการแจ้งเตือน Prometheus หลักสำหรับความล่าช้าในการจำลอง ความอิ่มตัวของการเชื่อมต่อ และความดันแคช ทดสอบการเฟลโอเวอร์ของคุณในวันแรก ไม่ใช่ในเหตุการณ์แรก ขยายไปสู่การแบ่งส่วน ท้องถิ่นของข้อมูลตามโซน และการปรับใช้หลายภูมิภาค เมื่อความต้องการปริมาณข้อมูลและความพร้อมใช้งานของคุณเพิ่มขึ้น โครงสร้างพื้นฐานรองรับกลไก ความรับผิดชอบของคุณคือการทำความเข้าใจสถาปัตยกรรมอย่างลึกซึ้งพอที่จะทำให้เกิดการแลกเปลี่ยนที่เหมาะสมสำหรับปริมาณงานของคุณและทดสอบสมมติฐานเหล่านั้นอย่างไม่ลดละ