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 declaración llama a con el documento de configuración modificado para rs.reconfig() configurar m3.example.net para que tenga un valor más alto members[n].priority que las otras mongod instancias.

   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 Detecta que ya no tiene la máxima prioridad y, en la mayoría de los casos, se desconecta. m1.example.net no se desconecta si m3.example.net la sincronización de está muy retrasada. En ese caso, m1.example.net espera hasta que m3.example.net esté a 10 segundos de su tiempo óptimo y luego se desconecta. Esto minimiza el tiempo sin principal tras la conmutación por error.

   • La reducción fuerza una elección en la que m3.example.net se convierte en primaria en función de su priority configuración.

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 10 segundos, puede forzar a m1.example.net a retirarse ejecutando:

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

   Esto evita que m1.example.net sea principal durante 86,400 segundos (24 horas), incluso si no hay otro miembro que pueda convertirse en principal. Cuando m3.example.net alcance a m1.example.net, se convertirá en 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 proporciona un rs.freeze() replSetFreeze contenedor alrededor del comando de base de datos.

Forzar a un miembro a ser principal mediante comandos de base de datos

Considere un conjunto de réplicas con los siguientes miembros:

• mdb0.example.net - el actual primario.

• mdb1.example.net - una secundaria.

• mdb2.example.net - una secundaria .

Para obligar a un miembro a convertirse en principal utilice el siguiente procedimiento:

1. mongoshEn, ejecute para asegurarse de que su conjunto de réplicas se esté ejecutando como se rs.status() 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. En una sesiónmongoshque está conectada a lamongodque se ejecuta en mdb0.example.net, reduzca el nivel de esta instancia para que lamongodno sea elegible para convertirse en principal 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, considere los rs.freeze() métodos rs.stepDown() y replSetFreeze replSetStepDown que envuelven los comandos y.