replSetReconfig (comando de base de datos)

Global nivel de confirmación de escritura (write concern)

A partir de MongoDB 5.0, se debe configurar explícitamente el nivel de confirmación de escritura (write concern) predeterminado global antes de intentar reconfigurar un set de réplicas con una configuración que cambiaría el nivel de confirmación de escritura (write concern) implícito por defecto. Para configurar la configuración global de nivel de confirmación de escritura (write concern) por defecto, use el comando setDefaultRWConcern.

term Campo de configuración de la réplica

El campo term lo define el miembro principal del set de réplicas. El primario ignora el campo term si se establece explícitamente en la operación replSetReconfig.

La reconfiguración no puede añadir ni remover más de un nodo votante a la vez

replSetReconfig por defecto permite agregar o remover no más de 1 voting nodos a la vez. Por ejemplo, una nueva configuración puede hacer como máximo uno de los siguientes cambios en el clúster membership:

• Agregando un nuevo miembro con derecho a voto en el set de réplicas.

• Removiendo a un miembro existente del conjunto de réplicas con derecho a voto.

• Modificar el votes para un miembro existente del conjunto de réplicas.

Para agregar o remover varios nodos con derecho a voto, emite una serie de replSetReconfig operaciones para agregar o remover un nodo a la vez.

Emitir una reconfiguración forzada instala inmediatamente la nueva configuración incluso si añade o elimina varios nodos con derecho a voto. La reconfiguración forzada puede causar un comportamiento inesperado, como el rollback de "majority" operaciones de escritura confirmadas.

La reconfiguración espera hasta que la mayoría de los nodos instalen la configuración de réplica

replSetReconfig espera hasta que la mayoría de los miembros con derecho a voto del conjunto de réplicas implementen la nueva configuración de réplica antes de devolver el éxito. Un nodo votante es cualquier nodo de un set de réplicas donde members[n].votes es 1, incluidos los árbitros.

Los miembros del set de réplicas propagan su configuración de réplica mediante latidos. Cada vez que un nodo con una configuración aprende sobre una configuración con un mayor version y term, instala la nueva configuración. El proceso de reconfiguración consta de dos fases de "espera" distintas:

1) Espera que la configuración actual esté confirmada antes de instalar la nueva configuración.

La configuración «actual» se refiere a la configuración de réplica que utiliza el primario en el momento en que se emite replSetReconfig.

Una configuración se compromete cuando:

• La mayoría de los miembros votantes del conjunto de réplicas han instalado la configuración actual, y

• Todas las escrituras que fueron "majority" confirmadas en la configuración anterior también se han replicado a la mayoría en la configuración actual.

Normalmente, la configuración actual ya se ha instalado en la mayoría de los sets de réplicas de votación. Sin embargo, la mayoría de las escrituras confirmadas en la configuración anterior pueden no estar todas comprometidas en la configuración actual. Los Delayed nodos o los nodos que lagging behind son los primarios pueden aumentar el tiempo dedicado a esta fase.

Si la operación se emitió con un límite de maxTimeMS y la operación excede el límite mientras espera, la operación devuelve un error y descarta la nueva configuración. El límite es acumulativo y no se restablece después de pasar a la siguiente fase.

2) Espera a que la mayoría de los nodos votantes en la nueva configuración instalen la nueva configuración.

La configuración "nueva" se refiere a la configuración de réplica especificada para replSetReconfig.

El primario instala y comienza a usar la nueva configuración de réplica antes de propagar la configuración a los miembros restantes del set de réplicas. La operación solo espera que la mayoría de los nodos con derecho a voto instalen la nueva configuración y no requiere esperar a que la nueva configuración sea comprometida.

Si a la operación se le asigna un límite maxTimeMS y supera el límite mientras espera, la operación devuelve un error pero continúa utilizando y propagando la nueva configuración.

Emitir una forzada reconfiguración instala inmediatamente la nueva configuración independientemente del estado de compromiso de la configuración anterior. La reconfiguración forzada puede causar un comportamiento inesperado, como el rollback de "majority" operaciones de escritura confirmadas.

Para verificar el estado del compromiso de la configuración actual del réplica, emite replSetGetConfig con el parámetro commitmentStatus en el set de réplicas primario.

Reconfiguración automática para nuevos miembros de set de réplicas de votación

A partir de MongoDB 5.0, un secundario recién agregado no cuenta como nodo votante y no puede ser elegido hasta que alcance el estado SECONDARY.

Cuando se añade un nuevo nodo de votación a un set de réplicas, replSetReconfig añadirá internamente un campo newlyAdded a la configuración del nodo. Los nodos con el campo newlyAdded no cuentan para el número actual de nodos de votación. Cuando la sincronización inicial se complete y el nodo alcance el estado SECONDARY, el campo newlyAdded se elimina automáticamente.

Control de acceso

Para ejecutar el comando en implementaciones que aplican el control de acceso, el usuario debe tener el privilegio replSetConfigure sobre el recurso del clúster. El rol de clusterManager funcionalidad incorporada, disponible en la base de datos admin, proporciona los privilegios requeridos para este comando.

Comportamiento de bloqueo

replSetReconfig obtiene un bloqueo exclusivo para prevenir que más de una replSetReconfig operación ocurran al mismo tiempo.

set de réplicas de versión mixta

Disponibilidad

La mayoría de los nodos del conjunto deben estar en funcionamiento para que los cambios se propaguen correctamente.

replSetReconfig puede hacer que el primario actual cese en algunas situaciones. El paso primario desencadena una elección para seleccionar un nuevo primario:

• Cuando el nuevo primario se activa, incrementa el campo term para distinguir los cambios de configuración realizados en el nuevo primario de los realizados en el primario anterior.

• Al descender, el primario ya no cierra todas las conexiones de los clientes; sin embargo, los guardados que estaban en curso son finalizados. Para más detalles, consulta Comportamiento.

El tiempo medio antes de que un clúster elija un nuevo primario no debe exceder normalmente los 12 segundos, suponiendo las replica configuration settings por defecto. Esto incluye el tiempo necesario para marcar el primario como no disponible y para convocar y completar una elección. Puedes ajustar este período de tiempo modificando la opción de configuración de replicación settings.electionTimeoutMillis. Factores como la latencia de red pueden prolongar el tiempo necesario para completar las elecciones del set de réplicas, lo que a su vez afecta la cantidad de tiempo que su clúster puede operar sin un primario. Estos factores dependen de su arquitectura particular de clúster.

Durante el proceso de elección, el clúster no puede aceptar operaciones de escritura hasta que elija el nuevo primario.

La lógica de conexión de la aplicación debe incluir tolerancia para las conmutaciones por error automáticas y las elecciones posteriores. Los controladores de MongoDB pueden detectar la pérdida del nodo principal y reintentar automáticamente ciertas operaciones de guardado una sola vez, proporcionando un manejo adicional incorporado para conmutaciones por error automáticas y elecciones:

Los controladores compatibles habilitan las Escrituras reintentables por defecto

Para reducir aún más el potencial impacto en un clúster de producción, solo reconfigura durante los períodos de mantenimiento programados.

{ force: true }

Descartar Conexiones Salientes Tras Remover a un nodo

Al utilizar replSetReconfig para remover un nodo del conjunto de réplicas, no se descartan automáticamente las conexiones salientes abiertas de otros nodos del conjunto de réplicas hacia el nodo eliminado.

Por defecto, los nodos del set de réplicas esperan 5 minutos antes de cerrar las conexiones al nodo eliminado. En sets de réplicas particionados, se puede modificar este tiempo de espera mediante el parámetro del servidor ShardingTaskExecutorPoolHostTimeoutMS.

Para descartar inmediatamente todas las conexiones salientes del set de réplicas al nodo eliminado, ejecutar el comando administrativo dropConnections en cada nodo restante del set de réplicas:

db.adminCommand(
  {
    "dropConnections" : 1,
    "hostAndPort" : [
      "<hostname>:<port>"
    ]
  }
)

Reemplaza <hostname> y <port> con los del nodo eliminado.

Prioridad de los nodos y votaciones

• Los nodos con priority mayor que 0 no pueden tener votes votos.

• Los nodos sin derecho a voto (es decir, votes es 0) deben tener priority de 0.