MySQL Cluster: solución MySQL Cluster para bases de datos MySQL
Existen muchas opciones oficiales y de terceros para soluciones de clúster MySQL, y tener demasiadas opciones puede ser una molestia. Por lo tanto, creemos que la base de datos MySQL debe cumplir los siguientes tres requisitos y examinar soluciones viables en el mercado:
Alta disponibilidad: el servidor principal puede cambiar automáticamente al servidor de respaldo después de una falla Escalabilidad: servidor de base de datos Equilibrio de carga : Admite el cambio manual de las solicitudes de datos de una empresa a otro servidor y puede configurar qué servicio de datos de la empresa accede a qué servidor. Agregue equilibrio de carga del servidor DB: admita el cambio manual de las solicitudes de datos de una empresa a otro servidor y configure qué servicio de datos de la empresa accede a qué servidor
Debe elegir una solución que cumpla con los requisitos anteriores Requerir.
Teniendo en cuenta todos los factores, decidimos realizar un estudio preliminar utilizando las soluciones MySQL Fabric y MySQL Cluster, así como otra solución de clustering más madura, Galera Cluster.
2. MySQLCluster
Introducción:
MySQL Cluster es el programa oficial de implementación de clústeres MySQL y tiene una larga historia. Admite escalamiento de lectura/escritura mediante fragmentación automática y datos redundantes mediante copia de seguridad en tiempo real, lo que la convierte en la solución de mayor disponibilidad con disponibilidad de hasta 99,999.
Principios de arquitectura e implementación:
El clúster MySQL se compone principalmente de tres tipos de servicios:
Servidor de administración NDB: el servidor de administración se utiliza principalmente para administrar otros tipos en los nodos del clúster (nodos de datos y nodos SQL) que le permiten configurar nodos, configurar información de nodos e iniciar y detener nodos. Nodo SQL: en el clúster MySQL, el nodo SQL es un proceso del servidor MySQL que utiliza el motor NDB, que se utiliza para proporcionar a las aplicaciones externas acceso a los datos del clúster: Nodo de datos: se utiliza para almacenar datos del clúster, el sistema intentará conservar los datos; en la memoria.
Desventajas y limitaciones:
Para las tablas que requieren fragmentación, es necesario modificar el motor Innodb a NDB, mientras que las tablas que no requieren fragmentación no necesitan modificarse. El nivel de aislamiento de transacciones de NDB solo admite lecturas confirmadas, lo que significa que las modificaciones en la transacción no se pueden consultar antes de que se confirme la transacción; Innodb admite todos los niveles de aislamiento de transacciones y usa lecturas repetibles de forma predeterminada, por lo que este problema no existe. Compatibilidad con claves externas: aunque las últimas versiones del clúster ya admiten claves externas, existen problemas de rendimiento (ya que el registro relacionado con la clave externa puede estar en otro nodo de fragmento), por lo que se recomienda eliminar todas las claves externas. Los datos del nodo de datos se colocarán en la memoria tanto como sea posible, lo que requiere mucha memoria.
El sistema de base de datos proporciona cuatro niveles de aislamiento de transacciones:
A. Serializable: una transacción es completamente invisible para otras transacciones cuando se realizan actualizaciones de la base de datos (no se permiten otras transacciones durante la transacción). ejecución) Las transacciones se ejecutan simultáneamente). Ejecución de serialización de transacciones: las transacciones solo se pueden ejecutar una tras otra y no se pueden ejecutar al mismo tiempo). .
B. Lectura repetible: una transacción puede ver los registros recién insertados enviados por otras transacciones durante la ejecución, pero no puede ver las actualizaciones de los registros existentes de otras transacciones.
C. Lectura confirmada (leer datos confirmados): durante la ejecución de una transacción, puede ver los registros recién insertados que han sido enviados por otras transacciones y también puede ver los registros existentes que han sido enviados por otras transacciones.
D. Leer datos no confirmados (leer datos no confirmados): durante la ejecución, una transacción puede ver registros recién insertados que aún no han sido confirmados por otras transacciones y también puede ver actualizaciones de registros existentes que aún no se han confirmado. por otras transacciones.
3. MySQL Fabric
Introducción:
Para implementar y facilitar la gestión de la fragmentación de MySQL y la implementación de alta disponibilidad, Oracle ha lanzado un conjunto de Los productos MySQL, MySQL Fabric, tienen grandes esperanzas por parte de todas las partes. Se utiliza para administrar servicios MySQL y proporcionar escalabilidad. Fabric actualmente implementa dos funciones: alta disponibilidad y el uso de fragmentación de datos para lograr escalabilidad y equilibrio de carga. Se puede utilizar de forma independiente o combinada.
MySQL Fabric se implementa a través de una serie de scripts en Python.
Ejemplos de aplicaciones: dado que la solución se lanzó el año pasado, no hay ejemplos de aplicaciones de grandes empresas para buscar en línea.
Principios de arquitectura e implementación:
El diagrama de arquitectura del soporte de Fabric para alta disponibilidad es el siguiente:
Fabric utiliza grupos de HA para lograr alta disponibilidad, uno de que es el servidor principal y el otro es el servidor de respaldo, que logra redundancia de datos mediante replicación sincrónica. La aplicación utiliza un controlador específico para conectarse al componente Connector de Fabric, que promueve automáticamente uno de los servidores de respaldo al servidor primario cuando el servidor primario falla, sin ninguna modificación en la aplicación.
La arquitectura de escalabilidad y equilibrio de carga de Fabric es la siguiente:
La fragmentación se implementa utilizando múltiples grupos de HA, cada grupo comparte diferentes datos (como se describe en Alta disponibilidad, Datos dentro de un grupo). es redundante)
Las aplicaciones solo necesitan enviar consultas e insertar declaraciones al conector. El conector asigna automáticamente estos datos a grupos a través de MasterGroup, o fusiona los datos calificados en cada grupo y los devuelve a la aplicación.
Desventajas y limitaciones:
Las dos limitaciones que tienen un mayor impacto son:
Las claves de crecimiento automático no se pueden utilizar como claves de fragmentos y las consultas sí; Solo admitido dentro del mismo fragmento, los datos actualizados en la transacción no pueden cruzar fragmentos y los datos devueltos por la declaración de consulta no pueden cruzar fragmentos.
Prueba de alta disponibilidad
Arquitectura del servidor:
Características
IP
Puertos
Almacenamiento de respaldo (guarda la información de configuración de cada servidor)
200.200.168.200.168.25
3306
El proceso de instalación se omite A continuación se describe cómo. configure un grupo de alta disponibilidad, agregue un servidor de respaldo y otros procesos.
Primero, cree un grupo de alta disponibilidad, por ejemplo, el nombre del grupo es group_id-1, el comando es:
Agregue las máquinas 200.200.168.25 y 200.200.168.23 al grupo group_id-1:
mysqlfabric group add group_id-1 200.200.168.25:3306
mysqlfabric group add group_id -1 200.200.168.23:3306
Luego verifique el estado de las máquinas en el grupo:
Dado que el maestro no está configurado, el estado de ambos servicios es SECUNDARIO
Promueve uno de ellos a maestro:
mysqlfabric group promociona group_id-1 --slave_id 00f9831f-d602-11e3-b65e-0800271119cb
Luego verifique el estado nuevamente:
El servicio que se configuró como servidor principal se ha convertido en Primario.
Además, el atributo de modo indica si el servidor está en modo de lectura y escritura (READ_WRITE) o en modo de solo lectura (READ_ONLY). El modo de solo lectura significa que la presión de consultar datos se puede distribuir; sólo el servidor principal se puede configurar en modo lectura-escritura (READ_WRITE).
En este punto, verifique el estado esclavo del servidor 25:
Puede ver que su maestro ha sido apuntado al 23
Luego active la función de conmutación por error:
mysqlfabric group enable group_id-1
Una vez activado, podrás probar la alta disponibilidad del servicio.
Primero, realice una prueba de estado:
Detenga el servidor maestro 23
Luego verifique el estado:
Puede ver que 25 ha sido promovido automáticamente como servidor principal.
Pero si reinicia 23, deberá restablecer manualmente 23 como servidor maestro.
Prueba en tiempo real:
Propósito: probar el tiempo necesario para que el servidor de respaldo muestre los datos después de que el servidor principal actualice los datos
Caso de prueba: uso código java para establecer una conexión e inserte 100 registros en la tabla para ver cuánto tiempo le toma al servidor de respaldo sincronizar estos 100 datos
Resultados de la prueba:
Después de eso es un programa en ejecución en la tabla, verifique el número principal de entradas de datos en el servidor:
Por supuesto, el servidor maestro se actualizará inmediatamente.
Ver la cantidad de entradas de datos en el servidor de respaldo:
Pero el servidor de respaldo esperó entre 1 y 2 minutos para completar la sincronización (puede ver que Fabric usa replicación asincrónica, que es el método predeterminado, el rendimiento es mejor, el servidor principal no tiene que esperar a que regrese el servidor de respaldo, pero la velocidad de sincronización es más lenta)
Para el problema de estabilidad de la sincronización de datos del servidor esclavo, Existen las siguientes soluciones:
El uso de la mitad de la sincronización mejora la coherencia de los datos: la replicación asincrónica puede proporcionar un mejor rendimiento, pero el servidor maestro solo envía el registro binlog al servidor esclavo y la acción no termina. Verifique si el servidor esclavo ha completado la recepción, por lo que el riesgo es mayor. La replicación semisincrónica espera a que el esclavo envíe un acuse de recibo y luego regresa después de enviarlo al esclavo. Puede configurar cómo se actualiza el registro de sincronización en el dispositivo esclavo para reducir el retraso de sincronización del dispositivo esclavo y acelerar la sincronización. Instalar copia semisync:
Ejecutar en mysql
Instalar el complemento rpl_semi_sync_master soname 'semisync_master.so';
instalar el complemento rpl_semi_sync_slave soname 'semisync_slave.so';< / p>
Establecer rpl_semi_sync_master_enabled=ON global;
Establecer rpl_semi_sync_slave_enabled=ON global;
Cambiar my.cnf:
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
sync_relay_log=1
sync_relay_log_info= 1
sync_master_info=1
Prueba de estabilidad:
p>
Caso de prueba: use código Java para establecer una conexión, inserte 10,000 registros en una tabla, detenga uno de los servidores principales durante el proceso de inserción y verifique si hay estos 1,000 registros en el servidor de respaldo
Resultado de la prueba: después de detener el servidor principal, el programa java arroja una excepción.
El programa Java arroja una excepción:
Pero luego el comando sql se envía nuevamente y el resultado se devuelve exitosamente. Esto demuestra que fue sólo el negocio el que fracasó en ese momento. La conexión se cambió a un servidor de respaldo que todavía estaba disponible.
Revisando la documentación de mysql, hay una sección que menciona este problema:
Menciona que cuando el servidor principal caiga, nuestra aplicación no será modificada, pero sí perdidas Algunas transacciones pueden tratarse como errores normales de MySQL hasta que el servidor principal sea reemplazado por el servidor de respaldo.
Comprobación de la integridad de los datos:
Pruebe si el servidor de respaldo puede sincronizar todos los datos después de detener el servidor principal.
Justo ahora el servidor principal se detuvo y luego se reinició. Comprobando el número de registros
Puedes ver que se detuvo después de insertar 1059 registros.
Ahora observe la cantidad de registros en el servidor de respaldo para ver si todos los datos se pueden sincronizar después de que el servidor principal caiga.
Pasaron unas decenas de segundos antes de la sincronización. se completó y los datos no estuvieron disponibles de inmediato. Se sincronizaron, pero no se perdieron.
1.2.Fabric: Cómo soportar la escalabilidad y el equilibrio de carga
Introducción a FabricFabric: cuando una máquina o un grupo de máquinas no pueden soportar la presión del servicio, puede agregar servidores para compartir lecturas. Presión de escritura, Fabric La función Fabric le permite dispersar y almacenar datos en ciertas tablas en diferentes servidores. Podemos establecer las reglas de asignación para el almacenamiento de datos configurando la clave de fragmento en la tabla. Además, es posible que los datos de algunas tablas no necesiten fragmentarse, pero toda la tabla debe almacenarse en el mismo servidor. Puede configurar un grupo global para almacenar estos datos. Los datos almacenados en el grupo global se copiarán automáticamente. todos los demás fragmentos en el set de filmación.
4.Galera Cluster
Introducción:
Se dice que Galera Cluster es la solución de clúster de bases de datos de código abierto más avanzada del mundo.
Principalmente Ventajas y funciones:
Modo de servicio multimaestro verdadero: se pueden leer y escribir múltiples servicios al mismo tiempo, a diferencia de Fabric, en el que algunos servicios solo se pueden usar como copias de seguridad. Replicación sincrónica: sin latencia, sin pérdida de datos. Espera activa: cuando un servidor deja de funcionar, el servidor de respaldo se hace cargo automáticamente, sin tiempo de inactividad. Escalado automático de nodos: al agregar un nuevo servidor, no es necesario copiar manualmente la base de datos al nuevo nodo Soporta InnoDB El motor es transparente para la aplicación: no es necesario modificar la aplicación
Principios de arquitectura e implementación:
Primero, veamos cómo usaremos InnoDB motor en el futuro. p>
Primero, echemos un vistazo a la arquitectura tradicional de MySQL basada en replicación:
La replicación copia el registro de actualización del servidor primario iniciando un hilo de replicación y luego lo transfiere. a la copia de seguridad Una forma de ejecución del servidor que corre el riesgo de perder transacciones y sincronizaciones inoportunas.
Tanto Fabric como la replicación maestro-esclavo tradicional adoptan este enfoque. Tanto Fabric como la replicación maestro-esclavo tradicional utilizan esta implementación.
Galera utiliza la siguiente arquitectura para garantizar la coherencia de las transacciones en todas las máquinas:
Los clientes acceden a la base de datos a través del balanceador de carga de Galera y cada transacción enviada se replica en todos los servidores a través de la API wsrep. Ejecutado en todos los servidores, se ejecuta correctamente en todos los servidores o se revierte en todos los servidores, lo que garantiza la coherencia de los datos para todos los servicios y todos los servidores sincronizan las actualizaciones de datos en tiempo real.
Desventajas y limitaciones:
Debido a que la misma transacción debe ejecutarse en varias computadoras en el clúster, la transmisión de red y la ejecución simultánea pueden causar algunas pérdidas de rendimiento. Los mismos datos se almacenan en todas las máquinas y existe una redundancia completa. Si una máquina se utiliza como servidor primario y como servidor de respaldo, la probabilidad de reversión causada por el bloqueo optimista aumenta, así que tenga cuidado al escribir su programa.
SQL no compatible: ¿bloquear/desbloquear tabla/get_lock(), release_lock()? Las transacciones XA no son compatibles
Actualmente hay tres implementaciones basadas en el clúster Galera:
Utilizamos el clúster Percona más maduro para MySQL, que tiene más casos de uso. 200.200.168.24
3306
HA Maestro 2
200.200.168.25
3306
HA Maestro 3
200.200.168.23
3306
4.1 Probar la sincronización de datos
Crear una tabla en la máquina 24:
Verifique inmediatamente el 25 y descubra que se ha creado de forma sincrónica
Utilice el código Java para insertar 100 registros en el servidor 24
Verifique la cantidad de registros inmediatamente en el servidor 25
La sincronización de datos de Discover entra en vigor inmediatamente.
4.2.Prueba de agregar nodos del clúster
Agregar nodos del clúster es muy simple. Simplemente implemente el clúster Percona XtraDB en la máquina recién agregada e inícielo, y el sistema agregará automáticamente el existente. cluster para sincronizar los datos de la nueva máquina con la nueva máquina.
Ahora, para fines de prueba, detenga el servicio en uno de los nodos:
Luego use código java para insertar 100 W de datos en el clúster
Ver 100 W Tamaño de la base de datos de los datos:
Inicie otro nodo y sincronizará automáticamente los datos en el clúster al inicio:
Solo tarda unos 20 segundos en iniciarse, luego vea el tamaño de los datos. y número de registros de la tabla. El tamaño de los datos es el mismo y el número de registros de la tabla se ha sincronizado
Resumen de comparación
MySQL Fabric
Galera Cluster
Lanzado en mayo de 2014, actualmente no hay casos de aplicación de las principales empresas de Internet
El programa es relativamente maduro y es utilizado por muchas empresas de Internet extranjeras. Es relativamente maduro y lo utilizan muchas empresas extranjeras de Internet
Copia de seguridad de datos en tiempo real
Debido al uso de replicación asincrónica, generalmente hay un retraso de decenas de segundos, pero el Los datos no se perderán.
Sincronización en tiempo real, los datos no se perderán
Redundancia de datos
Usando fragmentación, se pueden dispersar diferentes datos de la misma tabla estableciendo reglas clave de fragmentación En varias máquinas
Redundancia total por nodo, no se requiere fragmentación
Alta disponibilidad
Fabric Connector a través del servidor maestro
El servidor principal automáticamente cambia cuando hay un corte. Cambia automáticamente cuando el servidor deja de funcionar, pero debido a retrasos en la copia de seguridad, es posible que los datos no se consulten inmediatamente después del cambio
Implementado mediante HAProxy. La disponibilidad de conmutación es mayor debido a la sincronización en tiempo real.
Escalabilidad
Después de agregar un nodo, primero debe copiar manualmente los datos del clúster.
Expandir el nodo es muy simple. Los datos del clúster se sincronizarán automáticamente. cuando se inicia el nodo, 1 millón de datos (100 M) solo toma unos 20 segundos
Equilibrio de carga
Implementado a través de HASharding
Utilice HAProxy para lograr el equilibrio de carga<. /p>
Modificación del programa
p>Es necesario cambiar a jdbc: mysql: clase y URL de fabric jdbc
No es necesario modificar el programa
Comparación de rendimiento
Usar Java para insertar directamente en jdbc 100 filas lleva aproximadamente más de 2000 milisegundos
En comparación con operar directamente mysql:fabric. p> Al igual que operar mysql directamente, usar jdbc directamente para insertar 100 registros requiere aproximadamente 600 ms
6. Aplicación práctica
Según las ventajas y desventajas de las soluciones anteriores, preferimos Elegir Galera Si solo tiene dos servidores de bases de datos, puede considerar usar la siguiente arquitectura de base de datos para lograr alta disponibilidad, equilibrio de carga y expansión dinámica:
Si puede considerar tres máquinas: