MySQL proxy y show de procesos de la lista de procesos

Question

Actualmente tengo una replicación de MySQL entre dos maestros bidireccionalmente, uno en un centro de datos localmente, otro en Amazon EC2.

Todo parece funcionar normalmente en cuanto a la replicación, sin problemas per se, excepto la consulta ocasional que causa una colisión, pero son pocas y distantes. Recientemente configuré MySQL-Proxy para intentar equilibrar los dos servidores, el equilibrio de carga realmente en el inicio después de que la máquina local recibe 40 o más conexiones en el cual el punto que las conexiones de base de datos posteriores se arrastran a la máquina EC2.

Algo que notamos recientemente es que MySQL Proxy nos notificará que hay 41 conexiones y luego comenzar a equilibrar. Sin embargo, cuando me conecto a la máquina local y hago un SHOW PROCESSLIST; Puede solo proporcionarme 30 conexiones.

¿Alguien tiene alguna idea de por qué esto tal vez?

Además de eso como resultado de emitir el SHOW PROCESSLIST; Comando He notado que hay muchas consultas que se ejecutan en ambas máquinas que indican que han estado ejecutando más de 5000 segundos. Estoy bastante seguro de que estas son consultas de "zombie", pero ¿alguien sabe por qué se crean en primer lugar?

Para su información, estamos ejecutando MySQL versión 5.1.54 en las últimas versiones de Ubuntu y Debian.

Cualquier idea sería extremadamente útil.

Apéndice

Resulta que no estamos usando mysql_pconnect y estamos de hecho usando las bibliotecas mysqli. Todavía no he podido averiguar por qué sucede esto e informaré una vez que lo descubra.

Answer 1

Estoy en contra de escribir a ambos maestros en una configuración de dual-maestro. Hay demasiadas cosas que pueden salir mal, y pueden ser desordenadas para solucionar: auto_incrementos, otras teclas duplicadas, etc.

Cientos de conexiones de "sueño" prácticamente no tienen impacto en un servidor, por lo que limitar a 40 no es útil. 10 o más activo Las conexiones (sin sueño) pueden ser un problema. En ese caso, miraría las consultas. Por lo general, optimizar las consultas es la mejor respuesta.

Tenga en cuenta también que cada escritura (inserción, actualización, etc.) que se realiza en un maestro debe hacerse en todos los demás maestros y esclavos. Entonces, realmente no puedes "difundir".

Si tiene procesos que solo realizan (selecciona), entonces deben ir a esclavos y/o al maestro de copia de seguridad, no al maestro en vivo, witable,. Esto ayudará.

Tenga en cuenta el problema de "escritura crítica". Ejemplo: un usuario publica un comentario de blog, luego mira sus comentarios, pero falta. Esto puede suceder si la escritura fue a una máquina, pero la lectura llegó a otra, y la replicación está "detrás".

(Mis comentarios se aplican a todas las versiones, y a todas las API, no solo 5.1 y MySQLI de PHP).

Me mantengo alejado de mysql_pconnect (y otros mecanismos de agrupación de conexión). El inicio/desmontaje de la conexión es muy rápido en MySQL. Las conexiones agrupadas pueden tener problemas con @variables, modos de transacción, sql_modes, etc.