rs.reconfig() (método mongosh)

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 rs.reconfig().

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

rs.reconfig() 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 rs.reconfig() 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

rs.reconfig() 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 rs.reconfig().

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 rs.reconfig().

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.

Control de acceso

Para ejecutar el método en implementaciones que imponen control de acceso, el usuario debe tener la acción de privilegio replSetConfigure en 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

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

set de réplicas de versión mixta

Disponibilidad

El método shell rs.reconfig() puede hacer que el primario actual se reduzca en algunas situaciones. La reducción primaria activa una elección para seleccionar un nuevo primario:

Cuando el primario abdica, detiene cualquier guardado en curso. 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 }

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.

Descartar Conexiones Salientes Tras Remover a un nodo

Al utilizar rs.reconfig() 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.

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.

Cambiar la prioridad de los miembros del conjunto de réplicas

La siguiente secuencia de operaciones actualiza el members[n].priority del segundo nodo. Las operaciones se emiten a través de una sesión mongosh que está conectada al primario.

cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);

1. La primera declaración utiliza el método para rs.conf() recuperar un documento que contiene la configuración actual del conjunto de réplicas y establece el documento en la variable cfg local.

2. La segunda instrucción establece un valor members[n].priority para el segundo documento en el arreglo members. Para obtener configuraciones adicionales, consulta configuración del set de réplicas.

   Para acceder al documento de configuración del miembro en la matriz, la declaración utiliza el índice de la matriz y no el members[n]._id campo del miembro del conjunto de réplicas.

3. La última instrucción llama al método rs.reconfig() con el cfg modificado para inicializar esta nueva configuración. Una vez que se haya reconfigurado correctamente, la configuración del set de réplicas se parecerá a la siguiente:

{
   "_id" : "rs0",
   "version" : 2,
   "protocolVersion" : Long(1),
   "members" : [
      {
         "_id" : 0,
         "host" : "mongodb0.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {
         },
         "secondaryDelaySecs" : Long(0),
         "votes" : 1
      },
      {
         "_id" : 1,
         "host" : "mongodb1.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 2,
         "tags" : {
         },
         "secondaryDelaySecs" : Long(0),
         "votes" : 1
      },
      {
         "_id" : 2,
         "host" : "mongodb2.example.net:27017",
         "arbiterOnly" : false,
         "buildIndexes" : true,
         "hidden" : false,
         "priority" : 1,
         "tags" : {
         },
         "secondaryDelaySecs" : Long(0),
         "votes" : 1
      }
   ],
   "settings" : {
      "chainingAllowed" : true,
      "heartbeatIntervalMillis" : 2000,
      "heartbeatTimeoutSecs" : 10,
      "electionTimeoutMillis" : 10000,
      "catchUpTimeoutMillis" : 2000,
      "getLastErrorModes" : {
      },
      "getLastErrorDefaults" : {
         "w" : 1,
         "wtimeout" : 0
      },
      "replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
   }
}

Cambiar la configuración del conjunto de réplicas

También puedes modificar el documento del set de réplicas del clúster settings. El documento settings contiene opciones de configuración que se aplican a todo el set de réplicas.

La siguiente secuencia de operaciones actualiza el del settings.heartbeatTimeoutSecs clúster 15 a. Las operaciones se realizan a través de una sesión conectada al mongosh clúster principal.

cfg = rs.conf();
cfg.settings.heartbeatTimeoutSecs = 15;
rs.reconfig(cfg);