Tengo 5 servidores dedicados (máquinas idénticas: 32 núcleos, 96 GB de RAM, unidades SSD en RAID y enlace gigabit ethernet) configurados con Percona XtraDB Cluster.
Hay un problema recurrente que causa una severa desaceleración del clúster por lo general entre 30 y 60 segundos, pero a veces se atasca por hasta 5 a 10 minutos.
El sistema se utiliza para una red ocupada de sitios web y uso mysql-proxy en cada servidor web para equilibrar la carga del tráfico a la base de datos.
El problema no existe si solo hay un nodo habilitado. En cambio, con cada nodo agregado, el problema aumenta en intensidad (cantidad de tiempo que las consultas se ralentizan/bloquean) hasta que se vuelve muy insoportable con 4 nodos activos (el clúster en este punto ya no puede recuperarse automáticamente).
Aquí están los síntomas detallados:
- Cada 5 a 15 minutos, todas las consultas de escritura (INSERT/UPDATE) se atascan en la cola de cada nodo. Algunas de las consultas se envían después de 45 a 50 segundos, mientras que otras quedan completamente detenidas.
- La mayoría de las veces, después de 30 a 60 segundos, el clúster de alguna manera puede ponerse al día y envía rápidamente las consultas en cuestión de 1 a 2 segundos.
- A veces, el clúster no puede manejar estas consultas atascadas automáticamente y necesito deshabilitar manualmente los sitios web más ocupados para que la carga se reduzca y después de 30 segundos de tener casi ninguna carga, el clúster puede nuevamente enviar todas las consultas.
Los registros de errores suelen estar limpios y no hay mensajes de error antes o después de que se produzca la desaceleración. Rara vez recibo algo como esto (tal vez 1 vez de cada 10):
130906 9:53:27 [Nota] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') activando la solicitud de retransmisión de mensajes, pares no activos: tcp://IPOFONEOFTHENODES
130906 9:53:27 [Nota] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') desactivando la solicitud de retransmisión de mensajes
Normalmente tengo un wsrep_cert_deps_distance de aproximadamente 400 bajo carga normal. Tan pronto como comienza la desaceleración, wsrep_cert_deps_distance aumenta lentamente hasta el rango de 2k-3k (cuando alcanza la marca de 3k necesito deshabilitar manualmente la aplicación o el clúster no podrá recuperarse por sí solo)
Monitoreando con mytop y atop no noto carga alta en el servidor ni en el proceso mysql. El uso de la CPU es siempre razonablemente bajo (alrededor del 25% del máximo) tanto durante el funcionamiento normal como durante las ralentizaciones. El uso de E/S está bien, mucha RAM libre, vmcom por debajo del límite.
Utilizo myq_status para monitorear el clúster en cada nodo en tiempo real y esto es lo que sucede:
- La variable wsrep_flow_control_paused siempre está en 0,0 incluso cuando se producen desaceleraciones.
- No se producen wsrep_local_bf_aborts ni wsrep_local_cert_failures.
- En cada nodo, la replicación saliente suele ser 0 y aumenta hasta 200-300 cuando se produce la desaceleración.
- La replicación entrante siempre es 0 en cada nodo (raramente 1, pero ocurre incluso bajo carga normal). Esto me desconcierta ya que aparentemente no hay ningún nodo lento en el grupo.
- Después de 10 a 15 segundos desde el comienzo de la desaceleración, las operaciones y los bytes enviados y recibidos pasan a ser 0 en cada nodo. Permanecen en 0 durante uno o dos segundos, luego se produce una mayor cantidad de operaciones y bytes en el segundo siguiente, junto con una gran cantidad de operaciones "oooe" (ejecución fuera de orden). Esto se repite cada pocos segundos hasta que el servidor vuelve a normal.
Aquí están los detalles de las pruebas que realicé para intentar solucionar el problema (sin suerte...):
- Primero verifiqué la red: los servidores están en el mismo rack con una red gigabit dedicada y todo parece estar funcionando bien, sin pérdida de paquetes u otros problemas aparentes de red.
- Verifiqué el uso del ancho de banda: cada nodo usa un promedio de 30 a 100 Mbps (megabit) de ancho de banda. Verifico en tiempo real con "iftop" y mientras ocurre el problema, el uso del ancho de banda suele ser inferior al promedio (15 a 30 Mbps). Mientras se sincroniza el ancho de banda de un nodo, sube a 800-900 Mbps (como debería ser), por lo que no creo que la red esté saturada.
- Probé una combinación de todos los nodos para asegurarme de que un nodo en particular estuviera afectando todo lo demás: el problema siempre está presente sin importar qué nodo desactive o use. El problema siempre está relacionado con la cantidad de nodos activos al mismo tiempo.
¿Alguien ha encontrado alguna vez un problema similar? ¡Gracias de antemano!