Teoría y práctica de soluciones de alta disponibilidad basadas en bases de datos MySQL dual-master
MySQL ha florecido en todas partes en las aplicaciones de Internet, pero en el sistema bancario aún está en la etapa de echar raíces. Este artículo registra las necesidades reales de un determinado sistema de producción, organiza y mejora la solución de alta disponibilidad Mysql a partir de las necesidades de la solución de alta disponibilidad de la base de datos, compara, implementa y prueba las características de varias tecnologías de alta disponibilidad, y También se prepara para pruebas posteriores relacionadas con bases de datos distribuidas. Esté preparado en consecuencia.
Tecnología de replicación de almacenamiento:
Tecnología de replicación de almacenamiento:
La arquitectura IOE tradicional, una solución de alta disponibilidad comúnmente utilizada, se basa en la tecnología de replicación de almacenamiento subyacente para Para lograr la replicación de datos, la ventaja es que la seguridad de los datos está garantizada, pero la limitación es que depende del hardware de almacenamiento y el costo de implementación es alto.
keepalived + replicación dual-master: la relación maestro-esclavo entre dos MySQL, es decir, modo dual-master, configure la IP virtual a través de Keepalived para cambiar automáticamente el VIP a otro MySQL cuando una de las bases de datos La base de datos falla y la máquina de respaldo se hace cargo rápidamente del negocio para garantizar una alta disponibilidad de la base de datos. La máquina en espera se hace cargo rápidamente del negocio para garantizar una alta disponibilidad de la base de datos.
MHA: MHA se implementa en cada servidor mysql y detecta periódicamente el nodo maestro en el clúster. Cuando un nodo maestro falla, automáticamente promueve el último nodo esclavo como el nuevo nodo maestro y luego redirige todos los demás nodos esclavos al nuevo nodo maestro. El cambio rápido y al mismo tiempo maximizar la coherencia de los datos requiere al menos 3 servidores y puede provocar la pérdida de datos.
PXC: Percona eXtra Cluster es la solución de clustering de Percona basada en el paquete de clustering galera. A diferencia de la replicación multimaestro ordinaria, PXC garantiza una sólida coherencia y sincronización en tiempo real, y acelera la conmutación por error. Sin embargo, también requiere 3 nodos, la configuración es relativamente compleja y tiene un ligero impacto en el rendimiento.
Además de los escenarios de aplicación anteriores, también existen escenarios de aplicación de alta disponibilidad como MMM y Heartbeat + DRBD, que no se presentarán en detalle aquí.
Después de una evaluación integral, este plan de implementación utiliza el control maestro dual keepalived + mysql para lograr una alta disponibilidad de bases de datos en salas de computadoras duales en la misma ciudad. Versión de MySQL: 5.7.21. Sistema operativo: Red Hat Enterprise Linux Server 7.3Red Hat Enterprise Linux Server 7.3
El proceso de configuración es el siguiente: Mysql-master1: dirección IP 1 - en adelante denominada master1
Mysql-master2: Dirección IP 2 - en adelante denominada master2
Mysql-vip: Dirección VIP - utilizada por la aplicación para conectarse
Descripción del concepto relacionado con la replicación de Mysql:
1. Diagrama de replicación maestro-esclavo de Mysql:
2. Descripción del proceso de replicación maestro-esclavo de Mysql:
(1) El maestro registra el registro binario: antes de cada transacción que se actualiza Se completan los datos. MySQL escribe transacciones en el registro binario. MySQL escribe transacciones en el registro binario. Después de que la transacción se escribe en el registro binario, el maestro notifica al motor de almacenamiento que confirme la transacción.
(2) El esclavo copia el registro binario del maestro en su propio registro de retransmisión: primero, el esclavo inicia un subproceso de trabajo (subproceso de E/S) y abre una conexión normal en el maestro. el proceso de volcado de binlog. El proceso de volcado de binlog lee las transacciones del registro binario del registro principal. Si el registro principal se ha sincronizado, se suspenderá y esperará a que se generen nuevos eventos en el registro principal.
(3) El último paso del proceso de procesamiento del subproceso esclavo SQL: el subproceso SQL lee la transacción del registro de retransmisión y reproduce la transacción para actualizar los datos en el subproceso esclavo para que sean consistentes con los datos. en el hilo maestro.
Siempre que el subproceso sea coherente con el subproceso de E/S, el registro de retransmisión suele estar en la memoria caché del sistema operativo, por lo que el registro de retransmisión tiene poca sobrecarga.
La sincronización maestro-maestro significa que dos máquinas actúan como maestras entre sí y las operaciones de escritura en cualquier máquina se sincronizarán con la copia de seguridad.
Para facilitar la expansión posterior del servidor de la base de datos, cambiar automáticamente todo el entorno de replicación y reducir los costos de operación y mantenimiento, se introduce la función de replicación principal actual basada en Mysql GTID. Las ventajas y desventajas se presentan a continuación.
3. El principio de funcionamiento de GTID es el siguiente:
(1) Cuando la estación maestra actualiza los datos, se generará un GTID antes de la transacción y se registrará en el registro Binlog.
(2) El subproceso de E/S de la estación esclava escribe el Binlog modificado en el registro de retransmisión local.
(3) El hilo SQL esclavo obtiene el GTID del registro de retransmisión y lo compara con el binlog del esclavo para ver si el GTID está registrado.
(4) Si hay un registro, la transacción para este GTID se ha ejecutado y el programa esclavo la ignorará.
(5) Si no hay ningún registro, el esclavo ejecuta la transacción con GTID en el registro de retransmisión y la registra en el binlog.
(6) Durante el proceso de análisis, determinará si la clave principal existe, si existe, usará el índice, si no, usará un escaneo completo.
4. Ventajas de GTID:
(1) Una transacción corresponde a una ID única y GTID solo se ejecuta una vez en el servidor. (2) GTID se puede utilizar como alternativa a la replicación tradicional. La mayor diferencia entre la replicación GTID y el modo de replicación normal es que no es necesario especificar el nombre ni la ubicación del archivo binario.
(3) Reducir la intervención manual y el tiempo de inactividad del servicio Cuando la máquina host se apaga, el software promoverá una máquina de respaldo de muchas máquinas de respaldo como la nueva máquina de control principal.
5.GTID tiene algunas limitaciones:
(1) No se admiten motores que no sean de transacciones.
(2) La replicación no admite la instrucción create table...select (el repositorio principal informa un error directamente).
(3) No se permite que un sql actualice las tablas del motor de transacciones y las tablas del motor que no son de transacciones al mismo tiempo.
(4) En el grupo de replicación, GTID debe activarse o desactivarse de manera uniforme.
(5) Para abrir GTID es necesario reiniciar (excepto la versión 5.7).
(6) Al activar GTID se cancela el principio de replicación tradicional.
(7) No se admiten declaraciones para crear tablas temporales y eliminar tablas temporales.
(8) sql_slave_skip_counter no es compatible.
Requisitos previos:
Instalar mysql5.7 en el nodo maestro y el nodo de respaldo 21 (omitido)
Master1 crea una base de datos para la aplicación (omitido).
MySQL: strong> 1. Modifique el archivo de configuración de MySQL
Consulte las especificaciones de configuración relevantes y configure los archivos my.cnf de master1 y master2 respectivamente
Dado que keepalived posterior colgará VIP, la aplicación se conecta a la base de datos a través de VIP.
2. Configure el modo de semisincronización automática en el lado master1
Hay tres modos de sincronización principales de Mysql:
La configuración posterior es dual-master modo, por lo que cualquier La función de un nodo es tanto un nodo maestro como un nodo esclavo, por lo que los complementos maestro/esclavo relevantes deben configurarse al mismo tiempo.
(1) Primero verifique si la biblioteca admite la carga dinámica (compatible de forma predeterminada)
(2) Instale complementos en la biblioteca principal y en la biblioteca esclava
Como biblioteca maestra, instale el complemento semisync_master.so
Como biblioteca esclava, instale el complemento semisync_slave.so
(3) Instale el complemento desde el complemento. Una vez completado, puede ver que el complemento se ha instalado en la tabla de complementos
(4) Abra la replicación semisincrónica del almacén maestro-esclavo
y agréguelos a su respectivo my.cnf, que se cargará automáticamente en reinicios posteriores de la instancia de la base de datos.
En este momento, verifique si el estado se ha iniciado
(5) Inicie el proceso de IO en los dos nodos respectivamente
(6) Verifique el estado de semisincronización
3. Establezca master1 como el servidor maestro de master2
(1) Cree una cuenta de autorización en el host master1 para permitir conexiones en el host master2
(2) Exportar datos de master1 desde la base de datos maestra
(3) Transferir master.sql a master2 e importar los datos
(4) Importar master.sql a master2. Transfiera sql a master2 e impórtelo
(4) En el lado de master2, configure master1 como su propia base de datos maestra y habilite la función de base de datos esclava
Verifique el estado de la base de datos esclava en master2
En este punto, se completa la replicación maestro-esclavo de maestro1 a maestro2.
4. Deje que master2 se convierta en el servidor maestro de master1
Ejecutar en master1
Ver el estado del esclavo en master1
1.strong >
keepalived es una solución de software para la gestión de clústeres que garantiza una alta disponibilidad del clúster. Su función es similar a un latido y se utiliza para evitar puntos únicos de falla.
se basa en keepalived. en VRRP El nombre completo de VRRP es Protocolo de redundancia de enrutador virtual, que es el protocolo de redundancia del enrutador virtual y se utiliza como base para implementar el protocolo VRRP. Protocolo de redundancia, es decir, protocolo de redundancia de enrutamiento virtual.
El protocolo de redundancia de enrutamiento virtual puede considerarse como un protocolo para lograr una alta disponibilidad de enrutadores, es decir, un grupo de enrutadores está compuesto por N enrutadores que brindan las mismas funciones. En este grupo, hay un maestro. estación y múltiples enrutadores como respaldo, hay un vip en la estación principal para brindar servicios al mundo exterior. La estación principal envía multidifusión (la dirección de multidifusión es 224.0.0.18). multidifusión al mundo exterior como respaldo. Cuando la copia de seguridad no recibe paquetes vrrp, se supone que la estación primaria está inactiva. En este momento, se debe seleccionar una copia de seguridad como la estación primaria según la prioridad VRRP, para garantizar la alta disponibilidad del enrutador.
keepalived tiene tres módulos principales: core, check y vrrp. core es el núcleo de keepalived y es responsable de iniciar y mantener el proceso principal, así como de cargar y analizar archivos de configuración globales; check es responsable de las comprobaciones de estado, incluidos los métodos de verificación comunes. vrrp es un módulo que implementa el protocolo VRRP. Además, para evitar grietas, el firewall debe estar apagado o encendido pero permitiendo la recepción del protocolo VRRP.
2. Instale keepalived
(1) Configure la fuente yum local e instale las dependencias de keepalived Kernel-devel/openssl-devel/popt-devl, etc. en los servidores master1 y master2. .
Configure una fuente de yum local que apunte a rhel-7.5.iso. 5.iso, pasos omitidos
Nota: Si no sabe qué dependencias requiere keepalived, puede consultar el archivo INSTALAR en el directorio de descarga del código fuente para instalar las dependencias requeridas. Primero, debe verificar el archivo INSTALL en el directorio del código fuente descargado e instalar los paquetes de dependencia requeridos.
(2) Descomprimir y compilar keepalived en dos dispositivos mysql
(3) Configurar keepalived.conf en master1 y master2
Tenga en cuenta la figura anterior Las similitudes y diferencias entre las configuraciones de los dos nodos en fuente roja.
Nota: keepalived tiene un solo archivo de configuración, keepalived.conf, que incluye las siguientes áreas de configuración:
- global_defs: se utiliza para configurar objetos de notificación e identificadores de máquina en caso de fallas.
- vrrp_instance: se utiliza para definir el área VIP y sus propiedades relacionadas para servicios externos.
- virtual_server: definición de servidor virtual
(4) Al mismo tiempo, ambos nodos deben agregarse al script de detección
Función: cuando mysql se detiene trabajando Apaga automáticamente el servicio keeplived local para expulsar al host fallido del grupo de espera activo, porque keepalived solo se agrega como un servicio realslived en cada máquina. Debido a que keepalived en cada máquina solo agrega la máquina local como un servidor real, cuando mysqld se inicia normalmente, también necesitamos iniciar manualmente el servicio keepalived.
(5) Inicie el servicio keepalived en los dos nodos respectivamente
Verifique el proceso de inicio de keepalived en los dos nodos
Verifique el bloqueo vip en los dos nodos Cargar
(6) Realice una prueba de conmutación por error en las máquinas maestra y en espera
Detenga el servicio mysql en master2 y verifique si el programa de verificación de estado keepalived activa el script para realizar la conmutación por error automáticamente. se omiten los pasos
Verifique el montaje VIP en el nodo master1 para verificar si se implementa la conmutación automática. Se omiten los pasos
Esto significa que cuando falla el servicio mysql en el servidor master2, el script se activará y el cambio se realizará automáticamente.
(7) Ahora abrimos el servicio mysql en master2 y también necesitamos iniciar el servicio keepalived.
Incluso si se vuelven a abrir el servicio mysql y el servicio keepalived de master2, master1 sigue siendo el sitio maestro y master2 no ha tomado la autoridad del sitio maestro, lo que significa que el parámetro nopreempt entra en vigor en orden. Para garantizar la estabilidad del clúster, no se permite la configuración preferente en el entorno de producción. Solo cuando el servicio mysql de master1 falla, master2 volverá a convertirse en el sitio maestro; de lo contrario, solo podrá servir como copia de seguridad de master1 para siempre. Tenga en cuenta que nopreempt generalmente se configura en mysql de alta prioridad)
Sysbench es una herramienta de evaluación comparativa modular, multiplataforma y multiproceso que se puede utilizar para evaluar la carga de la base de datos. Simplemente configure la IP en el comando sysbench. Con la dirección, el número de puerto, el nombre de usuario y la contraseña, puede conectarse a la base de datos especificada y la contraseña, conectarse a la base de datos db1 especificada, crear varias tablas e insertar rápidamente la cantidad especificada de registros para observar la eficiencia de sincronización del archivo principal. base de datos y la base de datos de respaldo
(1) Descargue la herramienta de código abierto sysbench-0.4.12.14.tar.
4.12.14.tar.gz, colóquelo en el directorio correspondiente y descomprímalo
(2) Utilice iso para configurar la fuente local de yum e instale los siguientes paquetes de dependencia de Sysbench (pasos omitidos): autoconf /autoconf/cdbs /devbase/debase/debase/debase/debase/debase/debase/debase/debase/debase/debase/debase/debase automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/ libmysqlclient15-dev/ libtool/xsltproc
(3) Compile sysbench
Edite el archivo de configuración /etc /ld.so.conf, agregue el directorio lib de mysql /mysql/app/5.7 .21/lib, y Ejecute el comando ldconfig para que surta efecto
(4) Ejecute la prueba de estrés de sysbench
Utilice la herramienta sysbench para crear cinco tablas en la base de datos db1 en nodo maestro, y en cada tabla insertar 100.000 registros. 100.000 registros
Al mismo tiempo, observe la eficiencia de sincronización de la máquina de respaldo
Descripción de varios parámetros importantes:
B. Prueba de cambio de modo síncrono semiautomático y modo asíncrono
(1) Verifique el estado de sincronización y la configuración de los parámetros de sincronización de las máquinas maestra y de respaldo
El parámetro rpl_semi_sync_master_enabled indica que el modo semisincrónico el modo está habilitado
El parámetro rpl_semi_sync_master_timeout en milisegundos indica que si la transacción maestra espera a que la transacción esclava devuelva un mensaje de confirmación exitosa durante más de 10 segundos, pasará al modo asíncrono y ya no esperará. la transacción esclava y luego vuelve a semiautomático después de detectar la recuperación del subproceso io esclavo.
El parámetro rpl_semi_sync_timeout en milisegundos indica que la transacción maestra espera más de 10 segundos para que regrese la transacción esclava. un mensaje de confirmación exitosa. El parámetro semi_sync_master_wait_no_slave indica la necesidad de esperar a que la transacción esclava devuelva un mensaje de confirmación después de que se confirme la transacción
(2) Detener el hilo io de la transacción esclava
(3; ) Utilice sysbench para escribir una pequeña cantidad de datos en la transacción maestra; en este ejemplo, cree una tabla e inserte 10 registros, comando empaquetado en el script de prueba 1.sh
La marca de tiempo registrada muestra que la transacción maestra espera a que el esclavo responda durante 10 segundos y luego cambia automáticamente al modo asíncrono y escribe datos localmente.
(4) El esclavo inicia el subproceso io y los datos se traducen automáticamente
En este punto, la configuración de replicación maestro-maestro de MySQL se completa y se ejecuta en modo de sincronización semiautomática. y realizar MySQL a través de keepalived HA High Availability.
Después de conectarse, se debe seguir una estrategia de monitoreo estándar unificada, se debe agregar un protocolo de respaldo, se deben realizar copias de seguridad de los datos con regularidad y guardarlas en la biblioteca de cintas, y se deben realizar pruebas de recuperación de datos con regularidad.
Dado que keepalived logra una alta disponibilidad, también se deben agregar los siguientes recursos a la plataforma de administración de monitoreo:
1. Monitorear los tres procesos keepalived de cada host de base de datos
<; p> 2. Supervise el estado de funcionamiento del subproceso io y del subproceso sql del nodo principal y del nodo de respaldo 3.