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:
Tener una configuración maestro-maestro para MySQL
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?
Respuestas:
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 .
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
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 ;-)
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.
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
¡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 ...
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
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.
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.