A priority 0 nodo es un nodo que no puede convertirse en primario y no puede desencadenar elecciones. Los miembros con prioridad 0 pueden reconocer las operaciones de escritura emitidas con un nivel de confirmación de escritura (write concern) de w : <number>. Para el nivel de confirmación de escritura (write concern) "majority", el miembro con prioridad 0 también debe tener derecho a votar (es decir, members[n].votes es mayor que 0) para reconocer el guardar. Miembros no votantes de sets de réplicas (es decir, members[n].votes es 0) no pueden contribuir al reconocimiento de operaciones de escritura con un nivel de confirmación de escritura (write concern) de "majority".
Aparte de las restricciones mencionadas anteriormente, los secundarios que tienen funcionan como secundarios normales: mantienen una copia del conjunto de datos, aceptan operaciones de lectura y votan en las priority 0 elecciones.
Configurar un miembro del conjunto de réplicas con podría ser recomendable si dicho miembro se implementa en un centro de datos alejado de la implementación principal y, por lo tanto, presenta una mayor latencia. Si bien puede atender adecuadamente las solicitudes de lectura locales, podría no ser ideal para realizar las funciones de un servidor principal debido a su priority 0 latencia.
Para esta situación, el siguiente diagrama muestra un centro de datos a la izquierda que aloja el primario y un secundario, y un centro de datos a la derecha que aloja un secundario que se ha configurado para tener prioridad 0 para evitar que se convierta en primario. Debido a este ajuste, solo los miembros en el centro de datos de la izquierda son elegibles para convertirse en primario en una elección.
Compárese esto con la prioridad por defecto para los miembros del conjunto de réplicas, priority 1, donde cualquiera de los secundarios en este escenario sería apto para servir como primario. Consulta Sets de Réplicas distribuidos en Dos o Más Centros de Datos para obtener más información.
Miembros de prioridad 0 como en espera
Un miembro secundario con priority 0 puede funcionar como reserva. En algunos conjuntos de réplicas, podría no ser posible agregar un nuevo miembro en un tiempo razonable. Un miembro en reserva conserva una copia actualizada de los datos para poder reemplazar a un miembro no disponible.
En muchos casos, no es necesario establecer el modo de espera en prioridad 0. Sin embargo, en sets de réplicas con distribución geográfica o hardware diverso, una instancia en espera con prioridad 0 garantiza que solo ciertos nodos se conviertan en primarios.
Un standby prioritario 0 también puede ser valioso para algunos nodos de un grupo con diferentes perfiles de hardware o carga de trabajo. En estos casos, implementar un nodo con prioridad 0 para que no pueda convertirse en primario. También considera utilizar un miembro oculto para este propósito.
Si tu conjunto ya tiene siete nodos con derecho a voto, también configura el nodo como sin derecho a voto.
Consideraciones sobre la recuperación ante desastres
Al configurar un secundario para tener priority 0, considera posibles patrones de conmutación por falla, incluidas todas las particiones de red posibles. Siempre asegúrese de que su centro de datos principal contenga tanto un quórum de nodos con derecho a voto como nodos que sean elegibles para ser primarios.
Ejemplo
Para configurar un secundario para que priority 0 tenga, consulte Cómo evitar que un secundario autoadministrado se convierta en principal.