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

Obligar a un miembro a ser primario estableciendo su prioridad alta

Este procedimiento presupone que su servidor principal actual es m1.example.net y que desea convertir m3.example.net en el principal. También presupone que tiene un conjunto de réplicas de tres miembros con la configuración que se indica a continuación. Para obtener más información sobre las configuraciones, consulte Uso de la configuración del conjunto de réplicas.

Este procedimiento asume 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 que está conectada a la principal, utilice la siguiente secuencia de operaciones para hacer que sea m3.example.net la 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 se sincronizan 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 detrás del tiempo óptimo de m1.example.net, y si no necesita tener un primario designado dentro de los 10 segundos, puede forzar a m1.example.net a retirarse ejecutando:

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

   Esto evita que m1.example.net sea el principal durante 86.400 segundos (24 horas), incluso si no hay ningún otro miembro que pueda serlo. Cuando m3.example.net alcance a m1.example.net, se convertirá en el principal.

   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 obligar a un miembro a convertirse en principal utilice el siguiente 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ónmongoshque está conectada a la instanciamongodque se ejecuta en mdb2.example.net, congele 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 vuelve 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.