Loading blog...

MongoDB ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ: ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ, ਸ਼ਾਰਡਿੰਗ, ਅਤੇ Kubernetes ਆਪਰੇਟਰ

MongoDB HA ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ, ਸ਼ਾਰਡਿੰਗ, ਅਤੇ Kubernetes ਆਪਰੇਟਰਾਂ ਨਾਲ

Balinder Walia12 ਅਪ੍ਰੈਲ 202633 min read

MongoDB ਡੇਟਾਬੇਸ ਲੈਂਡਸਕੇਪ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ ਸਥਿਤੀ ਰੱਖਦਾ ਹੈ। ਇਸ ਦਾ ਦਸਤਾਵੇਜ਼ ਮਾਡਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਆਬਜੈਕਟਸ ਲਈ ਨਕਸ਼ੇ ਬਣਾਉਂਦਾ ਹੈ, ਇਸਦਾ ਲਚਕਦਾਰ ਸਕੀਮਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੇ ਬਿਨਾਂ ਵਿਕਾਸਸ਼ੀਲ ਡੇਟਾ ਢਾਂਚੇ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਬਿਲਟ-ਇਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਸ਼ਾਰਡਿੰਗ ਪ੍ਰਾਈਮਿਟਿਵ ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਲਈ ਇੱਕ ਬੁਨਿਆਦ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਕਿ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬਾਹਰੀ ਟੂਲਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪਰ ਇੱਕ ਨੀਂਹ ਇੱਕ ਮੁਕੰਮਲ ਇਮਾਰਤ ਨਹੀਂ ਹੈ. ਅਸਲ ਉੱਚ ਉਪਲਬਧਤਾ ਦੇ ਨਾਲ ਉਤਪਾਦਨ ਵਿੱਚ MongoDB ਨੂੰ ਚਲਾਉਣਾ — ਜਿੱਥੇ ਇੱਕ ਨੋਡ ਅਸਫਲਤਾ, ਇੱਕ ਨੈੱਟਵਰਕ ਭਾਗ, ਜਾਂ ਇੱਕ ਪੂਰਾ ਖੇਤਰ ਔਫਲਾਈਨ ਹੋਣ ਦਾ ਨਤੀਜਾ ਡਾਊਨਟਾਈਮ ਜਾਂ ਡਾਟਾ ਖਰਾਬ ਨਹੀਂ ਹੁੰਦਾ — ਜਾਣਬੁੱਝ ਕੇ ਆਰਕੀਟੈਕਚਰ, ਧਿਆਨ ਨਾਲ ਟਿਊਨਿੰਗ, ਅਤੇ ਸਖ਼ਤ ਸੰਚਾਲਨ ਅਨੁਸ਼ਾਸਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ।

ਇਹ ਗਾਈਡ MongoDB HA ਦੀ ਹਰ ਪਰਤ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ: ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਸਹਿਮਤੀ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਓਪਲੌਗ ਰੀਪਲੀਕੇਸ਼ਨ ਤੋਂ ਜੋ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਨੂੰ ਪਾਵਰ ਦਿੰਦੀ ਹੈ, ਸ਼ਾਰਡਡ ਕਲੱਸਟਰ ਆਰਕੀਟੈਕਚਰ ਦੁਆਰਾ ਜੋ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੀ ਹੈ, Kubernetes ਓਪਰੇਟਰਾਂ ਤੱਕ ਜੋ ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਬੰਧਨ ਨੂੰ ਆਟੋਮੈਟਿਕ ਕਰਦੇ ਹਨ, ਅਤੇ XPRX5 ਅਤੇ ਮੈਟਲ ਐਕਸਪੀਆਰਐਕਸ 5 ਵਿਕਲਪਾਂ 'ਤੇ ਤੈਨਾਤੀ ਕਰਦੇ ਹਨ। ਰੈਂਚਰ ਨਾਲ k3s। ਹਰੇਕ ਭਾਗ ਵਿੱਚ ਠੋਸ ਸੰਰਚਨਾ, YAML ਪ੍ਰਗਟਾਵੇ, ਅਤੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਵਾਤਾਵਰਣ ਦੇ ਅਨੁਕੂਲ ਬਣਾ ਸਕਦੇ ਹੋ।

MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਆਰਕੀਟੈਕਚਰ

ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ MongoDB ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਦੀ ਬੁਨਿਆਦੀ ਇਕਾਈ ਹੈ। ਇਹmongodਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਇੱਕੋ ਡੇਟਾ ਸੈੱਟ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਮੈਂਬਰਪ੍ਰਾਇਮਰੀਹੈ, ਜੋ ਸਾਰੇ ਲਿਖਣ ਕਾਰਜਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਬਾਕੀ ਬਚੇ ਮੈਂਬਰਸੈਕੰਡਰੀਹਨ, ਜੋ ਪ੍ਰਾਇਮਰੀ ਤੋਂ ਡੇਟਾ ਨੂੰ ਇਸਦੇ ਓਪਰੇਸ਼ਨ ਲੌਗ (ਓਪਲੌਗ) ਨੂੰ ਟੇਲ ਕਰਕੇ ਦੁਹਰਾਉਂਦੇ ਹਨ। ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਯੋਗ ਸੈਕੰਡਰੀ ਵਿੱਚੋਂ ਇੱਕ ਨਵਾਂ ਪ੍ਰਾਇਮਰੀ ਚੁਣਨ ਲਈ ਚੋਣ ਕਰਦਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ 10 ਤੋਂ 12 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ।

ਇੱਕ ਉਤਪਾਦਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਡਾਟਾ-ਬੇਅਰਿੰਗ ਮੈਂਬਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਅਸਫਲਤਾ ਡੋਮੇਨਾਂ (ਉਪਲਬਧਤਾ ਜ਼ੋਨ, ਰੈਕ, ਜਾਂ ਡਾਟਾ ਸੈਂਟਰ) ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਹਨ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਕਿਸੇ ਵੀ ਮੈਂਬਰ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਚੋਣ ਉਦੇਸ਼ਾਂ ਲਈ ਬਹੁਮਤ ਕਾਇਮ ਰੱਖ ਸਕਦਾ ਹੈ। ਇੱਕ ਵਿਕਲਪਿਕਆਰਬਿਟਰਚੋਣਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਂਦਾ ਹੈ ਪਰ ਕੋਈ ਡਾਟਾ ਨਹੀਂ ਰੱਖਦਾ — ਇਹ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਸਬੰਧਾਂ ਨੂੰ ਤੋੜਨ ਲਈ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਡੇਟਾ-ਬੇਅਰਿੰਗ ਮੈਂਬਰਾਂ ਦੀ ਇੱਕ ਬਰਾਬਰ ਸੰਖਿਆ ਹੁੰਦੀ ਹੈ, ਹਾਲਾਂਕਿ MongoDB ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਇਸ ਦੀ ਬਜਾਏ ਡਾਟਾ-ਬੇਅਰਿੰਗ ਮੈਂਬਰਾਂ ਦੀ ਇੱਕ ਅਜੀਬ ਸੰਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ।

ਓਪਲੌਗ ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ ਮਕੈਨਿਕਸ

ਓਪਲੌਗ ਇੱਕ ਕੈਪਡ ਸੰਗ੍ਰਹਿ (local.oplog.rs) ਹੈ ਜੋ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਹਰ ਡਾਟਾ-ਸੋਧਣ ਵਾਲੇ ਓਪਰੇਸ਼ਨ ਨੂੰ ਅਯੋਗ ਰੂਪ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। ਸੈਕੰਡਰੀ ਪ੍ਰਾਇਮਰੀ ਦੇ ਓਪਲੌਗ ਨੂੰ ਲਗਾਤਾਰ ਟੇਲ ਕਰਦੇ ਹਨ ਅਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਓਪਰੇਸ਼ਨ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਓਪਲੌਗ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਸੈਕੰਡਰੀ ਨੂੰ ਪੂਰੀ ਰੀ-ਸਿੰਕ ਦੀ ਲੋੜ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨੀ ਪਿੱਛੇ ਰਹਿ ਸਕਦੀ ਹੈ — ਉਤਪਾਦਨ ਦੇ ਵਰਕਲੋਡ ਲਈ, ਲਿਖਣ ਦੀ ਗਤੀਵਿਧੀ ਦੇ ਘੱਟੋ-ਘੱਟ 24 ਤੋਂ 72 ਘੰਟੇ ਰੱਖਣ ਲਈ ਓਪਲੌਗ ਦਾ ਆਕਾਰ ਦਿਓ। MongoDB 4.4+replSetResizeOplogਰਾਹੀਂ ਡਾਇਨਾਮਿਕ ਓਪਲੌਗ ਸਾਈਜ਼ਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

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

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

# Check replication lag on secondaries
rs.printSecondaryReplicationInfo()

ਚੋਣਾਂ ਅਤੇ ਰਾਫਟ-ਅਧਾਰਿਤ ਪ੍ਰੋਟੋਕੋਲ

MongoDB 4.0+ ਰਿਪਲੀਕਾ ਸੈੱਟ ਚੋਣਾਂ ਲਈ ਇੱਕ ਰਾਫਟ-ਪ੍ਰੇਰਿਤ ਸਹਿਮਤੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਸੈਕੰਡਰੀ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਾਇਮਰੀ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ (10,000ms ਦਾ ਡਿਫੌਲਟelectionTimeoutMillis), ਤਾਂ ਇਹ ਚੋਣ ਬੁਲਾ ਸਕਦਾ ਹੈ। ਜਿੱਤਣ ਲਈ, ਇੱਕ ਉਮੀਦਵਾਰ ਨੂੰ ਬਹੁਮਤ ਵੋਟਿੰਗ ਮੈਂਬਰਾਂ ਤੋਂ ਵੋਟਾਂ ਪ੍ਰਾਪਤ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਓਪਲੌਗ ਐਂਟਰੀ ਵਾਲਾ ਮੈਂਬਰ ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਜਿੱਤਦਾ ਹੈ ਜੇਕਰ ਕਈ ਉਮੀਦਵਾਰ ਯੋਗ ਹਨ। ਤੁਸੀਂ ਮੈਂਬਰ ਤਰਜੀਹਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਕੇ ਚੋਣ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹੋ —priority: 0ਵਾਲਾ ਮੈਂਬਰ ਕਦੇ ਵੀ ਪ੍ਰਾਇਮਰੀ ਨਹੀਂ ਬਣ ਸਕਦਾ, ਜੋ ਕਿ ਰਿਮੋਟ ਖੇਤਰਾਂ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜਾਂ ਮੈਂਬਰਾਂ ਲਈ ਉਪਯੋਗੀ ਹੈ।

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

# Check replica set status
rs.status()

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

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

ਤਰਜੀਹ ਪੜ੍ਹੋ ਅਤੇ ਚਿੰਤਾ ਲਿਖੋ

ਰੀਡ ਪ੍ਰੈਫਰੈਂਸਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਡਰਾਈਵਰ ਰੀਡ ਓਪਰੇਸ਼ਨ ਭੇਜਦਾ ਹੈ। ਵਿਕਲਪ ਹਨ:

primary— ਸਾਰੇ ਰੀਡ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਪਰ ਕੋਈ ਰੀਡ ਸਕੇਲਿੰਗ ਨਹੀਂ।
primaryPreferred— ਰੀਡਜ਼ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਇਹ ਉਪਲਬਧ ਨਾ ਹੋਵੇ, ਫਿਰ ਸੈਕੰਡਰੀ ਵਿੱਚ।
secondary— ਸਾਰੇ ਰੀਡ ਸੈਕੰਡਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਰੀਡ ਸਕੇਲਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ ਪੁਰਾਣਾ ਡਾਟਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ।
secondaryPreferred— ਰੀਡਜ਼ ਸੈਕੰਡਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਵੀ ਉਪਲਬਧ ਨਾ ਹੋਵੇ।
nearest— ਰੀਡਜ਼ ਭੂਮਿਕਾ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਸਭ ਤੋਂ ਘੱਟ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਵਾਲੇ ਮੈਂਬਰ ਨੂੰ ਜਾਂਦੇ ਹਨ। ਭੂ-ਵਿਤਰਿਤ ਤੈਨਾਤੀਆਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ।

Write Concernਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇਟ ਨੂੰ ਓਪਰੇਸ਼ਨ ਵਾਪਸ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਮੈਂਬਰਾਂ ਨੂੰ ਲਿਖਤ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

w: 1— ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਪਰ ਡਾਟਾ ਖਰਾਬ ਹੋਣ ਦਾ ਖਤਰਾ ਹੈ ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ।
w: "majority"— ਡਾਟਾ-ਬੇਅਰਿੰਗ ਮੈਂਬਰਾਂ ਦੀ ਬਹੁਗਿਣਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਿਫ਼ਾਰਸ਼ੀ ਉਤਪਾਦਨ ਮੂਲ ਹੈ। ਇਹ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਲਿਖਤ ਪ੍ਰਾਇਮਰੀ ਚੋਣ ਤੋਂ ਬਚੀ ਰਹੇਗੀ।
w: <number>— ਮੈਂਬਰਾਂ ਦੀ ਇੱਕ ਖਾਸ ਗਿਣਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
j: true— ਰਸੀਦ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਤ ਆਨ-ਡਿਸਕ ਜਰਨਲ ਲਈ ਵਚਨਬੱਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।w: "majority"ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਇਹ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਟਿਕਾਊਤਾ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

MongoDB ਸ਼ਾਰਡਡ ਕਲੱਸਟਰ ਆਰਕੀਟੈਕਚਰ

ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਉੱਚ ਉਪਲਬਧਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ ਹਰੀਜੱਟਲ ਰਾਈਟ ਸਕੇਲਿੰਗ ਨਹੀਂ — ਸਾਰੀਆਂ ਲਿਖਤਾਂ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਡੇਟਾ ਸੈੱਟ ਇੱਕ ਸਿੰਗਲ ਸਰਵਰ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ ਜਾਂ ਤੁਹਾਡਾ ਲਿਖਣ ਦਾ ਥ੍ਰੋਪੁੱਟ ਉਸ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ ਜੋ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਹੈਂਡਲ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਸ਼ਾਰਡਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸ਼ਾਰਡ ਕਲੱਸਟਰ ਇੱਕ ਸ਼ਾਰਡ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਮਲਟੀਪਲ ਰਿਪਲੀਕਾ ਸੈੱਟਾਂ (ਸ਼ਾਰਡਸ) ਵਿੱਚ ਡਾਟਾ ਵੰਡਦਾ ਹੈ, ਸਟੋਰੇਜ ਅਤੇ ਰਾਈਟ ਥ੍ਰੁਪੁੱਟ ਦੋਵਾਂ ਦੀ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਕ ਕੱਟੇ ਹੋਏ ਕਲੱਸਟਰ ਵਿੱਚ ਤਿੰਨ ਭਾਗ ਕਿਸਮਾਂ ਹਨ।mongosਰਾਊਟਰ ਸਟੇਟਲੈੱਸ ਕਿਊਰੀ ਰਾਊਟਰ ਹਨ ਜੋ ਕਿ ਕਲਾਇੰਟ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਉਚਿਤ ਸ਼ਾਰਡਾਂ ਤੱਕ ਨਿਰਦੇਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਰਿਡੰਡੈਂਸੀ ਲਈ ਘੱਟੋ-ਘੱਟ ਦੋ ਤੈਨਾਤ ਕਰੋ।ਕੌਂਫਿਗ ਸਰਵਰਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਕਲੱਸਟਰ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ — ਜੋ ਕਿ ਕਿਹੜੇ ਸ਼ਾਰਡ, ਸ਼ਾਰਡ ਕੁੰਜੀ ਰੇਂਜਾਂ, ਅਤੇ ਬੈਲੇਂਸਰ ਸਥਿਤੀ 'ਤੇ ਰਹਿੰਦੇ ਹਨ।ਸ਼ਾਰਡ ਸਰਵਰਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਹਨ ਜੋ ਹਰ ਇੱਕ ਸ਼ਾਰਡਡ ਡੇਟਾ ਦਾ ਸਬਸੈੱਟ ਰੱਖਦਾ ਹੈ।

ਸ਼ਾਰਡ ਕੁੰਜੀ ਚੋਣ

ਸ਼ਾਰਡ ਕੁੰਜੀ ਇੱਕ ਸ਼ਾਰਡ ਕਲੱਸਟਰ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਨਤੀਜੇ ਵਾਲਾ ਫੈਸਲਾ ਹੈ। ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾ ਨੂੰ ਸ਼ਾਰਡਾਂ ਵਿੱਚ ਕਿਵੇਂ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪੁੱਛਗਿੱਛ ਪ੍ਰਦਰਸ਼ਨ, ਲਿਖਣ ਦੀ ਵੰਡ, ਅਤੇ ਸਕੇਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਇੱਕ ਚੰਗੀ ਸ਼ਾਰਡ ਕੁੰਜੀ ਵਿੱਚ ਉੱਚ ਮੁੱਖਤਾ (ਬਹੁਤ ਸਾਰੇ ਵੱਖਰੇ ਮੁੱਲ) ਹੁੰਦੇ ਹਨ, ਸ਼ਾਰਡਾਂ ਵਿੱਚ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਲਿਖਤਾਂ ਨੂੰ ਵੰਡਦਾ ਹੈ, ਅਤੇ ਸਕੈਟਰ-ਗੈਦਰ ਦੀ ਬਜਾਏ ਟਾਰਗੇਟ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਸਭ ਤੋਂ ਆਮ ਪੁੱਛਗਿੱਛ ਪੈਟਰਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

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

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

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

# Check shard distribution
db.orders.getShardDistribution()

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

ਆਮ ਸ਼ਾਰਡ ਕੁੰਜੀ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਇਕਸਾਰ ਲਿਖਣ ਦੀ ਵੰਡ ਲਈਹੈਸ਼ਡ ਕੁੰਜੀਆਂ(ਵਧੀਆ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸ਼ਾਰਡ ਕੁੰਜੀ 'ਤੇ ਰੇਂਜ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ),ਕੰਪਾਊਂਡ ਕੁੰਜੀਆਂਜੋ ਇੱਕ ਮੋਟੇ ਗਰੁੱਪਿੰਗ ਫੀਲਡ ਨੂੰ ਇੱਕ ਉੱਚ-ਕਾਰਡੀਨਲ ਫੀਲਡ, ਲਈ ਜੋੜਦੀਆਂ ਹਨ। ਐਪਲੀਕੇਸ਼ਨਾਂ), ਅਤੇਜ਼ੋਨ-ਅਧਾਰਿਤ ਕੁੰਜੀਆਂਜੋ ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਨਾਲ ਡੇਟਾ ਪਲੇਸਮੈਂਟ ਨੂੰ ਇਕਸਾਰ ਕਰਦੀਆਂ ਹਨ।

ਬਹੁ-ਖੇਤਰਲਈ

ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ

ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ ਖਾਸ ਸ਼ਾਰਡਾਂ ਲਈ ਸ਼ਾਰਡ ਕੁੰਜੀ ਦੀਆਂ ਖਾਸ ਰੇਂਜਾਂ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਡਾਟਾ ਸਥਾਨਿਕਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਯੂਰਪੀਅਨ ਗਾਹਕ ਡੇਟਾ ਈਯੂ ਖੇਤਰ ਵਿੱਚ ਸ਼ਾਰਡਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਯੂਐਸ ਗਾਹਕ ਡੇਟਾ ਯੂਐਸ ਖੇਤਰ ਵਿੱਚ ਸ਼ਾਰਡਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ।

# 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, DR ਖੇਤਰ ਵਿੱਚ 2, ਰੀਡ ਖੇਤਰ ਵਿੱਚ 1) ਵਿੱਚ ਵੰਡੇ ਗਏ ਇੱਕ ਪੰਜ-ਮੈਂਬਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਵਿੱਚ, ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਦੇ ਨੁਕਸਾਨ ਨਾਲ ਅਜੇ ਵੀ ਤਿੰਨ ਮੈਂਬਰ ਉਪਲਬਧ ਹਨ — ਇੱਕ ਨਵਾਂ ਪ੍ਰਾਇਮਰੀ ਚੁਣਨ ਲਈ ਬਹੁਮਤ ਲਈ ਕਾਫ਼ੀ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ ਰੀਡ ਖੇਤਰ ਦੇ ਮੈਂਬਰ ਕੋਲpriority: 0ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉੱਚ ਅੰਤਰ-ਖੇਤਰ ਲੇਟੈਂਸੀ ਲਿਖਣ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਘਟਾ ਦੇਵੇਗੀ)। ਵਿਸ਼ਲੇਸ਼ਣ-ਸਮਰਪਿਤ ਮੈਂਬਰਾਂ ਲਈhidden: trueਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਿਯਮਤ ਐਪਲੀਕੇਸ਼ਨ ਰੀਡ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ।

MongoDB ਕਮਿਊਨਿਟੀ Kubernetes ਆਪਰੇਟਰ

MongoDB ਕਮਿਊਨਿਟੀ Kubernetes ਆਪਰੇਟਰ Kubernetes 'ਤੇ MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ ਨੂੰ ਤੈਨਾਤ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਇਹ MongoDB Inc. ਦਾ ਓਪਨ-ਸੋਰਸ ਆਪਰੇਟਰ ਹੈ ਜੋ ਸਟੇਟਫੁਲਸੈੱਟ ਪ੍ਰਬੰਧਨ, ਸਵੈਚਲਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਕੌਂਫਿਗਰੇਸ਼ਨ, TLS ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ, ਉਪਭੋਗਤਾ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਰੋਲਿੰਗ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

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

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

MongoDBਕਮਿਊਨਿਟੀ CRD ਨਿਰਧਾਰਨ

MongoDBCommunityਕਸਟਮ ਸਰੋਤ ਇੱਕ MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਦੀ ਲੋੜੀਦੀ ਸਥਿਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਉਤਪਾਦਨ-ਤਿਆਰ ਨਿਰਧਾਰਨ ਹੈ।

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

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

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

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

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

ਇਹ ਨਿਰਧਾਰਨ SCRAM ਪ੍ਰਮਾਣਿਕਤਾ, TLS ਐਨਕ੍ਰਿਪਸ਼ਨ, ਵੱਖਰਾ ਡੇਟਾ ਅਤੇ ਲੌਗ ਵਾਲੀਅਮ, ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਪੌਡ ਐਂਟੀ-ਐਫੀਨਿਟੀ, ਅਤੇ 16 GB RAM ਵਾਲੇ ਨੋਡ ਲਈ ਉਚਿਤ ਵਾਇਰਡਟਾਈਗਰ ਟਿਊਨਿੰਗ ਦੇ ਨਾਲ MongoDB 7.0 ਨੂੰ ਚਲਾਉਣ ਵਾਲਾ ਇੱਕ ਤਿੰਨ-ਮੈਂਬਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂversionਫੀਲਡ ਨੂੰ ਬਦਲਦੇ ਹੋ ਤਾਂ ਓਪਰੇਟਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਦੀ ਸ਼ੁਰੂਆਤ, ਮੈਂਬਰ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਰੋਲਿੰਗ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

MongoDB ਆਪਰੇਟਰਲਈ

ਪਰਕੋਨਾ ਸਰਵਰ

MongoDB (PSMDB ਆਪਰੇਟਰ) ਲਈ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਲਈ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ਤਾ-ਅਮੀਰ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ MongoDB (ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ MongoDB ਲਈ ਇੱਕ ਡ੍ਰੌਪ-ਇਨ ਰਿਪਲੇਸਮੈਂਟ) ਲਈ ਪਰਕੋਨਾ ਸਰਵਰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ, ਸ਼ਾਰਡਡ ਕਲੱਸਟਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, MongoDB (PBM) ਲਈ ਪਰਕੋਨਾ ਬੈਕਅੱਪ ਦੁਆਰਾ ਬੈਕਅੱਪ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

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

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

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

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

  sharding:
    enabled: false

  mongos: {}
  configsrv: {}

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

  secrets:
    users: mongodb-users-secret

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

ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਦਾ ਮੁੱਖ ਫਾਇਦਾ MongoDB (PBM) ਲਈ ਪਰਕੋਨਾ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਇਸਦਾ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਹੈ। PBM ਲਾਜ਼ੀਕਲ ਅਤੇ ਭੌਤਿਕ ਬੈਕਅੱਪ, ਵਾਧੇ ਵਾਲੇ ਬੈਕਅੱਪ, ਅਤੇ ਔਪਲੌਗ ਤੋਂ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ - ਇਹ ਸਭ CRD ਦੁਆਰਾ ਘੋਸ਼ਣਾਤਮਕ ਤੌਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤੇ ਗਏ ਹਨ।

AWS ਤੈਨਾਤੀ: DocumentDB ਬਨਾਮ ਐਟਲਸ ਬਨਾਮ EKS

'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ

Amazon DocumentDBਇੱਕ MongoDB-ਅਨੁਕੂਲ ਦਸਤਾਵੇਜ਼ ਡਾਟਾਬੇਸ ਸੇਵਾ ਹੈ। ਇਹ MongoDB ਨਹੀਂ ਹੈ - ਇਹ ਇੱਕ ਮਲਕੀਅਤ ਵਾਲਾ ਇੰਜਣ ਹੈ ਜੋ MongoDB ਵਾਇਰ ਪ੍ਰੋਟੋਕੋਲ (MongoDB 4.0 API ਤੱਕ ਅਨੁਕੂਲ) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। DocumentDB Aurora ਦੇ ਸਮਾਨ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਟੋਰੇਜ਼ ਲੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗਣਨਾ ਨੂੰ ਸਟੋਰੇਜ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, 15 ਤੱਕ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ। ਹਾਲਾਂਕਿ, ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ MongoDB ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਘਾਟ ਹੈ: ਪਰਿਵਰਤਨ ਸਟ੍ਰੀਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ, ਲੈਣ-ਦੇਣ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਏਕੀਕਰਣ ਪਾਈਪਲਾਈਨ ਪੜਾਅ ਅਸਮਰਥਿਤ ਹਨ। DocumentDB ਦੀ ਵਰਤੋਂ ਤਾਂ ਹੀ ਕਰੋ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ MongoDB ਦੇ API ਦੇ ਸਬਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਦੀ ਕਾਰਜਸ਼ੀਲ ਸਾਦਗੀ ਦੀ ਕਦਰ ਕਰਦੇ ਹੋ।

AWS'ਤੇ

MongoDB ਐਟਲਸ AWS ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਚੱਲ ਰਹੀ MongoDB ਦੀ ਆਪਣੀ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਹੈ। ਇਹ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਸਵੈਚਲਿਤ HA, ਨਿਰੰਤਰ ਬੈਕਅਪ, ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਆਟੋ-ਸਕੇਲਿੰਗ, ਅਤੇ ਮਲਟੀ-ਰੀਜਨ ਕਲੱਸਟਰਾਂ ਦੇ ਨਾਲ ਅਸਲੀ MongoDB ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਐਟਲਸ MongoDB ਉਤਪਾਦਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਹੈ ਪਰ ਪੈਮਾਨੇ 'ਤੇ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਵਿਕਲਪ ਹੈ।

EKS'ਤੇ

ਸਵੈ-ਪ੍ਰਬੰਧਿਤ ਤੁਹਾਨੂੰ MongoDB ਸੰਸਕਰਣ, ਸੰਰਚਨਾ, ਅਤੇ ਲਾਗਤ 'ਤੇ ਪੂਰਾ ਕੰਟਰੋਲ ਦਿੰਦਾ ਹੈ। ਸੁਰੱਖਿਅਤ S3 ਬੈਕਅੱਪ ਐਕਸੈਸ ਲਈ EBS gp3 ਸਟੋਰੇਜ ਅਤੇ IAM ਰੋਲਜ਼ ਫਾਰ ਸਰਵਿਸ ਅਕਾਉਂਟਸ (IRSA) ਦੇ ਨਾਲ MongoDB ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਜਾਂ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।

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

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

Azure ਤੈਨਾਤੀ: AKS

'ਤੇ Cosmos DB ਬਨਾਮ ਐਟਲਸ ਬਨਾਮ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ
MongoDB (vCore)ਲਈ Azure Cosmos DB ਅਸਲ MongoDB ਲਈ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ Azure ਮੂਲ ਪੇਸ਼ਕਸ਼ ਹੈ। MongoDB ਲਈ ਪੁਰਾਣੇ RU-ਅਧਾਰਿਤ Cosmos DB API ਦੇ ਉਲਟ, vCore ਮਾਡਲ ਸਮਰਪਿਤ ਕੰਪਿਊਟ 'ਤੇ ਅਸਲ MongoDB ਇੰਜਣ ਉਦਾਹਰਨਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, MongoDB 6.0+ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਉੱਚ ਅਨੁਕੂਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪੂਰੀ ਐਗਰੀਗੇਸ਼ਨ ਪਾਈਪਲਾਈਨ, ਸਟ੍ਰੀਮ ਬਦਲਣਾ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸ਼ਾਮਲ ਹਨ। ਇਹ ਜ਼ੋਨ-ਰਿਡੰਡੈਂਟ HA, ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।
Azure'ਤੇMongoDB ਐਟਲਸ AWS ਵਾਂਗ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ MongoDB ਅਨੁਭਵ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, Azure ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ VNET ਪੀਅਰਿੰਗ, Azure ਪ੍ਰਾਈਵੇਟ ਲਿੰਕ, ਅਤੇ Azure AD ਏਕੀਕਰਣ ਨਾਲ ਚੱਲਦਾ ਹੈ।
AKS'ਤੇ

ਸਵੈ-ਪ੍ਰਬੰਧਿਤ MongoDB ਜਾਂ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਨਾਲ Azure ਪ੍ਰਬੰਧਿਤ ਡਿਸਕਾਂ (ਪ੍ਰੀਮੀਅਮ SSD v2 ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

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

GCP ਤੈਨਾਤੀ: ਐਟਲਸ on GCP ਬਨਾਮ GKE

'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ
MongoDB ਐਟਲਸ GCP'ਤੇ GCP-ਨੇਟਿਵ ਏਕੀਕਰਣਾਂ ਦੇ ਨਾਲ Google ਕਲਾਉਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਚੱਲਦਾ ਹੈ: VPC ਪੀਅਰਿੰਗ, ਪ੍ਰਾਈਵੇਟ ਸਰਵਿਸ ਕਨੈਕਟ, ਅਤੇ GKE ਕਲੱਸਟਰ ਏਕੀਕਰਣ। GCP ਉੱਤੇ ਐਟਲਸ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਦੇ ਨਾਲ GCP ਖੇਤਰਾਂ ਵਿੱਚ ਫੈਲੇ ਬਹੁ-ਖੇਤਰ ਕਲੱਸਟਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
GKE'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ MongoDB ਜਾਂ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਨਾਲ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ SSD ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। GKE ਵਰਕਲੋਡ ਆਈਡੈਂਟਿਟੀ GCS ਵਿੱਚ ਬੈਕਅੱਪ ਲਈ ਸੁਰੱਖਿਅਤ, ਕੁੰਜੀ ਰਹਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
# GKE SSD StorageClass apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: pd-ssd-mongodb provisioner: pd.csi.storage.gke.io parameters: type: pd-ssd volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true reclaimPolicy: Retain
ਲੌਂਗਹੋਰਨਦੇ ਨਾਲ
ਬੇਅਰ ਮੈਟਲ k3s/ਰੈਂਚਰ
ਡੇਟਾ ਸੰਪ੍ਰਭੂਤਾ, ਪਾਲਣਾ, ਜਾਂ ਲਾਗਤ ਅਨੁਕੂਲਨ ਲਈ, MongoDB ਰੈਂਚਰ ਪ੍ਰਬੰਧਨ ਅਤੇ ਲੋਂਗਹੋਰਨ ਵੰਡੀ ਸਟੋਰੇਜ ਦੇ ਨਾਲ k3s ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਬੇਅਰ ਮੈਟਲ Kubernetes 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਚੱਲਦਾ ਹੈ। ਇਹ ਆਰਕੀਟੈਕਚਰ ਉਸੇ ਆਪਰੇਟਰ-ਅਧਾਰਿਤ ਪ੍ਰਬੰਧਨ ਮਾਡਲ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਨਿਰਭਰਤਾ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।
MongoDB
ਲਈ
ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ
# Install Longhorn helm repo add longhorn https://charts.longhorn.io helm repo update helm install longhorn longhorn/longhorn \ --namespace longhorn-system \ --create-namespace \ --set defaultSettings.defaultReplicaCount=3 \ --set defaultSettings.storageMinimalAvailablePercentage=15 # StorageClass for MongoDB on Longhorn apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: longhorn-mongo provisioner: driver.longhorn.io parameters: numberOfReplicas: "3" staleReplicaTimeout: "2880" dataLocality: best-effort fsType: xfs volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true reclaimPolicy: Retain
XFS ਦੀ ਲੀਨਕਸ ਉੱਤੇ MongoDB ਲਈ ext4 ਉੱਤੇ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। 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 ਮੋਂਗੋਸ ਰਾਊਟਰਾਂ (ਸ਼ਰਡਡ ਕਲੱਸਟਰਾਂ ਲਈ) ਜਾਂ ਪ੍ਰਾਇਮਰੀ (ਰਿਪਲੀਕਾ ਸੈੱਟਾਂ ਲਈ) ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਲੋਡਬੈਲੈਂਸਰ ਸੇਵਾ ਨੂੰ ਇੱਕ ਰੂਟੇਬਲ IP ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।
ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ
MongoDB ਕਈ ਬੈਕਅੱਪ ਪਹੁੰਚਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਹਰੇਕ ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਲਈ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ।
ਮੋਂਗੋਡੰਪ / ਮੋਂਗੋਰਸਟੋਰ
ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਜੋ BSON ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਨਿਰਯਾਤ ਕਰਦੇ ਹਨ। ਪੋਰਟੇਬਲ ਅਤੇ ਮਨੁੱਖੀ-ਨਿਰੀਖਣਯੋਗ, ਪਰ ਵੱਡੇ ਡੇਟਾਸੈਟਾਂ ਲਈ ਹੌਲੀ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ।
# Full logical backup with oplog for consistency mongodump --uri="mongodb://backup-user:password@mongo-0:27017,mongo-1:27017,mongo-2:27017/appdb?replicaSet=rs-production&authSource=admin" \ --oplog \ --gzip \ --out=/backups/$(date +%Y%m%d-%H%M%S) # Restore mongorestore --uri="mongodb://admin:password@mongo-0:27017/?replicaSet=rs-production&authSource=admin" \ --oplogReplay \ --gzip \ /backups/20260412-030000/
MongoDB (PBM)ਲਈ
ਪਰਕੋਨਾ ਬੈਕਅੱਪ
PBM ਭੌਤਿਕ ਬੈਕਅੱਪ, ਵਾਧੇ ਵਾਲੇ ਬੈਕਅੱਪ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਉਤਪਾਦਨ ਵਿੱਚ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ MongoDB ਲਈ ਸਿਫ਼ਾਰਸ਼ੀ ਬੈਕਅੱਪ ਟੂਲ ਹੈ।
# Configure PBM storage pbm config --set storage.type=s3 \ --set storage.s3.bucket=company-mongodb-backups \ --set storage.s3.region=us-east-1 \ --set storage.s3.credentials.access-key-id=$AWS_ACCESS_KEY \ --set storage.s3.credentials.secret-access-key=$AWS_SECRET_KEY # Full backup pbm backup --type=logical --compression=gzip # Physical backup (faster, requires WiredTiger) pbm backup --type=physical --compression=gzip # Incremental backup pbm backup --type=incremental --base-snapshot=2026-04-12T03:00:00Z # Point-in-time recovery pbm restore --time="2026-04-12T09:30:00Z" # List backups pbm list # Check backup status pbm status
ਕਲਾਊਡ ਸਨੈਪਸ਼ਾਟ
ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ, EBS ਸਨੈਪਸ਼ਾਟ (AWS), ਪ੍ਰਬੰਧਿਤ ਡਿਸਕ ਸਨੈਪਸ਼ਾਟ (Azure), ਅਤੇ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ ਸਨੈਪਸ਼ਾਟ (GCP) ਤੇਜ਼, ਸਟੋਰੇਜ-ਪੱਧਰ ਦਾ ਬੈਕਅੱਪ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਇਕਸਾਰਤਾ ਲਈdb.fsyncLock()ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਉਹ ਵੱਡੇ ਡੇਟਾਸੈਟਾਂ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਬੈਕਅਪ ਅਤੇ ਰੀਸਟੋਰ ਸਮੇਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ।
# Kubernetes VolumeSnapshot for MongoDB apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: mongodb-snapshot-$(date +%Y%m%d) namespace: databases spec: volumeSnapshotClassName: csi-snapclass source: persistentVolumeClaimName: data-volume-production-mongodb-0
ਓਪਲੌਗ-ਅਧਾਰਿਤ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ
ਬੇਸ ਬੈਕਅਪ ਨਾਲ ਜੋੜਨ 'ਤੇ ਓਪਲੌਗ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। PBM ਲਗਾਤਾਰ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਲਈ ਓਪਲੌਗ ਐਂਟਰੀਆਂ ਨੂੰ ਪੁਰਾਲੇਖ ਬਣਾਉਂਦਾ ਹੈ। ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਖਾਸ ਬਿੰਦੂ ਤੱਕ ਰੀਸਟੋਰ ਕਰਨ ਲਈ, PBM ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਬੇਸ ਬੈਕਅੱਪ ਨੂੰ ਰੀਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਟਾਰਗੇਟ ਟਾਈਮਸਟੈਂਪ ਤੱਕ ਓਪਲੌਗ ਐਂਟਰੀਆਂ ਨੂੰ ਰੀਪਲੇਅ ਕਰਦਾ ਹੈ। ਇਹ ਪਰਕੋਨਾ ਓਪਰੇਟਰ 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ਕੁਨੈਕਸ਼ਨ ਦੀ ਥਕਾਵਟ ਨੂੰ ਰੋਕਣ ਲਈ ਪ੍ਰਤੀ ਮੋਂਗੋਸ/ਰਿਪਲੀਕਾ ਸੈੱਟ ਮੈਂਬਰ ਕਨੈਕਸ਼ਨ ਪੂਲ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।
ਇੰਡੈਕਸ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਅਤੇ ਪੁੱਛਗਿੱਛ ਪ੍ਰਦਰਸ਼ਨ
ਸੂਚਕਾਂਕ 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 ਫਾਈਲ ਸਿਸਟਮ ਕੈਸ਼ ਅਤੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਨਾਕਾਫ਼ੀ ਮੈਮੋਰੀ ਛੱਡਦਾ ਹੈ। ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਉਪਲਬਧ ਰੈਮ ਦਾ 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
Prometheus ਅਤੇ Grafanaਨਾਲ
ਨਿਗਰਾਨੀ
MongoDBmongodb_exporter(ਪਰਕੋਨਾ ਤੋਂ) ਦੁਆਰਾ ਮੈਟ੍ਰਿਕਸ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ ਜੋ Prometheus ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ। ਮਾਨੀਟਰ ਕਰਨ ਲਈ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਦੀ ਗਿਣਤੀ, ਸੰਚਾਲਨ ਦਰਾਂ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲੇਗ, ਵਾਇਰਡਟਾਈਗਰ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ, ਅਤੇ ਪੁੱਛਗਿੱਛ ਨਿਸ਼ਾਨਾ ਕੁਸ਼ਲਤਾ ਸ਼ਾਮਲ ਹੈ।
# Deploy mongodb_exporter as a sidecar or standalone apiVersion: apps/v1 kind: Deployment metadata: name: mongodb-exporter namespace: databases spec: replicas: 1 selector: matchLabels: app: mongodb-exporter template: metadata: labels: app: mongodb-exporter annotations: prometheus.io/scrape: "true" prometheus.io/port: "9216" spec: containers: - name: exporter image: percona/mongodb_exporter:0.40.0 args: - --mongodb.uri=mongodb://monitoring:password@production-mongodb-0.production-mongodb-svc:27017,production-mongodb-1.production-mongodb-svc:27017,production-mongodb-2.production-mongodb-svc:27017/?replicaSet=rs-production&authSource=admin - --collect-all - --compatible-mode ports: - containerPort: 9216 resources: requests: cpu: 100m memory: 128Mi
# ServiceMonitor for Prometheus Operator apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: mongodb-metrics namespace: databases labels: release: kube-prometheus-stack spec: selector: matchLabels: app: mongodb-exporter endpoints: - port: metrics interval: 15s scrapeTimeout: 10s
# Critical Prometheus alert rules for MongoDB apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: mongodb-alerts namespace: databases labels: release: kube-prometheus-stack spec: groups: - name: mongodb-health rules: - alert: MongoDBReplicationLagHigh expr: mongodb_mongod_replset_member_replication_lag > 30 for: 5m labels: severity: warning annotations: summary: "MongoDB replica {{ $labels.name }} lag exceeds 30s" - alert: MongoDBConnectionsHigh expr: mongodb_connections{state="current"} / mongodb_connections{state="available"} > 0.8 for: 2m labels: severity: critical annotations: summary: "MongoDB connections above 80% capacity" - alert: MongoDBWiredTigerCacheEvictions expr: rate(mongodb_wiredtiger_cache_evicted_pages_total[5m]) > 100 for: 10m labels: severity: warning annotations: summary: "High WiredTiger cache eviction rate" - alert: MongoDBReplicaSetNoPrimary expr: mongodb_mongod_replset_number_of_members{state="PRIMARY"} == 0 for: 1m labels: severity: critical annotations: summary: "MongoDB replica set has no primary" - alert: MongoDBQueryTargetingInefficient expr: rate(mongodb_mongod_metrics_query_executor_total{state="scanned_objects"}[5m]) / rate(mongodb_mongod_metrics_query_executor_total{state="returned"}[5m]) > 100 for: 15m labels: severity: warning annotations: summary: "MongoDB scanning 100x more documents than returned"
ਰੀਅਲ-ਟਾਈਮ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਟ੍ਰੀਮ ਬਦਲੋ
ਚੇਂਜ ਸਟ੍ਰੀਮ MongoDB ਵਿੱਚ ਡੇਟਾ ਤਬਦੀਲੀਆਂ ਲਈ ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਲਈ, ਇਵੈਂਟ-ਸੰਚਾਲਿਤ ਆਰਕੀਟੈਕਚਰ, ਰੀਅਲ-ਟਾਈਮ ਡੈਸ਼ਬੋਰਡਸ, ਅਤੇ ਬਿਨਾਂ ਪੋਲਿੰਗ ਦੇ ਡੇਟਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਓਪਲੌਗ ਦਾ ਲਾਭ ਲੈਂਦੇ ਹਨ।
// Watch changes on a collection const pipeline = [ { $match: { operationType: { $in: ["insert", "update", "replace"] } } }, { $match: { "fullDocument.status": "active" } } ]; const changeStream = db.collection("orders").watch(pipeline, { fullDocument: "updateLookup", // include full document on updates resumeAfter: resumeToken // resume from last processed event }); changeStream.on("change", (change) => { console.log("Change detected:", change.operationType); console.log("Document:", change.fullDocument); // Store resume token for crash recovery saveResumeToken(change._id); }); changeStream.on("error", (error) => { console.error("Change stream error:", error); // Reconnect using saved resume token });
ਚੇਂਜ ਸਟ੍ਰੀਮਾਂ ਲਈ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਜਾਂ ਸ਼ਾਰਡ ਕਲੱਸਟਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਉਹ ਸਟੈਂਡਅਲੋਨ ਮੋਂਗੌਡ ਉਦਾਹਰਨਾਂ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰਦੇ)। ਉਹ ਪ੍ਰਾਇਮਰੀ ਚੋਣਾਂ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹਨ — ਡਰਾਈਵਰ ਆਪਣੇ ਆਪ ਮੁੜ ਕਨੈਕਟ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਆਖਰੀ ਪ੍ਰਾਪਤ ਹੋਏ ਰੈਜ਼ਿਊਮੇ ਟੋਕਨ ਤੋਂ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਉਤਪਾਦਨ ਦੀ ਵਰਤੋਂ ਲਈ, ਹਮੇਸ਼ਾ ਰੈਜ਼ਿਊਮੇ ਟੋਕਨ ਨੂੰ ਜਾਰੀ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਗੁੰਮ ਇਵੈਂਟਾਂ ਤੋਂ ਬਿਨਾਂ ਰੀਸਟਾਰਟ ਤੋਂ ਰਿਕਵਰ ਹੋ ਸਕੇ।
ਰੋਲਿੰਗ ਮੇਨਟੇਨੈਂਸ ਅਤੇ ਵਰਜਨ ਅੱਪਗਰੇਡ
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ਦੇ ਨਾਲ, ਆਰਪੀਓ ਅਸਫਲਤਾ ਦੇ ਸਮੇਂ ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ ਦੇ ਬਰਾਬਰ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਗਲਤੀ ਦਰ— ਫੇਲਓਵਰ ਵਿੰਡੋ ਦੌਰਾਨ ਅਸਫਲ ਹੋਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ।retryWrites=trueਦੇ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਲਿਖਣ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਡਰਾਈਵਰ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਸਟ੍ਰੀਮ ਨਿਰੰਤਰਤਾ ਨੂੰ ਬਦਲੋ— ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤਬਦੀਲੀ ਸਟ੍ਰੀਮ ਉਪਭੋਗਤਾ ਆਪਣੇ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਟੋਕਨ ਤੋਂ ਗੁੰਮ ਇਵੈਂਟਾਂ ਤੋਂ ਬਿਨਾਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ।
ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਰਨਬੁੱਕ
ਸਿੰਗਲ ਮੈਂਬਰ ਅਸਫਲਤਾ— Kubernetes ਪੌਡ ਰੀਸਟਾਰਟ ਅਤੇ ਓਪਲੌਗ ਕੈਚ-ਅੱਪ ਦੁਆਰਾ ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ। ਕਿਸੇ ਮੈਨੂਅਲ ਐਕਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਜਦੋਂ ਤੱਕ ਮੈਂਬਰ ਨੂੰ ਪੂਰੀ ਰੀਸਿੰਕ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।
ਪ੍ਰਾਇਮਰੀ ਅਸਫਲਤਾ— ਆਟੋਮੈਟਿਕ ਚੋਣ 10-12 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਸੈਕੰਡਰੀ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਬਾਕੀ ਬਚੀਆਂ ਸੈਕੰਡਰੀ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਪਛੜਾਈ ਕਰੋ।
ਬਹੁਮਤ ਅਸਫਲਤਾ— ਜੇਕਰ ਬਹੁਗਿਣਤੀ ਮੈਂਬਰ ਘੱਟ ਹਨ, ਤਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਬਣ ਜਾਂਦਾ ਹੈ (ਕੋਈ ਚੋਣਾਂ ਸੰਭਵ ਨਹੀਂ)। ਮੈਂਬਰਾਂ ਨੂੰ ਰੀਸਟੋਰ ਕਰੋ ਜਾਂ ਆਖਰੀ ਉਪਾਅ ਵਜੋਂrs.reconfig({ force: true })ਦੀ ਵਰਤੋਂ ਕਰੋ (ਇਸ ਨਾਲ ਡੇਟਾ ਦਾ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ)।
ਕਲੱਸਟਰ ਦਾ ਸੰਪੂਰਨ ਨੁਕਸਾਨ— ਇੱਕ ਨਵਾਂ ਕਲੱਸਟਰ ਤੈਨਾਤ ਕਰੋ, ਨਵੀਨਤਮ PBM ਬੈਕਅੱਪ ਤੋਂ ਰੀਸਟੋਰ ਕਰੋ, ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਟਾਰਗੇਟ ਪੁਆਇੰਟ 'ਤੇ ਓਪਲੌਗ ਨੂੰ ਰੀਪਲੇ ਕਰੋ। ਕਨੈਕਸ਼ਨ ਸਤਰ ਅਤੇ DNS ਰਿਕਾਰਡ ਅੱਪਡੇਟ ਕਰੋ।
ਖੇਤਰੀ ਫੇਲਓਵਰ— ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਗੁਆਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਵਿੱਚ ਸੈਕੰਡਰੀ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਪ੍ਰਾਇਮਰੀ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ (ਜੇ ਇਸ ਕੋਲ ਲੋੜੀਂਦੀ ਤਰਜੀਹ ਹੈ ਅਤੇ ਬਾਕੀ ਮੈਂਬਰ ਬਹੁਮਤ ਬਣਦੇ ਹਨ)। ਨਵੇਂ ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਲਈ ਆਵਾਜਾਈ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ DNS ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ।
ਉਤਪਾਦਨ ਟਿਊਨਿੰਗ ਸਿਫ਼ਾਰਿਸ਼ਾਂ
OS-ਪੱਧਰ ਦੀ ਟਿਊਨਿੰਗ
# Disable Transparent Huge Pages (critical for MongoDB) echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # Set readahead to 8-32 sectors for SSD blockdev --setra 32 /dev/sda # Increase file descriptor limits ulimit -n 64000 ulimit -u 64000 # Swappiness vm.swappiness = 1 # Dirty page ratio vm.dirty_ratio = 15 vm.dirty_background_ratio = 5 # Network tuning net.core.somaxconn = 4096 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_keepalive_time = 120
ਸਰੋਤ ਆਕਾਰ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼
WiredTiger ਕੈਸ਼: ਉਪਲਬਧ ਰੈਮ ਦਾ 50% ਘਟਾਓ 1 GB, ਜਾਂ ਤੁਹਾਡੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸੈੱਟ ਦਾ ਆਕਾਰ, ਜੋ ਵੀ ਛੋਟਾ ਹੋਵੇ।
ਓਪਲੌਗ ਆਕਾਰ: 24-72 ਘੰਟੇ ਲਿਖਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ। 50 GB ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇrs.printReplicationInfo()ਨਾਲ ਮਾਨੀਟਰ ਕਰੋ।
ਸਟੋਰੇਜ਼ IOPS: MongoDB I/O-ਇੰਟੈਂਸਿਵ ਹੈ, ਖਾਸ ਕਰਕੇ ਕੰਪੈਕਸ਼ਨ ਅਤੇ ਚੈਕਪੁਆਇੰਟਿੰਗ ਦੌਰਾਨ। ਪ੍ਰਬੰਧਿਤ IOPS (AWS 'ਤੇ 6000+ IOPS ਦੇ ਨਾਲ gp3, Azure 'ਤੇ ਪ੍ਰੀਮੀਅਮ SSD v2, GCP 'ਤੇ pd-ssd) ਦੇ ਨਾਲ NVMe SSD ਜਾਂ ਕਲਾਊਡ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰੋ।
CPU: ਸਮਕਾਲੀ ਰੀਡ/ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ, ਵਾਇਰਡਟਾਈਗਰ ਦੇ ਸਮਕਾਲੀ ਲੈਣ-ਦੇਣ, ਅਤੇ ਬੈਕਗ੍ਰਾਉਂਡ ਕਾਰਜਾਂ (ਚੈੱਕਪੁਆਇੰਟਿੰਗ, ਕੰਪੈਕਸ਼ਨ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ) ਲਈ ਮਲਟੀਪਲ ਕੋਰਾਂ ਤੋਂ MongoDB ਲਾਭ।
ਨੈੱਟਵਰਕ: ਰੀਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਲਿਖਣ-ਭਾਰੀ ਵਰਕਲੋਡ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਘੱਟ-ਲੇਟੈਂਸੀ, ਉੱਚ-ਬੈਂਡਵਿਡਥ ਨੈੱਟਵਰਕਿੰਗ ਨੂੰ ਯਕੀਨੀ ਬਣਾਓ।
ਕਨੈਕਸ਼ਨ ਪ੍ਰਬੰਧਨ
# Application-side connection pool configuration const client = new MongoClient(uri, { maxPoolSize: 100, minPoolSize: 10, maxIdleTimeMS: 60000, waitQueueTimeoutMS: 5000, connectTimeoutMS: 10000, socketTimeoutMS: 30000, serverSelectionTimeoutMS: 15000, retryWrites: true, retryReads: true, w: "majority", readPreference: "secondaryPreferred", compressors: ["snappy", "zstd"] });
ਮਾਨੀਟਰਿੰਗ ਚੈੱਕਲਿਸਟ
ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ— ਚੇਤਾਵਨੀ ਜਦੋਂ ਕੋਈ ਸੈਕੰਡਰੀ 30 ਸਕਿੰਟਾਂ ਦੇ ਪਛੜ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ।
ਕਨੈਕਸ਼ਨ ਸੰਤ੍ਰਿਪਤਾ— ਚੇਤਾਵਨੀ ਜਦੋਂ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨmaxIncomingConnectionsਦੇ 80% ਤੋਂ ਵੱਧ ਹੁੰਦੇ ਹਨ।
ਵਾਇਰਡਟਾਈਗਰ ਕੈਸ਼— ਚੇਤਾਵਨੀ ਜਦੋਂ ਕੈਚ ਗੰਦਾ ਭਰਨ ਦਾ ਅਨੁਪਾਤ 20% ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ (ਚੈੱਕਪੁਆਇੰਟ ਥ੍ਰੋਪੁੱਟ ਤੋਂ ਵੱਧ ਲਿਖਣ ਦਾ ਦਬਾਅ ਦਰਸਾਉਂਦਾ ਹੈ)।
ਓਪਲੌਗ ਵਿੰਡੋ— ਚੇਤਾਵਨੀ ਜਦੋਂ ਓਪਲੌਗ ਵਿੰਡੋ 12 ਘੰਟਿਆਂ ਤੋਂ ਘੱਟ ਜਾਂਦੀ ਹੈ (ਸੰਭਾਲ ਤੋਂ ਬਾਅਦ ਪੂਰੀ ਰੀਸਿੰਕ ਦੀ ਲੋੜ ਵਾਲੇ ਸੈਕੰਡਰੀ ਦਾ ਜੋਖਮ)।
ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀ ਪੁੱਛਗਿੱਛ — ਜਦੋਂ ਵਾਪਸ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਸਕੈਨ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਅਨੁਪਾਤ 100 (ਗੁੰਮ ਸੂਚਕਾਂਕ) ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ।
ਡਿਸਕ ਵਰਤੋਂ— 70% ਅਤੇ 85% ਥ੍ਰੈਸ਼ਹੋਲਡ 'ਤੇ ਚੇਤਾਵਨੀ। MongoDB ਕੰਪੈਕਸ਼ਨ ਦੌਰਾਨ ਮਹੱਤਵਪੂਰਨ ਅਸਥਾਈ ਡਿਸਕ ਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।
ਬੈਕਅੱਪ ਤਾਜ਼ਗੀ— ਚੇਤਾਵਨੀ ਜਦੋਂ ਆਖਰੀ ਸਫਲ ਬੈਕਅੱਪ ਤੁਹਾਡੀ RPO ਵਿੰਡੋ ਤੋਂ ਪੁਰਾਣਾ ਹੋਵੇ।
ਟਿਕਟ ਦੀ ਉਪਲਬਧਤਾ— 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 ਐਟਲਸ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ HA, ਬੈਕਅੱਪ, ਨਿਗਰਾਨੀ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਕਾਰਜਸ਼ੀਲ ਓਵਰਹੈੱਡ ਦੇ ਨਾਲ ਸਕੇਲਿੰਗ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
AWS ਨਾਲ MongoDB-ਅਨੁਕੂਲ ਲੋੜਾਂ ਸਿਰਫ਼— Amazon DocumentDB 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ MongoDB API ਦੇ ਮੂਲ ਸਬਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਅਨੁਭਵ ਚਾਹੁੰਦੇ ਹੋ। ਨਹੀਂ ਤਾਂ, ਐਟਲਸ ਜਾਂ ਈ.ਕੇ.ਐਸ. 'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ.
Azure ਪੂਰੀ MongoDB ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ— ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਅਨੁਭਵ ਲਈ MongoDB vCore ਲਈ Cosmos DB ਦੀ ਵਰਤੋਂ ਕਰੋ, ਜਾਂ ਅਸਲ MongoDB ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਲਈ Azure 'ਤੇ ਐਟਲਸ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਮਲਟੀ-ਕਲਾਊਡ ਜਾਂ ਹਾਈਬ੍ਰਿਡ— MongoDB ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਜਾਂ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਨਾਲ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ। Kubernetes ਐਬਸਟਰੈਕਸ਼ਨ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚ ਨਿਰੰਤਰ ਤੈਨਾਤੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।
ਬੇਅਰ ਮੈਟਲ ਜਾਂ ਕਿਨਾਰਾ— k3s + Rancher + Longhorn + MongoDB ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਜਾਂ ਪਰਕੋਨਾ ਆਪਰੇਟਰ। ਕੋਈ ਕਲਾਉਡ ਨਿਰਭਰਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਵੱਡੇ ਪੈਮਾਨੇ ਦੀ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ— ਡਾਟਾ ਲੋਕੇਲਿਟੀ ਲਈ ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ ਦੇ ਨਾਲ ਸਾਂਝਾ ਕਲੱਸਟਰ। ਪਰਕੋਨਾ ਓਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸ਼ਾਰਡ ਤੈਨਾਤੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
ਰੀਅਲ-ਟਾਈਮ ਇਵੈਂਟ-ਸੰਚਾਲਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ— MongoDB ਪਰਿਵਰਤਨ ਸਟ੍ਰੀਮ ਬਿਲਟ-ਇਨ CDC ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਜਾਂ ਕੱਟੇ ਹੋਏ ਕਲੱਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ (ਸਟੈਂਡਅਲੋਨ ਨਹੀਂ)।
ਸਿੱਟਾ
MongoDB ਦੇ ਬਿਲਟ-ਇਨ ਰੀਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸ਼ਾਰਡਿੰਗ ਪ੍ਰਾਈਮਿਟਿਵਜ਼ ਇਸ ਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ ਲਈ ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ — ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਦੇ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਅਤੇ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਦੇ ਨਾਲ ਸ਼ਾਰਡ ਕਲੱਸਟਰ ਮੂਲ ਸਮਰੱਥਾਵਾਂ ਹਨ, ਨਾ ਕਿ ਬੋਲਟ-ਆਨ ਬਾਅਦ ਦੇ ਵਿਚਾਰ। ਪਰ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਮੰਗ ਕਰਨ ਵਾਲੀ ਉਪਲਬਧਤਾ ਦੀ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਇਹਨਾਂ ਮੁੱਢਲੇ ਤੱਤਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਉਤਪਾਦਨ MongoDB ਤੈਨਾਤੀ ਲਈ ਅਸਫਲ ਡੋਮੇਨਾਂ ਵਿੱਚ ਤਿੰਨ ਡਾਟਾ-ਬੇਅਰਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਮੈਂਬਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ,w: majorityਨੂੰ ਟਿਕਾਊਤਾ ਲਈ ਚਿੰਤਾ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਚਕਤਾ ਲਈ ਸਹੀ ਓਪਲੌਗ ਆਕਾਰ, ਤੁਹਾਡੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸੈੱਟ ਲਈ ਵਾਇਰਡਟਾਈਗਰ ਕੈਸ਼ ਟਿਊਨਿੰਗ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਸਮਰੱਥਾ ਦੇ ਨਾਲ ਇੱਕ ਟੈਸਟ ਕੀਤੀ ਬੈਕਅੱਪ ਰਣਨੀਤੀ। Kubernetes ਆਪਰੇਟਰ - ਭਾਵੇਂ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ ਲਈ MongoDB ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਜਾਂ ਸ਼ਾਰਡਿੰਗ ਅਤੇ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅੱਪ ਸਮੇਤ ਪੂਰੀ-ਵਿਸ਼ੇਸ਼ ਤੈਨਾਤੀਆਂ ਲਈ ਪਰਕੋਨਾ ਆਪਰੇਟਰ - ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੋ ਜਿਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੰਚਾਲਨ ਨਿਵੇਸ਼ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
AWS, Azure, GCP, ਅਤੇ ਬੇਅਰ ਮੈਟਲ ਵਿੱਚ ਤੈਨਾਤੀ ਪੈਟਰਨ ਇੱਕੋ ਕੋਰ MongoDB ਸੰਰਚਨਾ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਸਟੋਰੇਜ ਕਲਾਸ, ਬੈਕਅੱਪ ਟਿਕਾਣਾ, ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ ਲੇਅਰ ਕੀ ਬਦਲਾਅ ਹੈ। ਇਹ ਇਕਸਾਰਤਾ ਇੱਕ ਓਪਰੇਟਰ-ਆਧਾਰਿਤ ਪਹੁੰਚ ਦਾ ਮੁੱਲ ਹੈ: ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਟੂਲ, ਇੱਕ ਸੰਚਾਲਨ ਮਾਡਲ, ਅਤੇ ਰਨਬੁੱਕਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਸਿੱਖਦੀ ਹੈ ਜੋ ਹਰ ਥਾਂ ਕੰਮ ਕਰਦੀ ਹੈ।
ਇੱਕ ਤਿੰਨ-ਮੈਂਬਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ,w: majorityਲਿਖਦਾ ਹੈ, ਲਗਾਤਾਰ ਓਪਲੌਗ ਆਰਕਾਈਵਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਰੋਜ਼ਾਨਾ PBM ਬੈਕਅੱਪ, ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ, ਕਨੈਕਸ਼ਨ ਸੰਤ੍ਰਿਪਤਾ, ਅਤੇ ਕੈਸ਼ ਪ੍ਰੈਸ਼ਰ ਲਈ ਕੋਰ Prometheus ਚੇਤਾਵਨੀਆਂ। ਪਹਿਲੇ ਦਿਨ ਆਪਣੇ ਫੇਲਓਵਰ ਦੀ ਜਾਂਚ ਕਰੋ - ਤੁਹਾਡੀ ਪਹਿਲੀ ਘਟਨਾ ਦੌਰਾਨ ਨਹੀਂ। ਸ਼ਾਰਡਿੰਗ, ਜ਼ੋਨ-ਅਧਾਰਿਤ ਡਾਟਾ ਲੋਕੇਲਿਟੀ, ਅਤੇ ਬਹੁ-ਖੇਤਰ ਤੈਨਾਤੀਆਂ ਤੱਕ ਫੈਲਾਓ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਅਤੇ ਉਪਲਬਧਤਾ ਲੋੜਾਂ ਵਧਦੀਆਂ ਹਨ। ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਮਕੈਨਿਕਸ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ; ਤੁਹਾਡੀ ਜਿੰਮੇਵਾਰੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਣਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਲਈ ਸਹੀ ਵਪਾਰ-ਆਫ ਬਣਾਇਆ ਜਾ ਸਕੇ ਅਤੇ ਉਹਨਾਂ ਧਾਰਨਾਵਾਂ ਦੀ ਨਿਰੰਤਰ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕੇ।

Loading blog...

Database Kubernetes DevOps Backend

MongoDB ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ: ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ, ਸ਼ਾਰਡਿੰਗ, ਅਤੇ Kubernetes ਆਪਰੇਟਰ

MongoDB HA ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ, ਸ਼ਾਰਡਿੰਗ, ਅਤੇ Kubernetes ਆਪਰੇਟਰਾਂ ਨਾਲ

Balinder Walia12 ਅਪ੍ਰੈਲ 202633 min read

MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਆਰਕੀਟੈਕਚਰ

ਓਪਲੌਗ ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ ਮਕੈਨਿਕਸ

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

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

# Check replication lag on secondaries
rs.printSecondaryReplicationInfo()

ਚੋਣਾਂ ਅਤੇ ਰਾਫਟ-ਅਧਾਰਿਤ ਪ੍ਰੋਟੋਕੋਲ

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

# Check replica set status
rs.status()

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

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

ਤਰਜੀਹ ਪੜ੍ਹੋ ਅਤੇ ਚਿੰਤਾ ਲਿਖੋ

ਰੀਡ ਪ੍ਰੈਫਰੈਂਸਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਡਰਾਈਵਰ ਰੀਡ ਓਪਰੇਸ਼ਨ ਭੇਜਦਾ ਹੈ। ਵਿਕਲਪ ਹਨ:

primary— ਸਾਰੇ ਰੀਡ ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਇਕਸਾਰਤਾ ਪਰ ਕੋਈ ਰੀਡ ਸਕੇਲਿੰਗ ਨਹੀਂ।
primaryPreferred— ਰੀਡਜ਼ ਪ੍ਰਾਇਮਰੀ ਵਿੱਚ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਇਹ ਉਪਲਬਧ ਨਾ ਹੋਵੇ, ਫਿਰ ਸੈਕੰਡਰੀ ਵਿੱਚ।
secondary— ਸਾਰੇ ਰੀਡ ਸੈਕੰਡਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ। ਰੀਡ ਸਕੇਲਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ ਪੁਰਾਣਾ ਡਾਟਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ।
secondaryPreferred— ਰੀਡਜ਼ ਸੈਕੰਡਰੀ 'ਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਵੀ ਉਪਲਬਧ ਨਾ ਹੋਵੇ।
nearest— ਰੀਡਜ਼ ਭੂਮਿਕਾ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਸਭ ਤੋਂ ਘੱਟ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਵਾਲੇ ਮੈਂਬਰ ਨੂੰ ਜਾਂਦੇ ਹਨ। ਭੂ-ਵਿਤਰਿਤ ਤੈਨਾਤੀਆਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ।

w: 1— ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਪਰ ਡਾਟਾ ਖਰਾਬ ਹੋਣ ਦਾ ਖਤਰਾ ਹੈ ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ।
w: "majority"— ਡਾਟਾ-ਬੇਅਰਿੰਗ ਮੈਂਬਰਾਂ ਦੀ ਬਹੁਗਿਣਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਿਫ਼ਾਰਸ਼ੀ ਉਤਪਾਦਨ ਮੂਲ ਹੈ। ਇਹ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਲਿਖਤ ਪ੍ਰਾਇਮਰੀ ਚੋਣ ਤੋਂ ਬਚੀ ਰਹੇਗੀ।
w: <number>— ਮੈਂਬਰਾਂ ਦੀ ਇੱਕ ਖਾਸ ਗਿਣਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
j: true— ਰਸੀਦ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਤ ਆਨ-ਡਿਸਕ ਜਰਨਲ ਲਈ ਵਚਨਬੱਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।w: "majority"ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਇਹ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਟਿਕਾਊਤਾ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

MongoDB ਸ਼ਾਰਡਡ ਕਲੱਸਟਰ ਆਰਕੀਟੈਕਚਰ

ਸ਼ਾਰਡ ਕੁੰਜੀ ਚੋਣ

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

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

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

# Check shard distribution
db.orders.getShardDistribution()

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

ਬਹੁ-ਖੇਤਰਲਈ
ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ
ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ ਖਾਸ ਸ਼ਾਰਡਾਂ ਲਈ ਸ਼ਾਰਡ ਕੁੰਜੀ ਦੀਆਂ ਖਾਸ ਰੇਂਜਾਂ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਡਾਟਾ ਸਥਾਨਿਕਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਯੂਰਪੀਅਨ ਗਾਹਕ ਡੇਟਾ ਈਯੂ ਖੇਤਰ ਵਿੱਚ ਸ਼ਾਰਡਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਯੂਐਸ ਗਾਹਕ ਡੇਟਾ ਯੂਐਸ ਖੇਤਰ ਵਿੱਚ ਸ਼ਾਰਡਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ।
# Add shards to zones sh.addShardTag("shard-us-east", "US") sh.addShardTag("shard-eu-west", "EU") sh.addShardTag("shard-ap-south", "APAC") # Define zone ranges sh.addTagRange("appdb.customers", { "region": "US", "customer_id": MinKey }, { "region": "US", "customer_id": MaxKey }, "US" ) sh.addTagRange("appdb.customers", { "region": "EU", "customer_id": MinKey }, { "region": "EU", "customer_id": MaxKey }, "EU" ) sh.addTagRange("appdb.customers", { "region": "APAC", "customer_id": MinKey }, { "region": "APAC", "customer_id": MaxKey }, "APAC" ) # Verify zone configuration sh.status()
ਮਲਟੀ-ਰੀਜਨ MongoDB ਤੈਨਾਤੀ
MongoDB ਨੂੰ ਕਈ ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਣਾ ਦੋ ਉਦੇਸ਼ਾਂ ਦੀ ਪੂਰਤੀ ਕਰਦਾ ਹੈ: ਤਬਾਹੀ ਰਿਕਵਰੀ (ਇੱਕ ਪੂਰੇ ਖੇਤਰ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਣਾ) ਅਤੇ ਲੇਟੈਂਸੀ ਓਪਟੀਮਾਈਜੇਸ਼ਨ (ਨੇੜਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਰੀਡ ਦੀ ਸੇਵਾ ਕਰਨਾ)। MongoDB ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡੇ ਗਏ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਮੈਂਬਰਾਂ ਦੁਆਰਾ ਬਹੁ-ਖੇਤਰ ਤੈਨਾਤੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਡੇਟਾ ਸਥਾਨ ਲਈ ਜ਼ੋਨ ਸ਼ਾਰਡਿੰਗ, ਅਤੇ ਤਰਜੀਹੀ ਸੰਰਚਨਾ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਨਜ਼ਦੀਕੀ ਮੈਂਬਰ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ।
ਤਿੰਨ ਖੇਤਰਾਂ (ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਵਿੱਚ 2, DR ਖੇਤਰ ਵਿੱਚ 2, ਰੀਡ ਖੇਤਰ ਵਿੱਚ 1) ਵਿੱਚ ਵੰਡੇ ਗਏ ਇੱਕ ਪੰਜ-ਮੈਂਬਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਵਿੱਚ, ਪ੍ਰਾਇਮਰੀ ਖੇਤਰ ਦੇ ਨੁਕਸਾਨ ਨਾਲ ਅਜੇ ਵੀ ਤਿੰਨ ਮੈਂਬਰ ਉਪਲਬਧ ਹਨ — ਇੱਕ ਨਵਾਂ ਪ੍ਰਾਇਮਰੀ ਚੁਣਨ ਲਈ ਬਹੁਮਤ ਲਈ ਕਾਫ਼ੀ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ ਰੀਡ ਖੇਤਰ ਦੇ ਮੈਂਬਰ ਕੋਲpriority: 0ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉੱਚ ਅੰਤਰ-ਖੇਤਰ ਲੇਟੈਂਸੀ ਲਿਖਣ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਘਟਾ ਦੇਵੇਗੀ)। ਵਿਸ਼ਲੇਸ਼ਣ-ਸਮਰਪਿਤ ਮੈਂਬਰਾਂ ਲਈhidden: trueਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਿਯਮਤ ਐਪਲੀਕੇਸ਼ਨ ਰੀਡ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ।
MongoDB ਕਮਿਊਨਿਟੀ Kubernetes ਆਪਰੇਟਰ
MongoDB ਕਮਿਊਨਿਟੀ Kubernetes ਆਪਰੇਟਰ Kubernetes 'ਤੇ MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ ਨੂੰ ਤੈਨਾਤ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਇਹ MongoDB Inc. ਦਾ ਓਪਨ-ਸੋਰਸ ਆਪਰੇਟਰ ਹੈ ਜੋ ਸਟੇਟਫੁਲਸੈੱਟ ਪ੍ਰਬੰਧਨ, ਸਵੈਚਲਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਕੌਂਫਿਗਰੇਸ਼ਨ, TLS ਸਰਟੀਫਿਕੇਟ ਰੋਟੇਸ਼ਨ, ਉਪਭੋਗਤਾ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਰੋਲਿੰਗ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
# Install the MongoDB Community Operator via Helm helm repo add mongodb https://mongodb.github.io/helm-charts helm repo update helm install community-operator mongodb/community-operator \ --namespace mongodb \ --create-namespace \ --set operator.watchNamespace="*"
MongoDBਕਮਿਊਨਿਟੀ CRD ਨਿਰਧਾਰਨ
MongoDBCommunityਕਸਟਮ ਸਰੋਤ ਇੱਕ MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਦੀ ਲੋੜੀਦੀ ਸਥਿਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਉਤਪਾਦਨ-ਤਿਆਰ ਨਿਰਧਾਰਨ ਹੈ।
apiVersion: mongodbcommunity.mongodb.com/v1 kind: MongoDBCommunity metadata: name: production-mongodb namespace: databases spec: members: 3 type: ReplicaSet version: "7.0.12" security: authentication: modes: ["SCRAM"] tls: enabled: true certificateKeySecretRef: name: mongodb-tls-cert caCertificateSecretRef: name: mongodb-ca-cert users: - name: appuser db: admin passwordSecretRef: name: mongodb-appuser-password roles: - name: readWrite db: appdb - name: clusterMonitor db: admin scramCredentialsSecretName: appuser-scram - name: backup-user db: admin passwordSecretRef: name: mongodb-backup-password roles: - name: backup db: admin - name: restore db: admin scramCredentialsSecretName: backup-scram - name: monitoring db: admin passwordSecretRef: name: mongodb-monitoring-password roles: - name: clusterMonitor db: admin scramCredentialsSecretName: monitoring-scram additionalMongodConfig: storage.wiredTiger.engineConfig.cacheSizeGB: 4 storage.wiredTiger.engineConfig.journalCompressor: snappy storage.wiredTiger.collectionConfig.blockCompressor: snappy net.maxIncomingConnections: 10000 operationProfiling.mode: slowOp operationProfiling.slowOpThresholdMs: 100 replication.oplogSizeMB: 51200 setParameter.cursorTimeoutMillis: 600000 statefulSet: spec: template: spec: containers: - name: mongod resources: requests: cpu: "2" memory: 8Gi limits: cpu: "4" memory: 16Gi - name: mongodb-agent resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 512Mi affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: topology.kubernetes.io/zone labelSelector: matchLabels: app: production-mongodb-svc tolerations: - key: "workload" operator: "Equal" value: "database" effect: "NoSchedule" volumeClaimTemplates: - metadata: name: data-volume spec: storageClassName: gp3-csi accessModes: ["ReadWriteOnce"] resources: requests: storage: 100Gi - metadata: name: logs-volume spec: storageClassName: gp3-csi accessModes: ["ReadWriteOnce"] resources: requests: storage: 10Gi
ਇਹ ਨਿਰਧਾਰਨ SCRAM ਪ੍ਰਮਾਣਿਕਤਾ, TLS ਐਨਕ੍ਰਿਪਸ਼ਨ, ਵੱਖਰਾ ਡੇਟਾ ਅਤੇ ਲੌਗ ਵਾਲੀਅਮ, ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਪੌਡ ਐਂਟੀ-ਐਫੀਨਿਟੀ, ਅਤੇ 16 GB RAM ਵਾਲੇ ਨੋਡ ਲਈ ਉਚਿਤ ਵਾਇਰਡਟਾਈਗਰ ਟਿਊਨਿੰਗ ਦੇ ਨਾਲ MongoDB 7.0 ਨੂੰ ਚਲਾਉਣ ਵਾਲਾ ਇੱਕ ਤਿੰਨ-ਮੈਂਬਰੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂversionਫੀਲਡ ਨੂੰ ਬਦਲਦੇ ਹੋ ਤਾਂ ਓਪਰੇਟਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ ਦੀ ਸ਼ੁਰੂਆਤ, ਮੈਂਬਰ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਰੋਲਿੰਗ ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
MongoDB ਆਪਰੇਟਰਲਈ
ਪਰਕੋਨਾ ਸਰਵਰ
MongoDB (PSMDB ਆਪਰੇਟਰ) ਲਈ ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਕਮਿਊਨਿਟੀ ਆਪਰੇਟਰ ਲਈ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ਤਾ-ਅਮੀਰ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ MongoDB (ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ MongoDB ਲਈ ਇੱਕ ਡ੍ਰੌਪ-ਇਨ ਰਿਪਲੇਸਮੈਂਟ) ਲਈ ਪਰਕੋਨਾ ਸਰਵਰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ, ਸ਼ਾਰਡਡ ਕਲੱਸਟਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, MongoDB (PBM) ਲਈ ਪਰਕੋਨਾ ਬੈਕਅੱਪ ਦੁਆਰਾ ਬੈਕਅੱਪ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
# Install Percona Operator helm repo add percona https://percona.github.io/percona-helm-charts/ helm repo update helm install psmdb-operator percona/psmdb-operator \ --namespace psmdb \ --create-namespace
# Percona Server for MongoDB Cluster CRD apiVersion: psmdb.percona.com/v1 kind: PerconaServerMongoDB metadata: name: production-psmdb namespace: databases spec: crVersion: "1.16.0" image: percona/percona-server-mongodb:7.0.12-7 imagePullPolicy: IfNotPresent replsets: - name: rs0 size: 3 resources: requests: cpu: "2" memory: 8Gi limits: cpu: "4" memory: 16Gi volumeSpec: persistentVolumeClaim: storageClassName: gp3-csi accessModes: [ReadWriteOnce] resources: requests: storage: 100Gi nonvoting: enabled: false arbiter: enabled: false configuration: | storage: wiredTiger: engineConfig: cacheSizeGB: 4 journalCompressor: snappy collectionConfig: blockCompressor: snappy operationProfiling: mode: slowOp slowOpThresholdMs: 100 replication: oplogSizeMB: 51200 affinity: antiAffinityTopologyKey: topology.kubernetes.io/zone sharding: enabled: false mongos: {} configsrv: {} backup: enabled: true image: percona/percona-backup-mongodb:2.5.0 storages: s3-backup: type: s3 s3: bucket: company-mongodb-backups region: us-east-1 credentialsSecret: aws-s3-credentials prefix: production insecureSkipTLSVerify: false pitr: enabled: true oplogOnly: false compressionType: gzip tasks: - name: daily-full enabled: true schedule: "0 3 * * *" keep: 7 storageName: s3-backup compressionType: gzip secrets: users: mongodb-users-secret pmm: enabled: true image: percona/pmm-client:2 serverHost: pmm-server.monitoring
ਪਰਕੋਨਾ ਆਪਰੇਟਰ ਦਾ ਮੁੱਖ ਫਾਇਦਾ MongoDB (PBM) ਲਈ ਪਰਕੋਨਾ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਇਸਦਾ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਹੈ। PBM ਲਾਜ਼ੀਕਲ ਅਤੇ ਭੌਤਿਕ ਬੈਕਅੱਪ, ਵਾਧੇ ਵਾਲੇ ਬੈਕਅੱਪ, ਅਤੇ ਔਪਲੌਗ ਤੋਂ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ - ਇਹ ਸਭ CRD ਦੁਆਰਾ ਘੋਸ਼ਣਾਤਮਕ ਤੌਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤੇ ਗਏ ਹਨ।
AWS ਤੈਨਾਤੀ: DocumentDB ਬਨਾਮ ਐਟਲਸ ਬਨਾਮ EKS
'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ
Amazon DocumentDBਇੱਕ MongoDB-ਅਨੁਕੂਲ ਦਸਤਾਵੇਜ਼ ਡਾਟਾਬੇਸ ਸੇਵਾ ਹੈ। ਇਹ MongoDB ਨਹੀਂ ਹੈ - ਇਹ ਇੱਕ ਮਲਕੀਅਤ ਵਾਲਾ ਇੰਜਣ ਹੈ ਜੋ MongoDB ਵਾਇਰ ਪ੍ਰੋਟੋਕੋਲ (MongoDB 4.0 API ਤੱਕ ਅਨੁਕੂਲ) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। DocumentDB Aurora ਦੇ ਸਮਾਨ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਟੋਰੇਜ਼ ਲੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗਣਨਾ ਨੂੰ ਸਟੋਰੇਜ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਖੇਤਰ ਦੇ ਅੰਦਰ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, 15 ਤੱਕ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ। ਹਾਲਾਂਕਿ, ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ MongoDB ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਘਾਟ ਹੈ: ਪਰਿਵਰਤਨ ਸਟ੍ਰੀਮ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ, ਲੈਣ-ਦੇਣ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਏਕੀਕਰਣ ਪਾਈਪਲਾਈਨ ਪੜਾਅ ਅਸਮਰਥਿਤ ਹਨ। DocumentDB ਦੀ ਵਰਤੋਂ ਤਾਂ ਹੀ ਕਰੋ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ MongoDB ਦੇ API ਦੇ ਸਬਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਦੀ ਕਾਰਜਸ਼ੀਲ ਸਾਦਗੀ ਦੀ ਕਦਰ ਕਰਦੇ ਹੋ।
AWS'ਤੇ

EKS'ਤੇ

# 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 ਤੈਨਾਤੀ: AKS

# 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