Clúster de MySQL con equilibrio de carga sin equilibrador de carga

10

Estoy buscando crear un clúster de MySQL con equilibrio de carga, pero sin el equilibrador de carga real, para no agregar otro punto de falla o complejidad.

Lo que estaba pensando era tener lo siguiente:

  1. Tener una configuración maestro-maestro para MySQL

  2. En cada cliente, coloque un proxy simple round-robin que rotaría las solicitudes entre servidores.

es posible? ¿O hay mejores maneras de lograr esto?

mysql
fuente
Tengo curiosidad, ¿para qué lo vas a usar?
Intento agregar HA a nuestra solución, sin involucrar equilibradores de carga y cosas similares.

Respuestas:

3

Por favor leer mi otra respuesta a esta pregunta antes de utilizar un proxy MySQL de ningún tipo. Si tiene 2 servidores maestro-maestro en los que un CMS está escribiendo y 10 httpd que solo leen de él, estará bien, pero (como se señaló en la otra respuesta) ese no es siempre el caso. Has sido advertido.

MySQL Proxy es un programa simple que se encuentra entre su cliente y los servidores MySQL que pueden monitorear, analizar o transformar su comunicación. Su flexibilidad permite usos ilimitados; los comunes incluyen: equilibrio de carga; failover análisis de consultas; consulta de filtrado y modificación; y muchos más.

.

HAProxy es una solución gratuita, muy rápida y confiable que ofrece alta disponibilidad, equilibrio de carga y proxy para aplicaciones basadas en TCP y HTTP

Si lo ejecutas en modo TCP, podría ser incluso mejor que Wackamole. Si tuviera que elegir entre ellos, usaría HAProxy. También HAProxy puede tener muchos backends, Waclamole puede tener solo 2. Tenga en cuenta que HAProxy es "tonto", conecta enchufes sin mirar lo que hay dentro de la transmisión: el proxy MySQL dedicado podría tener una opción para apuntar varias solicitudes a servidores específicos .


fuente
Solo para verificar: 1) HAProxy requeriría una máquina adicional / 2 máquinas para HA 2) ¿Wackamole solo puede admitir 2 servidores por configuración? Saludos.
El patrón de uso estándar de Wackamole (de hecho, el único que conozco) es hacer que el servidor A y el servidor B se vigilen y tomen la IP del otro si muere. El sitio web de Wackamole dice que se puede usar para proteger un grupo de IP ... Pero debo decir que Wackamole no proporciona la estabilidad como uno quisiera, por lo que no recomiendo eso. Acerca de HAProxy, colocaría 2 de ellos en 2 máquinas dedicadas para redundancia, o incluso podría colocar uno en cada nodo, como dijo en la pregunta. Si sus consultas son en su mayoría de lectura, entonces creo que funcionará bastante bien.
Hola arrecife Solo un poco sobre Wackamole: según su experiencia, ¿no es lo suficientemente estable en dos máquinas?
2 máquinas hacen ping entre sí, pero una de ellas tiene una carga de 200, todas las CPU en un 100% de uso, todas las RAM utilizadas. MySQL ha fallado. <- wackamole NO funcionará allí. HAProxy puede verificar si la APLICACIÓN remota está activa, Wackamole solo si el servidor está activo y application_uptime <server_uptime. Tuvimos muchos casos en los que confiamos en wackamole y nos decepcionó.
4

Probablemente valga la pena mencionar, Galera Replication for MySQL para una verdadera configuración de MySQL multimaestro. Galera es un protocolo de replicación sincrónica, por lo que las aplicaciones pueden leer y escribir en cualquiera de los servidores MySQL. Aquí hay un tutorial rápido: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

En cuanto a los equilibradores de carga frente a los servidores MySQL, use un conector MySQL que admita esta funcionalidad (por ejemplo, Connector / J para Java o Mysqlnd para php)

Si no tiene un conector que pueda hacer esto, utilice algo como un proxy HA. Este script configura automáticamente el proxy HA y mantiene la lista de buenos servidores MySQL: https://github.com/severalnines/haproxy

Atentamente,

Vinay

www.severalnines.com

Vinay Joosery
fuente
Es importante que revele su asociación con el producto que está recomendando con mucha claridad. Además, este sitio no es para autopromoción. Si tiene un producto que resolvería un problema publicado, ¡genial! Si todas sus respuestas giran en torno a sus productos, es posible que desee hablar con alguien sobre cómo obtener espacio publicitario en lugar de publicar respuestas. Por favor vea nuestras preguntas frecuentes .
JNK
3

La replicación maestro-maestro no es tan buena como podría pensar, lo mismo ocurre con el proxy round-robin y soluciones 'fáciles' similares. Si confirma la colisión de datos en servidores separados lo suficientemente rápido (más rápido que la demora entre los servidores, que en servidores de producción puede ser de hasta un segundo completo *), ambos aceptarán los datos. Si tiene un servidor de subastas, acaba de vender el mismo automóvil dos veces . Quien lo compro? ¡Depende de qué DB preguntarás!

La aplicación debe tener en cuenta que en realidad hay 2 bases de datos y debe conocer sus dos direcciones IP. Si desea "vender", debe fe

DB_number = `auction_number` % `number_of_databases`

( %es para modulo)

... y confirmarlo en la base de datos DB_number. Si obtiene un error de conexión, quizás lo haga con el otro (pero en el caso de un servidor de subastas, solo mostraría un error).

Además, las direcciones IP deben ser wackamole -d entre ambos servidores. En un escenario de desastre, donde un servidor de base de datos deja de funcionar durante un par de horas en el tiempo de uso máximo, encontrará que la aplicación intentará conectarse al servidor ausente y se bloqueará hasta que se agote el tiempo de espera, digamos, 3 segundos. De repente, la mitad de sus consultas se ejecutan 3 segundos más (y eventualmente todas van a la misma base de datos, lo que no hace que se ejecute más rápido que antes del desastre). Esto no hace feliz a su httpd, ya que probablemente tiene un grupo limitado de conexiones de subprocesos de controlador de solicitudes simultáneas ...

* el retraso de la replicación en los servidores de producción puede ser de hasta un segundo completo : lo probé en una ubicación remota y en nuestro centro de datos y durante aproximadamente el 99% del tiempo es 0, pero a veces mysql muestra 1s. En el tráfico masivo tuve muchas colisiones debido a que la aplicación del cliente realizó dos solicitudes que dieron como resultado dos consultas, insertar y seleccionar. En algunos casos, la fila todavía no estaba allí , por lo que utilizamos el hash del ID de usuario y solucionó el problema

Espero que aprendas de mis errores ;-)


fuente
Hola. Gracias por compartir. Pensé en Wackamole, que en realidad es bueno para HA. Mi problema con esto es que toda la carga estaría en uno de los servidores maestros, cuando el segundo estaría inactivo, básicamente creando activo / pasivo, mientras estoy buscando activo / activo. ¿Quizás sea mejor colocar alguna solución LB ligera en cada cliente, para permitirle cambiar las solicitudes entre los servidores? ¿Alguna idea de si existe tal herramienta?
Si necesita redundancia, entonces "uno funcionando, uno inactivo" es bueno. Digamos que uno de los 2 servidores muere (le recuerdo que compró el otro, por lo que si el primero se rompe, aún puede funcionar). Si el segundo servidor no puede manejar todo el tráfico, entonces es para escalar, ¡no para HA! Además: confiar solo en Wackamole es una mala solución (ping ok! = Mysqld ok).
3

Un clúster de base de datos MySQL con equilibrio de carga (o algún otro) es bastante inútil. Si está escribiendo en más de un servidor, entonces se encontrará con problemas o utilizará la replicación sincrónica (que MySQL no admite de todos modos), y eso perjudica mucho el rendimiento ya que necesita sincronizar bloqueos.

Le recomiendo que divida las cargas de lectura / escritura, y equilibre la carga de las lecturas entre los esclavos mysql, y que tenga un solo maestro para las escrituras, o use un par de conmutación por error activo / pasivo para su maestro.

Esencialmente, no puede escalar las escrituras colocando más servidores en una base de datos como esclavos, ya que cada uno aún tiene que escribir la carga de escritura completa de su aplicación.

Para escalar las escrituras, necesita dividir sus datos de manera lógica en varios servidores, particionando o "fragmentando", etc. necesito.

Por supuesto, puede usar el clúster MySQL si realmente lo desea, pero es un motor completamente diferente con sus propias características e inconvenientes: es un poco complicado de configurar, pero realmente proporciona una base de datos de equilibrio de carga HA en hardware básico. Todavía sufre penalizaciones en el rendimiento de la escritura por el uso de la replicación sincrónica, pero le permite escalar las escrituras ya que ha incorporado particiones en los servidores.


fuente
3

Otra gran guía sobre este tema que he encontrado ...

http://www.dancryer.com/2010/01/mysql-circular-replication

Esta es la parte 1 de una serie de tres publicaciones:

  • MySQL Load-Balanced Cluster Guide - Part 1 - configurando los propios servidores y configurando la replicación MySQL.

  • MySQL Load-Balanced Cluster Guide - Part 2 - configure un script para monitorear el estado de sus nodos de cluster MySQL, que usaremos en la siguiente guía para configurar nuestro proxy.

  • MySQL Load-Balanced Cluster Guide - Part 3 - configurando el balanceador de carga con HAProxy, usando los scripts de monitoreo

dvb
fuente
2

¡Personalmente, la mejor manera sería usar un equilibrador de carga!

Sí, agrega otro punto de falla, pero cualquier rutina que establezca o instale en CADA cliente agrega mucha más complejidad que un equilibrador de carga estándar ...


fuente
Tiene sentido, pero el problema es el único punto de falla, incluso con 2 LB ... En caso de que uno de los clientes caiga, solo impactó y nadie más.
Es difícil mantener LB en cada nodo. Si instala un LB en 12 servidores y luego desea cambiar algo (dirección de uno de los DB o agregar un DB o algo), notará el problema. Yo hice.
1

Connector / J tiene la capacidad de realizar consultas de equilibrio de carga en varios servidores. Esto está destinado principalmente para MySQL NDB Cluster, donde todos los nodos SQL tendrán una vista coherente de los datos, pero si puede asegurarse de que la base de datos de dos maestros sea razonablemente consistente entre estos dos maestros, podría ser segura para su aplicación.

La cadena de conexión se vería así:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000


fuente
0

Dividir las escrituras no quitará la carga de los servidores porque las escrituras aún deben replicarse.

Si usa solo 2 servidores, use heartbeat con drbd y deje que drbd maneje la replicación. Si el primer servidor falla, el segundo servidor se hará cargo. Si desea utilizar el segundo servidor, puede usar gfs sobre drbd y luego ejecutar el segundo servidor como solo lectura y usarlo como servidor de lectura. Cuando se produce la conmutación por error, cambie el servidor a lectura / escritura.

re: wackamole - wackamole no está limitado a 2 servidores

Estoy trabajando en una serie de tutoriales que cubren esto, pero es muy fácil de configurar.


fuente
Sí, en teoría, wackamole puede soportar más de 2 servidores, pero ¿alguna vez has intentado esto en producción? Lo hicimos. Ahora nos arrepentimos.
Hasta ahora no he tenido problemas, aparte del hecho de que no puedo hacer que compile bajo centos 5 de 64 bits
0

Para dar una respuesta más reciente a esta pregunta, con la versión 5.6 de MySQL, introdujo GTID (Identificadores de transacciones globales) que tienen como objetivo hacer que la replicación asincrónica sea más robusta y poner a MySQL en la carrera por HA (alta disponibilidad) nuevamente.

Esta sección explica la replicación basada en transacciones utilizando identificadores de transacciones globales (GTID). Cuando se utilizan GTID, cada transacción se puede identificar y rastrear a medida que se confirma en el servidor de origen y se aplica por cualquier esclavo; esto significa que no es necesario cuando se usan GTIDs para referirse a archivos de registro o posiciones dentro de esos archivos al iniciar un nuevo esclavo o fallar a un nuevo maestro, lo que simplifica enormemente estas tareas. Debido a que la replicación basada en GTID está completamente basada en transacciones, es simple determinar si los maestros y esclavos son consistentes; siempre que todas las transacciones confirmadas en un maestro también se confirmen en un esclavo, se garantiza la coherencia entre ambos. Puede usar la replicación basada en sentencias o en filas con GTID (consulte la Sección 16.2.1, “Formatos de replicación”); sin embargo, para mejores resultados,

Referencia: 16.1.3 Replicación con identificadores de transacciones globales (documentación de MySQL)

Pensé que el uso de HAProxy para consultas de equilibrio de carga está introduciendo un SPOF (Punto único de falla), y agregar latidos hace que esta solución sea engorrosa.

Una solución más simple es conectarse a través del conector JConnector de Java que tiene como objetivo realizar consultas de equilibrio de carga a través de una url jdbc con todos los nodos MySQL. Puede manejar configuraciones maestro / esclavo o maestro / maestro .

Eso hace posible configurar una solución de clúster HA fuera de la caja con MySQL.

Jérôme B
fuente