Cinco soluciones comunes de alta disponibilidad de MySQL (las más completas)
Cuando consideramos la arquitectura de alta disponibilidad de la base de datos MySQL, debemos considerar principalmente los siguientes aspectos:
Si la base de datos deja de funcionar o se interrumpe inesperadamente u otras fallas. Si esto ocurre, puede restaurar la disponibilidad de la base de datos lo antes posible para minimizar el tiempo de inactividad y garantizar que el negocio no se vea interrumpido debido a una falla de la base de datos.
Los datos de los nodos no principales utilizados para copias de seguridad, réplicas de lectura y otras funciones deben ser en tiempo real o eventualmente coherentes con los datos del nodo principal.
Cuando ocurre un cambio de base de datos en la empresa, el contenido de la base de datos antes y después del cambio debe ser el mismo, y la empresa no se verá afectada por la falta de datos o la inconsistencia de los datos.
La clasificación de alta disponibilidad no se discutirá en detalle aquí. Aquí solo discutiremos las ventajas y desventajas de los programas de alta disponibilidad comúnmente utilizados y la selección de programas de alta disponibilidad.
2. Solución de alta disponibilidad
2.1. Replicación semisíncrona maestro-esclavo o maestro-maestro
Utilice una base de datos de dos nodos para establecer unidireccional. o replicación semisincrónica bidireccional. A partir de la versión 5.7, la replicación semisíncrona nativa de MySQL se vuelve más confiable debido a la introducción de nuevas características como replicación sin pérdidas, replicación lógica multiproceso y más.
Las arquitecturas comunes son las siguientes:
A menudo se usa junto con software de terceros, como proxy y keepalived, que se pueden usar para monitorear el estado de la base de datos y ejecutar una serie de comandos de gestión. Si la base de datos principal falla, puede continuar usando la base de datos después de cambiar a la base de datos de respaldo.
Ventajas:
Arquitectura simple, que utiliza replicación semisincrónica nativa como base para la sincronización de datos.
Nodo dual, no hay problema para seleccionar el; sitio principal después de que el host se caiga, puede cambiar directamente;
Los nodos duales requieren menos recursos y son fáciles de implementar
Desventajas:
Completamente dependiente; en la base de datos principal y no se puede implementar Sincronización de datos:
Depende completamente de la replicación semisincrónica. Si la replicación semisincrónica se degrada a replicación asincrónica, los datos aún se pueden usar.
Desventajas:
Depende completamente de la replicación semisincrónica. Si la replicación semisincrónica degenera en replicación asincrónica, no se puede garantizar la coherencia de los datos.
Se necesitan consideraciones adicionales; Se convertirá en un mecanismo de alta disponibilidad haproxy y keepalived.
2.2. Optimización de la replicación semisincrónica
La replicación semisincrónica es confiable. Si la replicación semisincrónica siempre es efectiva, los datos pueden considerarse consistentes. Sin embargo, si la replicación semisincrónica se agota y cambia a replicación asincrónica debido a fluctuaciones de la red y otras razones objetivas, no se puede garantizar la coherencia de los datos. Por lo tanto, si se puede garantizar la replicación semisíncrona tanto como sea posible, se puede mejorar la coherencia de los datos.
Esta solución también utiliza una arquitectura de dos nodos, pero optimiza las funciones en función de la replicación semisincrónica original, lo que hace que el mecanismo de replicación semisincrónica sea más confiable.
El contenido de la optimización es el siguiente:
2.2.1 Replicación de doble canal
La replicación semisincrónica se desconecta debido al tiempo de espera al restablecerse. Durante la replicación, se establecen dos canales al mismo tiempo, donde un canal de replicación semisincrónico comienza a replicarse desde la posición actual, asegurando que el esclavo esté al tanto del progreso de ejecución del maestro actual. Otro canal de replicación asincrónica comienza a ponerse al día con los datos retrasados del dispositivo esclavo. La replicación semisincrónica se reanudará cuando el canal de replicación asincrónica alcance el inicio de la replicación semisincrónica.
2.2.2. servidor de archivos binlog
Establezca dos canales de replicación semisincrónicos. El canal semisincrónico conectado al servidor de archivos no se activa en circunstancias normales. esclavo semisincrónico Cuando la replicación se ralentiza debido a problemas de red, se activa un canal de replicación semisincrónico al servidor de archivos. Una vez que se reanude la replicación semisincrónica maestro-esclavo, cierre el canal de replicación semisincrónica con el servidor de archivos.
Ventajas:
Nodos duales, bajos requisitos de recursos, fácil de implementar
Arquitectura simple, sin problemas de selección del sitio maestro, se puede cambiar directamente; p>
La replicación semisincrónica optimizada garantiza la coherencia de los datos mejor que la replicación local.
Desventajas:
Requiere modificación del código fuente del kernel o uso del protocolo de comunicación mysql. Debe tener cierta comprensión del código fuente y poder realizar un desarrollo secundario hasta cierto punto.
Todavía depende de la replicación semisincrónica y no resuelve fundamentalmente el problema de la coherencia de los datos.
2.3. Optimización de la arquitectura de alta disponibilidad
Expanda la base de datos de dos nodos a una base de datos de múltiples nodos o un clúster de bases de datos de múltiples nodos. Puede elegir un maestro y dos esclavos, un maestro y varios esclavos, o varios maestros y varios esclavos según sus necesidades.
Dado que se trata de una replicación semisincrónica, un nodo esclavo recibe una respuesta de que la replicación semisincrónica fue exitosa, por lo que la confiabilidad de la replicación semisincrónica de múltiples nodos esclavos es mejor que la confiabilidad de la replicación semisincrónica de un solo nodo. Replicación semisincrónica del nodo esclavo. Además, la probabilidad de que varios nodos caigan al mismo tiempo es menor que la probabilidad de que un solo nodo caiga. Por lo tanto, se puede considerar que la arquitectura de múltiples nodos tiene una mejor alta disponibilidad que la arquitectura de dos nodos para un determinado. medida.
Sin embargo, debido a la gran cantidad de bases de datos, se necesita un software de gestión de bases de datos para garantizar la mantenibilidad de la base de datos. Puede elegir entre MMM, MHA o varias versiones de agentes, etc. Las situaciones comunes son las siguientes:
2.3.1.Clúster de múltiples nodos MHA+
El administrador de MHA detectará periódicamente el nodo maestro en el clúster. Cuando el nodo maestro falle, lo hará. automáticamente tiene la última El nodo esclavo de los datos se promueve al nuevo nodo maestro y todos los demás nodos esclavos se redirigen al nuevo nodo maestro. Todo el proceso de conmutación por error es completamente transparente para la aplicación.
El nodo MHA se ejecuta en cada servidor MySQL y su función principal es procesar el registro binario durante la conmutación para garantizar que se pierda la menor cantidad de datos posible durante la conmutación.
MHA también se puede extender a clústeres de múltiples nodos, de la siguiente manera:
Ventajas:
Puede detectar fallas y realizar conmutación por error automáticamente
<; p > Más escalable, el número y la estructura de los nodos MySQL se pueden ampliar según sea necesario;En comparación con la replicación MySQL de dos nodos, aparece MySQL de tres nodos/multinodos. La probabilidad de indisponibilidad es menor
Desventajas:
Se requieren al menos tres nodos, lo que requiere más recursos que dos nodos
La lógica es más compleja; es más difícil solucionar problemas y localizarlos después de que ocurre una falla;
La consistencia de los datos aún está garantizada por la replicación semisincrónica nativa, y aún existe el riesgo de que se produzcan inconsistencias en los datos;
Debido a las particiones de red, puede ocurrir una ruptura cerebral;
2.3.2.zookeeper+ agente
Zookeeper utiliza un algoritmo distribuido para garantizar la coherencia de los datos del clúster. El uso de zookeeper garantiza de manera efectiva la alta disponibilidad del clúster. agente, que es para evitar una mejor manera de particionar su red.
Ventajas:
Garantiza mejor la alta disponibilidad de todo el sistema, incluidos los agentes y MySQL
Mejor escalabilidad y se puede extender a clústeres a gran escala;
Desventajas:
La coherencia de los datos aún depende de la replicación semisincrónica nativa de MySQL;
Después de la introducción de zk, la lógica de todo el sistema se vuelve más compleja
2.4.***Almacenamiento de cobertura
***El almacenamiento de cobertura desacopla el servidor de la base de datos del dispositivo de almacenamiento y la sincronización de datos entre diferentes bases de datos ya no depende de la replicación nativa de MySQL. función, pero para garantizar la coherencia de los datos a través de la sincronización de datos del disco.
2.4.1.SAN*** Disfrute del almacenamiento
El concepto de SAN es establecer una conexión de red directa de alta velocidad (relativa a LAN) entre el dispositivo de almacenamiento y el procesador. (servidor), de esta forma se consigue el almacenamiento centralizado de datos. Las arquitecturas comúnmente utilizadas son las siguientes:
Cuando el almacenamiento está habilitado usando ****, el servidor MySQL puede montar el sistema de archivos y ejecutarlo normalmente. Si el repositorio principal deja de funcionar, el repositorio de respaldo también puede montarlo. mismo sistema de archivos, asegurando que los repositorios principal y de respaldo utilicen los mismos datos.
Ventajas:
Solo se necesitan dos nodos, fácil de implementar y una lógica de conmutación simple
Garantiza una sólida coherencia de los datos
<; p> La inconsistencia de los datos no será causada por errores lógicos en MySQL;Desventajas:
Se debe considerar el almacenamiento de alta disponibilidad de ****-disfrute;
Caro.
2.4.2.DRBD replicación de disco
DRBD es una solución de almacenamiento de replicación de bloques basada en red basada en software, que se utiliza principalmente para discos, particiones y volúmenes lógicos entre servidores. El usuario escribe datos en el disco local, los datos también se enviarán al disco de otro host en la red, asegurando así la sincronización en tiempo real de los datos entre el host local (nodo principal) y el host remoto (nodo de respaldo). La arquitectura comúnmente utilizada es la siguiente:
Cuando ocurre un problema en el host local, el host remoto aún conserva una copia de los mismos datos y puede continuar usándola para garantizar la seguridad de los datos.
DRBD es una tecnología de replicación síncrona de nivel rápido implementada por el módulo del kernel de Linux, que puede lograr el mismo almacenamiento de disfrute que SAN.
Ventajas:
Solo se necesitan dos nodos, fácil de implementar, lógica de conmutación simple
En comparación con la red de almacenamiento SAN, el costo es menor
p >
Puede garantizar una sólida coherencia de los datos
Desventajas:
Tiene un mayor impacto en el rendimiento de IO
No proporciona operaciones de lectura desde el repositorio; ;
2.5. Protocolo distribuido
Los protocolos distribuidos pueden resolver muy bien el problema de la coherencia de los datos. Las soluciones más comunes son las siguientes:
2.5.1.MySQL Cluster
MySQL Cluster es una solución de implementación de clúster lanzada oficialmente que utiliza el motor de almacenamiento NDB para realizar copias de seguridad de datos redundantes en tiempo real. Es hora de lograr la seguridad de la base de datos. Alta disponibilidad y coherencia de los datos.
Ventajas:
Todos utilizan componentes oficiales y no dependen de software de terceros
Puede lograr una sólida coherencia de datos
; Desventajas:
Menos utilizado en China
La configuración es compleja y requiere el uso del motor de almacenamiento NDB, que es diferente del motor MySQL normal
; Se requieren al menos tres nodos;
2.5.2.Galera
El clúster de alta disponibilidad MySQL basado en Galera es una solución de clúster MySQL para la sincronización de datos maestros múltiples. , no tiene un único punto de falla y tiene alta disponibilidad. La arquitectura común es la siguiente:
Ventajas:
Escritura multimaestro, replicación sin demoras, lo que garantiza una sólida coherencia de los datos
Existe una comunidad madura; utilizado a gran escala por empresas de Internet;
Conmutación por error automática, adición y eliminación automática de nodos
Desventajas:
Es necesario reiniciar cuando el sistema falla;
Requiere un reinicio cuando el sistema falla
Requiere un reinicio cuando el sistema falla
Requiere un reinicio cuando el sistema falla
<; p> Requiere reiniciar en caso de falla del sistema:Los nodos MySQL locales deben parchearse con el parche wsrep
Solo se admite el motor de almacenamiento innodb
Al menos se requieren tres nodos;
2.5.3.POAXS
El algoritmo Paxos resuelve el problema de cómo un sistema distribuido puede acordar un determinado valor (resolución). Paxos combinado con MySQL puede lograr una gran coherencia en los datos distribuidos de MySQL. Las arquitecturas comunes son las siguientes:
Ventajas:
Escritura multimaestro, replicación sin demoras, lo que garantiza una sólida coherencia de los datos
Base teórica madura
; p> p>
Conmutación por error automática, adición y eliminación automática de nodos
Desventajas:
Solo admite el motor de almacenamiento innodb
Al menos tres nodos; son necesarios;
Lo más importante es que Paxos es el algoritmo más eficiente de su tipo.
3. Resumen
Con la mejora continua de los requisitos de coherencia de los datos, se prueban cada vez más métodos para resolver los problemas de coherencia de los datos distribuidos, como la optimización propia de MySQL y la optimización del clúster MySQL. arquitectura, introducción de Paxos, Raft, algoritmo 2PC, etc.
Cada vez más personas aceptan el uso de algoritmos distribuidos para resolver el problema de coherencia de los datos de la base de datos MySQL, y una serie de productos maduros como PhxSQL, MariaDB Galera Cluster y Percona XtraDB Cluster también se están volviendo cada vez más populares. y más popular. La tierra se utilizó a gran escala.
Con el lanzamiento oficial de MySQL Group Replication GA, el uso de protocolos distribuidos para resolver problemas de coherencia de datos se ha convertido en una dirección generalizada. Esperamos que se propongan cada vez más soluciones excelentes para resolver mejor el problema de alta disponibilidad de MySQL.