En algunas circunstancias (por ejemplo, cuando tiene un servidor principal y uno secundario, pero las limitaciones de costo impiden agregar otro secundario), puede optar por agregar un árbitro a su conjunto de réplicas. Un árbitro participa en elecciones primarias pero un árbitro no tiene una copia del conjunto de datos y no puede convertirse en primario.
Un árbitro tiene exactamente 1 Votación electoral. Por defecto, un árbitro tiene prioridad 0.
Importante
No ejecutar un árbitro en sistemas que también sean los hosts de los miembros primarios o secundarios del set de réplicas.
Advertencia
El uso de una arquitectura de primario-secundario-árbitro (PSA) para fragmentos en un clúster puede provocar una pérdida de disponibilidad si un secundario que almacena datos no está disponible. Un clúster PSA se diferencia de un set de réplicas típico: en un clúster fragmentado, los fragmentos realizan w: majority operaciones de nivel de confirmación de escritura que no pueden completarse si los miembros restantes del clúster necesarios para confirmar una operación tienen un árbitro.
Para agregar un árbitro, consultar Agregar un árbitro a un set de réplicas autogestionado.
Consideraciones sobre la versión de lanzamiento
Los árbitros no son compatibles con las versiones rápidas trimestrales. Si su implementación incluye árbitros, utilice únicamente Lanzamientos LTS.
Problemas de rendimiento con sets de réplicas de PSA
Si está utilizando una arquitectura de tres nodos de primario-secundario-árbitro (PSA), considere lo siguiente:
El nivel de confirmación de escritura
"majority"puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulta Mitigar problemas de rendimiento con un set de réplicas de PSA autogestionado.Si estás utilizando un
"majority"global por defecto y el nivel de confirmación de escritura es menor que el tamaño de la mayoría, tus consultas pueden devolver datos obsoletos (no completamente replicados).
Claves de partición, transacciones y árbitros
No puedes cambiar una clave de fragmentación mediante una transacción si el set de réplicas tiene un árbitro. Los árbitros no pueden participar en las operaciones de datos requeridas para las transacciones de múltiples fragmentos.
Las transacciones cuyas operaciones de escritura abarcan varios fragmentos generarán un error y se abortarán si alguna operación de transacción lee o escribe en una partición que contiene un árbitro.
Preocupaciones con múltiples árbitros
Utiliza un único árbitro para evitar problemas de coherencia de datos. Varios árbitros impiden el uso confiable del nivel de confirmación de escritura (write concern) de mayoría.
Para asegurarse de que una escritura persista tras el fallo de un nodo primario, el nivel de confirmación de escritura (write concern) requiere que la mayoría de los nodos reconozcan una operación de escritura. Los árbitros no almacenan ningún dato, pero contribuyen a la cantidad de nodos en un set de réplicas. Cuando un set de réplicas tiene múltiples árbitros, es menos probable que la mayoría de los nodos con datos estén disponibles tras un fallo de nodo.
Advertencia
Si un nodo secundario se retrasa con respecto al primario, y el clúster esreconfigured, los votos de múltiples árbitros pueden elegir el nodo que se había quedado atrás. El nuevo primario no tendrá los guardados no replicados aunque los guardados podrían haber sido confirmados en su mayoría por la configuración anterior. El resultado es la pérdida de datos.
Para evitar este escenario, se debe usar como máximo un único árbitro.
Novedades en la versión 5.3.
A partir de MongoDB 5.3, el soporte para múltiples árbitros en un set de réplicas está desactivado por defecto. Si se intenta agregar varios árbitros a un set de réplicas, el servidor devuelve un error:
MongoServerError: Multiple arbiters are not allowed unless all nodes were started with --setParameter 'allowMultipleArbiters=true'
Para añadir varios árbitros a un set de réplicas con MongoDB 5.3 o posterior, se debe iniciar cada nodo con el parámetro allowMultipleArbiters establecido en true:
mongod --setParameter allowMultipleArbiters=true
Seguridad
Autenticación
Cuando se ejecuta con authorization, los árbitros intercambian credenciales con otros miembros del conjunto para autenticarse. MongoDB cifra el proceso de autenticación, y el intercambio de autenticación de MongoDB es criptográficamente seguro.
Como los árbitros no almacenan datos, no poseen la tabla interna de asignaciones de usuarios y roles que se utiliza para la autenticación. Por lo tanto, la única forma de registro en un árbitro con autorización activa es utilizar la excepción de localhost.
Comunicación
La única comunicación entre los árbitros y otros miembros del conjunto son: los votos durante las elecciones, los latidos y los datos de configuración. Estos intercambios no están cifrados.
Sin embargo, si su implementación de MongoDB utiliza TLS/SSL, MongoDB cifrará toda la comunicación entre los miembros del conjunto de réplicas.Consulte Configurar mongod y mongos para TLS/SSL para obtener más información.
Como ocurre con todos los componentes de MongoDB, ejecuta árbitros en entornos de red de confianza.
Ejemplo
Por ejemplo, en el siguiente set de réplicas con 2 miembros que contienen datos (el primario y un secundario), un árbitro permite que el set tenga un número impar de votos para desempatar:
