MongoDB
Explica la arquitectura de replica sets, primary, secondaries, oplog, elecciones, failover y configuración para alta disponibilidad.
Un replica set mantiene varias copias de los datos para ofrecer alta disponibilidad. Un miembro actúa como y recibe escrituras; los replican el oplog y pueden asumir el rol de primary mediante una election.
application
↓
primary
↓ oplog
secondary A
secondary BReplication es asíncrona: durante intervalos normales puede existir lag entre miembros.
Acepta escrituras y, por defecto, lecturas críticas. Solo existe un primary por replica set en un momento estable.
Aplica operaciones del oplog en orden. Puede atender lecturas según read preference, pero estas pueden estar atrasadas.
Participa en votación sin almacenar datos. Reduce costes de hardware, pero no aporta redundancia de datos y añade decisiones de topología. Generalmente es preferible un miembro data-bearing cuando sea posible.
Una election ocurre cuando el primary deja de ser elegible o disponible.
primary pierde mayoría
→ miembros detectan fallo
→ candidatos solicitan votos
→ nuevo primary
→ drivers actualizan topologíaDurante la elección existe una ventana sin escrituras. El driver puede reintentar operaciones compatibles.
Un replica set necesita mayoría de miembros con voto para elegir primary. Un primary aislado de la mayoría hace step down aunque siga vivo, evitando dos primaries aceptando escrituras válidas.
Diseña número impar de votos y distribución entre fallos independientes.
Lag puede crecer por:
Un secondary atrasado no es solo un problema de lectura; puede dejar de ser candidato útil para failover.
Si un primary aceptó writes que no alcanzaron el commit point de mayoría y luego pierde la elección, algunas operaciones pueden revertirse durante reconciliación.
writeConcern: 'majority' reduce exposición a este escenario para writes confirmados.
Leer de secondaries puede descargar ciertos workloads, pero añade staleness. No ejecutes reportes destructivos para la capacidad de replicar.
Una réplica dedicada a analytics puede configurarse con prioridad y tags apropiados, pero sigue necesitando recursos suficientes.
Miembros hidden pueden servir para backups o tareas especiales sin recibir tráfico normal. Un delayed member conserva una copia atrasada y puede ayudar frente a errores lógicos dentro de una ventana, pero no reemplaza backup ni PITR.
Estas configuraciones requieren operación experta y pruebas de recuperación.
Un miembro nuevo copia datos y alcanza el oplog. Necesita suficiente ventana para completar. Si el oplog rota antes de que alcance el punto necesario, puede reiniciar el proceso.
Planifica red, disco y carga durante incorporación de nodos.
Distribuir miembros entre zonas mejora tolerancia a fallos, pero aumenta latencia de majority writes. Una topología multi-region debe definir:
Replication copia correctamente:
Backup conserva puntos recuperables separados y políticas de retención.
La URI debe incluir miembros o usar SRV para que el driver descubra la topología. Conectarse solo a un host sin configuración correcta puede impedir failover transparente.
mongodb://host1,host2,host3/app?replicaSet=rs0No hardcodees únicamente el primary actual.
Rolling maintenance actualiza secondaries uno por uno, realiza step down controlado y finaliza el antiguo primary cuando el procedimiento y versión lo soportan.
Observa elections, lag y capacidad de mayoría durante cada paso.
Replica sets proporcionan alta disponibilidad mediante copias, oplog y elections. La replicación es asíncrona, necesita mayoría y puede tener lag. Write/read concerns determinan garantías para la aplicación. Un replica set reduce downtime; no conserva por sí solo puntos históricos recuperables.
Oplog.