Cloud Manager realiza un reinicio en secuencia cuando realizas el mantenimiento en los nodos de un clúster. La automatización actualiza los nodos en un clúster uno a uno hasta que todos los nodos estén actualizados para mantener la disponibilidad del clúster durante un período de mantenimiento.
Antes de realizar el mantenimiento en tus clústeres, revisa las siguientes consideraciones y toma medidas, si es necesario, para mantener la disponibilidad del clúster.
Nota
Para aprender cómo la Automatización realiza mantenimiento en tus clústeres, consulta ¿Cómo realiza Cloud Manager el mantenimiento de los nodos de clúster?
oplog Tamaño
Cada nodo de un clúster se reinicia en modo autónomo antes de que comience el mantenimiento. El nodo vuelve a reproducir las escrituras en el oplog para ponerse al día con los otros nodos cuando se agrega nuevamente al clúster después de completar el mantenimiento.
Asegúrate de que el oplog del clúster sea lo suficientemente grande como para almacenar todas las escrituras que tu aplicación pueda realizar durante el periodo de mantenimiento. Utiliza la opción avanzada de implementación replication.oplogSizeMB para ajustar el tamaño del oplog.
Prioridad
Todas las conexiones de clientes con un nodo principal se descartan cuando comienza el mantenimiento en ese nodo. Las conexiones se restablecen con el nuevo nodo primario elegido.
Puedes preferir que un nodo en un centro de datos específico se convierta en el nuevo nodo principal. Edita la configuración del clúster y ajusta la prioridad de cada nodo para indicar tu nodo principal preferido.
Tolerancia a los fallos
Los nodos en mantenimiento no proveen soporte de conmutación por error al clúster. Para sets de réplicas de tres miembros, si un nodo adicional queda indisponible mientras uno está en mantenimiento, el clúster ha perdido la mayoría de los nodos. El nodo principal pierde este estatus y se reduce para convertirse en un nodo secundario. No se puede elegir un nuevo primario hasta que la mayoría de los nodos del clúster estén disponibles.
Para aplicaciones críticas que requieren alta disponibilidad, considera convertir un set de réplicas de tres miembros a un set de réplicas de cinco miembros antes de realizar operaciones de mantenimiento, para mantener la mayoría del clúster en caso de que un nodo adicional del clúster se vuelva inaccesible durante el mantenimiento.
Nota
Los sets de réplicas de cinco nodos o más grandes son más resilientes y menos propensos a experimentar pérdida de mayoría durante los períodos de mantenimiento.
Una opción más sencilla pero menos resiliente para aumentar la tolerancia a múltiples fallos es añadir un árbitro temporal a un set de réplicas de tres nodos antes de realizar el mantenimiento.
Construcciones de índices únicos
La automatización construye índices en los nodos del clúster uno a la vez utilizando comandos idénticos pero independientes. Para garantizar que las escrituras respeten la unique calidad de los campos indexados en un/a índice único, todas las escrituras en la colección del clúster deben detenerse antes de compilar el índice.
No puedes usar Explorador de datos ni el Recurso de configuración de automatización en Cloud Manager para crear índices únicos de manera progresiva, ya que estos métodos no detienen las escrituras en el clúster.
Si tu caso de uso requiere que compiles nuevos índices únicos:
Detén todas las escrituras en la colección afectada. Para obtener más información. consulta db.fsyncLock() en el Manual de MongoDB.
Consulta Crear índices en conjuntos de réplicas en el Manual de MongoDB para crear el índice único de forma continua.