Obliga a un miembro autogestionado de un set de réplicas a convertirse en primario

Forzar a un nodo a ser el primario al establecer su alta prioridad

Este procedimiento asume que tu principal actual es m1.example.net y que te gustaría, en cambio, establecer m3.example.net como principal. El procedimiento también asume que tienes un set de réplicas de tres nodos con la siguiente configuración. Para obtener más información sobre las configuraciones, consulta Uso de la configuración de sets de réplicas.

Este procedimiento supone esta configuración:

{
    "_id" : "rs",
    "version" : 7,
    "members" : [
        {
            "_id" : 0,
            "host" : "m1.example.net:27017"
        },
        {
            "_id" : 1,
            "host" : "m2.example.net:27017"
        },
        {
            "_id" : 2,
            "host" : "m3.example.net:27017"
        }
    ]
}

1. En un mongosh sesión conectada al principal, utiliza la siguiente secuencia de operaciones para hacer que m3.example.net sea el principal:

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

   La última instrucción llama a rs.reconfig() con el documento de configuración modificado para configurar m3.example.net de modo que tenga un valor members[n].priority superior al de otras instancias mongod.

   Se produce la siguiente secuencia de eventos:

   • m3.example.net y m2.example.net será sincronizado con m1.example.net (normalmente en 10 segundos).

   • m1.example.net ve que ya no tiene la máxima prioridad y, en la mayoría de los casos, renuncia. m1.example.net no renunciará si la sincronización de m3.example.net está muy atrasada. En ese caso, m1.example.net espera hasta que m3.example.net esté a menos de 10 segundos de su optime y luego renuncia. Esto minimiza el tiempo sin primario tras una conmutación por error.

   • El retiro forzado desencadena una elección en la que m3.example.net se convierte en primario con base en su configuración de priority.

2. Opcionalmente, si m3.example.net está más de 10 segundos por detrás del optime de m1.example.net, y si no necesita tener un primario designado en un plazo de 10 segundos, se puede forzar a m1.example.net a retirarse ejecutando:

   db.adminCommand({replSetStepDown: 86400, force: 1})

   Esto impide que m1.example.net sea primario durante 86 400 segundos (24 horas), incluso si no hay ningún otro nodo que pueda convertirse en primario. Cuando m3.example.net alcance a m1.example.net, se convertirá en el primario.

   Si más adelante desea que m1.example.net vuelva a ser primario mientras espera que m3.example.net lo alcance, ejecute el siguiente comando para que m1.example.net busque nuevamente la elección:

   rs.freeze()

   El rs.freeze() proporciona un contenedor alrededor del comando de base de datos replSetFreeze.

Forzar que un nodo sea primario utilizando comandos de base de datos

Considera un set de réplicas con los siguientes miembros:

• mdb0.example.net - el actual primario.

• mdb1.example.net - a secundario.

• mdb2.example.net - un secundario.

Para forzar a un nodo a convertirse en primario, se debe seguir este procedimiento:

1. En mongosh, ejecuta rs.status() para asegurarte de que tu set de réplicas esté funcionando como se esperaba.

2. En una sesión mongosh que está conectada a la mongod instancia ejecutándose en mdb2.example.net, congelar mdb2.example.net para que no intente convertirse en principal durante 120 segundos.

   rs.freeze(120)

3. Inicia sesión en la mongosh conectada al mongod que se ejecuta en mdb0.example.net, baje esta instancia para que mongod no sea elegible para convertirse en primario durante 120 segundos.

   rs.stepDown(120)

   mdb1.example.net se convierte en primario.

   Nota

   Durante la transición, hay una breve ventana en la que el conjunto no tiene un primario.

Para obtener más información, consulta los métodos rs.freeze() y rs.stepDown() que envuelven los comandos replSetFreeze y replSetStepDown.