En esta sección se describen estrategias comunes para la resolución de problemas. Implementaciones deconjuntos de réplicas.
Verifica el estado del set de réplicas
Para mostrar el estado actual del conjunto de réplicas y el estado actual de cada miembro, ejecute el comando rs.status() método en un
mongosh Sesión conectada al servidor principal del conjunto de réplicas. Para obtener descripciones de la información mostrada por,rs.status() consulte replSetGetStatus (comando de base de datos).
Nota
El método rs.status() es un contenedor que ejecuta el comando de base de datos replSetGetStatus.
Verifica el atraso de la replicación
El atraso de la replicación es un retraso entre una operación en el primario y la aplicación de esa operación desde el oplog al secundario. El atraso de la replicación puede ser un problema significativo y puede afectar seriamente las implementaciones de set de réplicas de MongoDB. El atraso de la replicación excesivo hace que los nodos “retrasados” no sean elegibles para convertirse rápidamente en primarios y aumenta la posibilidad de que las operaciones de lectura distribuidas sean incoherentes.
Para verificar la duración actual del atraso de la replicación:
En una sesión
mongoshque esté conectada al primario, llama al métodors.printSecondaryReplicationInfo().Devuelve el valor
syncedTopara cada nodo, que muestra la hora en que se escribió la última entrada de oplog en el secundario, como se muestra en el siguiente ejemplo:source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary Un miembro atrasado puede mostrarse como
0segundos detrás del primario cuando el período de inactividad en el primario es mayor que el valormembers[n].secondaryDelaySecs.Nota
El método
rs.status()es un contenedor alrededor del comando de base de datosreplSetGetStatus.totalOplogSlotDurationMicrosen el mensaje de registro de query lenta muestra el tiempo entre que una operación de escritura recibe una marca de tiempo para confirmar las escrituras del motor de almacenamiento y la confirmación real.mongodadmite escrituras paralelas. Sin embargo, confirma operaciones de escritura con marcas de tiempo de confirmación en cualquier orden.Ejemplo
Por ejemplo, considere las siguientes opciones de guardado con marcas de tiempo de confirmación:
writeA con Timestamp1
writeB con Timestamp2
writeC con Timestamp3
Supongamos que writeB realiza su primera confirmación en Timestamp2. La replicación se pausa hasta que se produzca la confirmación de writeA porque se requiere la entrada de oplog de writeA con Timestamp1 para que la replicación copie el oplog a los nodos secundarios del set de réplicas.
Supervise la tasa de replicación verificando valores de tiempo de registro de operaciones distintos de cero o en aumento en el Replication Lag Gráfico disponible en Cloud Manager y en Ops Manager.
Causas de atrasos de la replicación
Entre las posibles causas de atrasos de la replicación, se incluyen:
Latencia de la red
Verifica las rutas de red entre los nodos del set para asegurarte de que no haya ningún problema de pérdida de paquetes ni de enrutamiento de red.
Utiliza herramientas como
pingpara probar la latencia entre los nodos del set ytraceroutepara exponer el enrutamiento de paquetes a los nodos de red.Rendimiento de disco
Si el sistema de archivos y el dispositivo de disco en el secundario no pueden vaciar datos en el disco tan rápido como el primario, el secundario tendrá dificultades para mantener el estado. Los problemas relacionados con los discos son increíblemente frecuentes en los sistemas multiinquilino, incluidas las instancias virtualizadas, y pueden ser transitorios si el sistema accede a los dispositivos de disco a través de una red IP (como ocurre con el sistema EBS de Amazon).
Utiliza herramientas a nivel del sistema para evaluar el estado del disco, incluidos
iostatovmstat.Simultaneidad
En algunos casos, las operaciones de larga duración en el primario pueden bloquear la replicación en los secundarios. Para obtener los mejores resultados, configura el nivel de confirmación de escritura (write concern) para que solicite la confirmación de la replicación a los secundarios. Esto impide que se devuelvan las operaciones de escritura si la replicación no puede seguir el ritmo de la carga de escritura.
También puedes utilizar el perfilador de base de datos para ver si hay queries lentos u operaciones de larga duración que correspondan a las incidencias del retraso.
Nivel de confirmación de escritura (write concern) apropiado
Si estás realizando una ingestión de datos de gran tamaño o una operación de carga masiva que requiere un gran número de escrituras en el primario, en particular con
unacknowledged write concern, los secundarios no podrán leer el oplog lo suficientemente rápido para mantenerse al día con los cambios.Para evitar esto, solicita nivel de confirmación de escritura (write concern) cada 100, 1000 u otro intervalo para darles a los secundarios la oportunidad de alcanzar al primario.
Para obtener más información, consulta:
Control de flujo
A partir de MongoDB,4.2 los administradores pueden limitar la velocidad a la que el servidor principal aplica sus escrituras con el objetivo de mantener el retraso por debajo de un valor majority
committed máximo flowControlTargetLagSeconds configurable.
Por defecto, el control de flujo es enabled.
Con el control de flujo habilitado, a medida que el retraso se acerca a flowControlTargetLagSeconds, las escrituras en el primario deben obtener tickets antes de tomar bloqueos para aplicar las escrituras. Al limitar el número de tickets emitidos por segundo, el mecanismo de control de flujo intenta mantener el retraso por debajo del objetivo.
El atraso de la replicación puede producirse sin que el set de réplicas reciba suficiente carga como para activar el control del flujo, como en el caso de un secundario que no responde.
Para ver el estado del control de flujo, ejecuta los siguientes comandos en el primario:
Ejecuta el método
rs.printSecondaryReplicationInfo()para determinar si algún nodo está retrasado:rs.printSecondaryReplicationInfo() Ejemplo de salida:
source: 192.0.2.2:27017 { syncedTo: 'Mon Jan 31 2022 18:58:50 GMT+0000 (Coordinated Universal Time)', replLag: '0 secs (0 hrs) behind the primary ' } --- source: 192.0.2.3:27017 { syncedTo: 'Mon Jan 31 2022 18:58:05 GMT+0000 (Coordinated Universal Time)', replLag: '45 secs (0 hrs) behind the primary ' } Ejecuta el comando
serverStatusy utiliza el valorflowControl.isLaggedpara determinar si el set de réplicas ha activado el control de flujo:db.runCommand( { serverStatus: 1 } ).flowControl.isLagged Ejemplo de salida:
false Si el control de flujo no se ha activado, investiga el secundario para determinar la causa del atraso de la replicación, como las limitaciones en el hardware, la red o la aplicación.
Para obtener información sobre las estadísticas de control de flujo, consulta:
Aplicación lenta de entradas del Oplog
Los miembros secundarios de un set de réplicas ahora registran entradas de oplog que tardan más que el umbral de una operación lenta en aplicarse. Estos mensajes lentos del oplog:
Se registran para los secundarios en el
diagnostic log.Se documentan en el registro bajo el componente
REPLcon el textoapplied op: <oplog entry> took <num>ms.No depende de los niveles de registro (ya sea a nivel del sistema o del componente)
No depende del nivel de perfil.
Se ven afectados por
slowOpSampleRate.
El perfilador no captura entradas lentas del oplog.
Prueba conexiones entre todos los nodos
Todos los nodos de un set de réplicas deben poder conectarse a todos los demás nodos del set para admitir la replicación. Verifica siempre las conexiones en ambas “direcciones”. Las topologías de red y las configuraciones de firewall pueden evitar la conectividad normal y necesaria, lo que puede bloquear la replicación.
Advertencia
Antes de vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar la infraestructura de red.
Los binarios de MongoDB, mongod y mongos, se enlazan a localhost por defecto. Si se establece el ajuste del archivo de configuración net.ipv6 o la opción de línea de comandos --ipv6 para el binario, el binario se vincula además a la dirección IPv6 de localhost.
Por defecto, mongod y mongos que están vinculados a localhost solo aceptan conexiones de clientes que se ejecutan en el mismo ordenador. Este comportamiento de vinculación incluye mongosh y otros nodos del set de réplicas o clúster. Los clientes remotos no pueden conectarse a binarios que están vinculados únicamente a localhost.
Para anular la vinculación por defecto y enlazar a otras direcciones IP, utiliza la configuración del archivo de configuración net.bindIp o la opción de línea de comandos --bind_ip para especificar una lista de nombres de host o direcciones IP.
Advertencia
A partir de MongDB 5.0, los nodos DNS de horizonte dividido que solo están configurados con una dirección IP fallan en la validación de inicio y reportan un error. Consulta disableSplitHorizonIPCheck.
Por ejemplo, la siguiente instancia de mongod se vincula tanto al localhost como al nombre de host My-Example-Associated-Hostname, que está asociado con la dirección IP 198.51.100.1:
mongod --bind_ip localhost,My-Example-Associated-Hostname
Para conectarse a esta instancia, los clientes remotos deben especificar el nombre de host o su dirección IP asociada 198.51.100.1:
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
Considera el siguiente ejemplo de una prueba bidireccional de redes:
Ejemplo
En un set de réplicas con tres nodos que se ejecutan en tres hosts distintos:
m1.example.netm2.example.netm3.example.net
Los tres utilizan el puerto por defecto 27017.
Prueba la conexión de
m1.example.netcon los otros hosts mediante el siguiente set de operacionesm1.example.net:mongosh --host m2.example.net --port 27017 mongosh --host m3.example.net --port 27017 Prueba la conexión de
m2.example.netcon los otros dos hosts mediante el siguiente set de operaciones desdem2.example.net, como en:mongosh --host m1.example.net --port 27017 mongosh --host m3.example.net --port 27017 Ya probaste la conexión entre
m2.example.netym1.example.neten ambas direcciones.Prueba la conexión de
m3.example.neta los otros dos hosts mediante el siguiente set de operaciones desde el hostm3.example.net, como en:mongosh --host m1.example.net --port 27017 mongosh --host m2.example.net --port 27017
Si se produce un error en alguna conexión, en cualquier dirección, verifica la configuración de red y firewall, y vuelve a configurar tu entorno para permitir estas conexiones.
Excepciones de sockets al reiniciar más de un secundario
Cuando reinicies los nodos de un set de réplicas, asegúrate de que el set pueda elegir un primario durante el mantenimiento. Esto significa garantizar que la mayoría de los members[n].votes del set estén disponibles.
Cuando los nodos activos de un set ya no pueden formar una mayoría, el primario del set se retira y se convierte en secundario. El primario no cierra las conexiones de los clientes cuando se retira.
Los clientes no pueden escribir en el set de réplicas hasta que los nodos elijan un nuevo primario.
Ejemplo
Dado un set de réplicas de tres nodos en el que cada nodo tiene un voto, el set puede elegir un primario si al menos dos nodos pueden conectarse entre sí. Si reinicias los dos secundarios a la vez, el primario se retira y se convierte en secundario. Hasta que al menos otro secundario esté disponible, es decir, al menos una de las secundarias reiniciadas también esté disponible, el set no tiene primario y no puede elegir un nuevo primario.
Para obtener más información sobre los votos, consulta Elecciones de sets de réplicas. Para obtener información relacionada sobre errores de conexión, consulta ¿El tiempo TCP keepalive afecta a las implementaciones de MongoDB?
Verifica el tamaño del oplog
Un oplog más grande puede proporcionar a un set de réplicas una mayor tolerancia al atraso y hacerlo más resiliente.
Para verificar el tamaño del oplog de un nodo determinado del set de réplicas, conéctate al nodo en mongosh y ejecuta el método rs.printReplicationInfo().
El resultado muestra el tamaño del oplog y los rangos de fechas de las operaciones contenidas en el oplog. En el siguiente ejemplo, el oplog pesa unos 10 MB y puede admitir unas 26 horas (94 400 segundos) de operaciones:
configured oplog size: 10.10546875MB log length start to end: 94400 (26.22hrs) oplog first event time: Mon Mar 19 2012 13:50:38 GMT-0400 (EDT) oplog last event time: Wed Oct 03 2012 14:59:10 GMT-0400 (EDT) now: Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)
El oplog debe ser lo suficientemente largo para admitir todas las transacciones durante el tiempo de inactividad más largo que esperas en un secundario. [1] Como mínimo, un oplog debe poder mantener un mínimo de 24 horas de operaciones; sin embargo, muchos usuarios prefieren disponer de 72 horas o incluso una semana de trabajo de operaciones.
Para obtener más información sobre cómo afecta el tamaño del oplog a las operaciones, consulta:
Nota
Por lo general, conviene que el oplog sea del mismo tamaño para todos los nodos. Si cambias el tamaño del oplog, debes hacerlo en todos los nodos.
Para cambiar el tamaño del oplog, consulta el tutorial Cambia el tamaño del oplog de los nodos del set de réplicas autogestionado.
| [1] | El oplog puede crecer más allá de su límite de tamaño configurado para evitar borrar el majority commit point. |