1. Visión general
Cuando consideramos la arquitectura de base de datos MySQL de alta disponibilidad, sobre todo en cuenta los siguientes aspectos:
- Si el fallo de la base de datos o interrupción inesperada tiempo de inactividad, para reanudar tan pronto como la disponibilidad de bases de datos, reducir el tiempo tanto como sea posible, para asegurar que el servicio no se interrumpe debido a un fallo de la base de datos.
- Como medida de seguridad, los datos de copia de sólo lectura de la no maestro funciones de nodo debe ser el nodo maestro y los datos en tiempo real o siempre la misma.
- conmutación de servicios se produce cuando la base de datos, el contenido de bases de datos antes y después de la conmutación debe ser coherente, los datos no se encuentra o está afectando el tráfico de datos inconsistentes.
Acerca de Aquí no hacemos una discusión detallada sobre la clasificación de alta disponibilidad, aquí solamente discutir las ventajas y desventajas de alta disponibilidad y selección de los programas más utilizados en soluciones de alta disponibilidad.
2. Programa de Alta Disponibilidad
2.1. Desde el maestro o maestro primario semi-sync
Usando la base de datos de dos nodos, construir la replicación semi-síncrono unidireccional o bidireccional. En una próxima versión 5.7, debido replicación sin pérdida, la introducción de nuevas funciones lógicas replicación multi-hilo y alguna otra columna, haciendo que la replicación semisincrónica nativo de MySQL es más fiable.
arquitectura común es el siguiente:
A menudo, y el proxy, keepalived mientras se utiliza otro software de terceros que se puede utilizar para controlar la salud de la base de datos, y puede realizar una serie de comandos administrativos. Si la base de datos principal falla a la base de datos standby puede seguir utilizando la base de datos.
ventajas:
- La arquitectura es simple, utilizando la replicación semi-sincrónica nativa como la base para la sincronización de datos;
- De dos nodos, no hay ningún problema después de que el anfitrión principal seleccionada es hacia abajo, se puede cambiar directamente;
- De dos nodos, menos demanda de recursos, la instalación sea sencilla;
desventajas:
- Totalmente dependiente de la replicación semi-sincrónico, si semi-sincrónica replicación degenerar en la replicación asíncrona, consistencia de los datos no puede ser garantizada;
- Y requieren consideraciones adicionales haproxy, alta disponibilidad de mecanismo de keepalived.
2.2. Optimización de la replicación semi-síncrona
mecanismo de replicación semi-síncrono es fiable. Si la replicación semi-síncrono está en vigor, entonces se puede considerar los datos son consistentes. Sin embargo, debido a algunas razones objetivas batir, dando lugar a la replicación semisincrónica se produce tiempo de espera y se conecta a la replicación asíncrona, entonces el tiempo no puede borrar la consistencia de datos de garantía. Por lo tanto como sea posible para asegurar la replicación semi-sincrónica, se puede mejorar la consistencia de los datos.
El programa también utiliza una arquitectura de dos nodos, pero a la mitad la función original se ha optimizado sobre la base de la misma copia en el mecanismo de replicación semi-síncrona se hace más fiable.
Consulte el esquema de optimización es la siguiente:
2.2.1. Replicación de doble canal
Dado que la replicación semi-sincrónica se produce después de que el tiempo de espera, copia desconectada, cuando se estableció la replicación de nuevo, al tiempo que establece dos canales, uno de los canales de replicación semisincrónica comienza a copiar desde la posición actual para asegurarse de que el esclavo sabe el progreso de la implementación de la máquina actual. Además de un canal de puesta al día se inicia la replicación asíncrona de datos de la máquina hacia atrás. Cuando el canal de la replicación asíncrona a la posición inicial para controlar el semi-sync, la recuperación semi-sync.
2.2.2. Binlog servidor de archivos
Dos estructuras de canales semi-sincronización, en el que la mitad inferior-SCH normalmente conectado al servidor de archivos no está activado, cuando la red maestro-esclavo de semi-sync degradación problemas medio iniciar la replicación síncrona con el canal de servidor de archivos. Cuando la recuperación semi-sincronización desde el maestro, el medio-close replicación síncrona el canal servidor de archivos.
ventajas:
- De dos nodos, menos demanda de recursos, la instalación sea sencilla;
- Estructura simple, el problema principal no está seleccionada, puede cambiar directamente;
- En comparación con la copia original, la replicación semi-síncrona optimizada para asegurar una mejor consistencia de los datos.
desventajas:
- Modificaciones a la fuente del núcleo utilizando MySQL o protocolo de comunicación. Tenemos que tener algún conocimiento del código fuente, y podemos hacer un cierto grado de desarrollo secundario.
- Todavía se basa en la replicación semi-sincrónica, la consistencia de datos no resuelve el problema fundamental.
2.3. Alta disponibilidad optimización de la arquitectura
La base de datos extendidos de dos nodos a una base de datos multi-nodo, o un grupo de base de datos multi-nodo. Puede elegir dos de un maestro de acuerdo a sus necesidades, desde un multi-master o varios maestros de la multi-cluster.
Puesto que la replicación semi-sincrónico, la presencia de un transpondedor se recibe de una máquina que tiene éxito semi-sincronización características exitosas considerados, la replicación multi-síncrona de un solo semi-fiabilidad fiabilidad superior replicado de la media. Y la probabilidad de múltiples nodos a la vez el tiempo de inactividad debe ser menor que la probabilidad de un solo nodo deja de funcionar, por lo que la arquitectura de múltiples nodos en cierta medida se puede considerar alta disponibilidad es mejor que una arquitectura de dos nodos.
Sin embargo, debido a que el número de bases de datos, software de gestión de base de datos, por lo que es necesario para asegurar la capacidad de mantenimiento de la base de datos. Puede elegir MMM, MHA o varias versiones del proxy, y así sucesivamente. esquema común es el siguiente:
2.3.1. MHA + clúster de varios nodos
MHA Director detectará regularmente nodo principal en el clúster cuando falla el maestro, que puede servir como esclavo automáticamente actualizar a los últimos datos para el nuevo maestro, y luego todos los otros esclavos redirigido a la nueva maestra, todo el proceso de cesión de aplicaciones completamente transparente.
MHA nodo se ejecuta en cada servidor MySQL, el papel principal es procesar el registro binario cuando se cambia, asegúrese de cambiar para minimizar la pérdida de datos.
MHA se puede extender a un clúster de varios nodos de la siguiente manera:
ventajas:
- Se puede detectar automáticamente y los fallos de transferencia;
- Mejor escalabilidad, puede ser necesario ampliar el número de nodos y la estructura de MySQL;
- Una menor probabilidad en comparación con una replicación MySQL de dos nodos, de tres nodos / no disponible con MySQL multi-nodo
desventajas:
- Al menos tres nodos, con respecto a los dos nodos requiere más recursos;
- lógica más compleja, fallo de resolución de problemas se produce, el problema de posicionamiento es más difícil;
- consistencia de los datos sigue siendo, con la garantía de la replicación semisincrónica nativa, riesgo de aún existe inconsistencia de datos;
- Probablemente debido a la ocurrencia de la red fenómeno de partición cerebro dividido;
2.3.2. cuidador del zoológico + Proxy
Zookeeper usando algoritmo de agrupamiento distribuido para asegurar la consistencia de datos, el uso cuidador del zoológico puede garantizar de manera efectiva la alta disponibilidad de proxy, puede evitar mejor el fenómeno de partición de la red.
ventajas:
- Mejor asegurar la alta disponibilidad de todo el sistema, incluyendo el proxy, MySQL;
- Una mejor escalabilidad, puede extenderse a grandes grupos;
desventajas:
- la coherencia de datos es todavía depende de la replicación semi-síncrono nativo mysql;
- La introducción de ZK, la lógica del sistema se vuelve más complicada;
2.4. Almacenamiento compartido
El almacenamiento compartido para lograr un desacoplamiento de los servidores de base de datos y dispositivos de almacenamiento, la sincronización de datos entre diferentes bases de datos ya no confían en las capacidades de replicación nativas de MySQL, pero por medio de la sincronización de datos de disco para garantizar la coherencia de los datos.
2.4.1. SAN almacenamiento compartido
concepto SAN es permitir que el procesador y el dispositivo de almacenamiento de red de alta velocidad entre un (servidor) directo (en comparación con las LAN), que están conectados a través de una aplicación de almacenamiento de datos centralizada. arquitectura común es el siguiente:
Cuando una memoria compartida, el servidor MySQL puede montar un sistema de archivos y operando normalmente, si se produce el tiempo de inactividad de la base de datos principal, la base de datos de reserva puede montar el mismo sistema de archivos, asegúrese de que la biblioteca principal y de copia de seguridad de base de datos utilizando los mismos datos.
ventajas:
- Dos nodos pueden ser simple de implementar, lógica de conmutación sencilla;
- Buena consistencia de los datos sólida garantía;
- No debido a inconsistencias de datos MySQL se producen errores lógicos;
desventajas:
- Es necesario tener en cuenta la alta disponibilidad de almacenamiento compartido;
- caro;
2.4.2. Duplicación de discos DRBD
DRBD es un basados en software, soluciones de almacenamiento basadas en bloques copia de la red, los servidores utilizan principalmente entre los discos, particiones y otros datos que reflejan volumen lógico, cuando los datos de usuario se escribe en el disco local, también se transmiten los datos red a otro host en el disco, de modo que el host local (master) y el (aparato de nodo) host remoto pueden garantizar la sincronización de datos en tiempo real. arquitectura común es el siguiente:
Cuando hay un problema el anfitrión local, un host remoto conserva los mismos datos, pueden seguir utilizándose para garantizar la seguridad de datos.
DRBD nivel de replicación síncrona rápida del núcleo de Linux módulo implementado con un SAN puede lograr el mismo efecto memoria compartida.
ventajas:
- Dos nodos pueden ser simple de implementar, lógica de conmutación sencilla;
- En comparación con la red de almacenamiento SAN, precios bajos;
- Asegurar una fuerte coherencia de los datos;
desventajas:
- io mayor impacto en el rendimiento;
- No proporciona una operación de lectura de la biblioteca;
2.5. Protocolo distribuido
protocolo distribuido problema de la consistencia de datos puede ser resuelto. Los escenarios más comunes son los siguientes:
2.5.1. MySQL Cluster
MySQL Cluster es un conjunto de despliegue oficial usando el motor de almacenamiento en tiempo real redundancia de datos de copia de seguridad NDB, alta disponibilidad y consistencia de los datos de la base de datos.
ventajas:
- Todos los componentes utilizando el funcionario, no se basa en el software de terceros;
- consistencia de los datos Strong puede lograrse;
desventajas:
- Menos uso doméstico;
- configuración más compleja se requiere motor NDB, hay algunas diferencias con MySQL motor convencional;
- Al menos tres nodos;
2.5.2. galera
clústeres de alta disponibilidad basada en MySQL de Galera, es una sincronización de datos multi-maestro de solución MySQL Cluster, fácil de usar, no hay ningún punto único de fallo, alta disponibilidad. arquitectura común es el siguiente:
ventajas:
- Varios maestros de escritura, copia sin demora, para asegurar una fuerte consistencia de los datos;
- Hay comunidad madura, hay empresas de Internet en el uso a gran escala;
- conmutación por error automática, añadir automáticamente, eliminar el nodo;
desventajas:
- Wsrep parche necesidad de luchar por el nodo nativo de MySQL
- Sólo motor de almacenamiento InnoDB soportan
- Al menos tres nodos;
2.5.3. POAXS
Paxos algoritmo para resolver la cuestión de cómo un sistema distribuido de acuerdo sobre un valor (resolución). Este algoritmo se considera que es el tipo más eficaz de algoritmo. Paxos y MySQL combinada con una fuerte consistencia se pueden lograr en un datos MySQL distribuido. arquitectura común es el siguiente
ventajas:
- Varios maestros de escritura, copia sin demora, para asegurar una fuerte consistencia de los datos;
- Madura base teórica;
- conmutación por error automática, añadir automáticamente, eliminar el nodo;
desventajas:
- Sólo motor de almacenamiento InnoDB soportan
- Al menos tres nodos;
3. Resumen
A medida que las personas siguen mejorando requisitos de coherencia de datos, cada vez más métodos se utilizan para tratar de resolver los problemas de consistencia de datos distribuidas, tales como MySQL propia optimización, optimización de la arquitectura de MySQL Cluster, Paxos, Balsa, algoritmo de 2PC introducción y así sucesivamente.
Pero el uso de un algoritmo distribuido para resolver el problema de consistencia de los datos de base de datos MySQL de enfoque, cada vez más aceptada por la gente, una serie de productos maduros como PhxSQL, MariaDB Galera Cluster, Percona XtraDB Cluster y lo que más y más por las grandes uso a gran escala.
Con el funcionario Grupo de replicación MySQL GA, usando un protocolo distribuido para resolver el problema de la consistencia de los datos se ha convertido en una dirección general. Esperan que se han propuesto soluciones cada vez más pendientes, cuestiones de alta disponibilidad de MySQL pueden abordarse mejor.
referencias
[2015 OTN] Pengli Xun -DoubleBinlog .pdf programa
referencia:
https://zhuanlan.zhihu.com/p/25960208 (anteriormente transferido de este artículo)
