Mantenimiento rolling en un replica set (reinicio, parche del SO, actualización menor)

Comando

// 1) Before starting: all members healthy, low lag, and an oplog window longer than the maintenance
rs.printSecondaryReplicationInfo()
// 2) Clean shutdown on the SECONDARY under maintenance (then OS/binary work, restart with the same config):
db.getSiblingDB("admin").shutdownServer({ timeoutSecs: 60 })
// 3) Wait until the member is SECONDARY and lag has closed, then move to the next secondary:
rs.status().members.map(m => ({ host: m.name, state: m.stateStr, health: m.health }))
// 4) When all secondaries are done, on the PRIMARY: hand over to a secondary that catches up within 30 s
rs.stepDown(120, 30)
// 5) The old primary is now a SECONDARY: apply steps 2 and 3 to it

Qué hace

Indica el orden para poner los miembros en mantenimiento de uno en uno, primero los secundarios y el primario al final, de modo que los reinicios, parches del SO o actualizaciones de binarios se hagan sin sacar el conjunto de servicio.

Cuándo usarlo

Durante actualizaciones planificadas del SO/kernel, actualizaciones de versión menor, cambios de parámetros de mongod o mantenimiento de disco/hardware.

Precaución

Nunca apague más de un miembro a la vez; en un conjunto de 3 miembros, perder dos supone perder la mayoría. Después de cada miembro, confirme el estado SECONDARY y que el retraso se ha cerrado. stepDown provoca una breve interrupción de escrituras; asegúrese de que los drivers se reconectan con retryable writes. Si hay un árbitro, trátelo en la misma secuencia.