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 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:

• Agregar un nuevo miembro al conjunto de réplicas de votación.

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

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

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 miembros 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 conjunto de réplicas propagan su configuración mediante latidos. Cuando un miembro detecta una configuración con valores superiores version a term y, 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 del conjunto de réplicas con derecho a voto han instalado la configuración actualy

• 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 miembros del conjunto de réplicas con derecho a voto. Sin embargo, es posible que la mayoría de las escrituras confirmadas en la configuración anterior no se hayan confirmado en la configuración actual. Delayed Los miembros o los miembros que son lagging behind principales pueden aumentar el tiempo empleado en 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 miembro secundario recién agregado no cuenta como miembro con derecho a voto y no puede ser elegido hasta que haya alcanzado el SECONDARY estado.

Al añadir un nuevo nodo con derecho a votación a un conjunto de réplicas, replSetReconfig añadirá internamente un newlyAdded campo a la configuración del nodo. Los nodos con el newlyAdded campo no se contabilizan para el número actual de nodos con derecho a votación. Al finalizar la sincronización inicial y alcanzar el estado,SECONDARY el newlyAdded campo 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 miembros del conjunto deben estar operativos para que los cambios se propaguen correctamente.

replSetReconfig puede provocar la renuncia de los candidatos a la primaria actual en algunas situaciones. La renuncia a la primaria desencadena una elecciónpara elegir una nueva primaria:

• Cuando se aumenta el nuevo primario, se incrementa el term campo para distinguir los cambios de configuración realizados en el nuevo primario de los cambios 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 electoral, el clúster no puede aceptar operaciones de escritura hasta que elija la nueva primaria.

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.

De forma predeterminada, los miembros del conjunto de réplicas esperan 5 minutos antes de interrumpir las conexiones con el miembro eliminado. En conjuntos de réplicas fragmentados, puede modificar este tiempo de espera mediante el ShardingTaskExecutorPoolHostTimeoutMS parámetro de servidor.

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.