Cómo diseñar e implementar MySQL de alta disponibilidad
Comencemos nuestro contenido principal hoy. Hoy presentaremos principalmente la alta disponibilidad de MySQL a través de qué, por qué y cómo hacerlo.
En primer lugar, ¿qué es la alta disponibilidad? En mi opinión, significa que el número total de horas de funcionamiento empresarial puede proporcionar servicios de alta calidad a los usuarios. De hecho, cuando nos dedicamos a trabajos relacionados con MySQL, todo el mundo es más sensible al número nueve. Cuando elegimos un producto en la nube de un proveedor de nube, primero miramos cuántos nueves hay en su base de datos. Actualmente, Tencent Cloud MySQL puede alcanzar 99,95, 25 minutos durante todo el año.
Hasta donde yo sé, la alta disponibilidad más alta puede lograr 3 9 y 1 6. Es muy difícil lograr 4 9, y 5 9 ya es el límite.
¿Por qué necesitamos alta disponibilidad? Debido a que tenemos demasiados factores incontrolables, como las máquinas mineras, recuerdo que incidentes similares ocurrían básicamente cada dos años. Lo que permanece fresco en mi memoria es que en 2015, cierta red troncal en Xiaoshan, Hangzhou, fue eliminada, causando algunos. de los servicios de Alibaba no estén disponibles. Además, hay algunos cortes de energía similares, o algunos desastres naturales, etc. Vale la pena mencionar que en algunos casos, el personal de operación y mantenimiento comete errores y repara todo el directorio o pierde tablas. También hay un dicho popular que es desde eliminar la base de datos hasta ejecutarla. Hay muchos factores incontrolables. Tus datos son tuyos y tus usuarios son tuyos. Si no puedes controlarlos, tu negocio no crecerá.
De manera general, existen dos indicadores que se utilizan como estándares de medición, el primero es el RPO y el segundo es el RTO. RPO se refiere a la cantidad de datos perdidos desde el inicio de la falla hasta la recuperación del negocio, y RTO se refiere al tiempo que lleva desde el comienzo de la falla hasta la recuperación del negocio. Cuanto más corto, mejor para ambos. indicadores.
¿Cómo hacer esto? En términos generales, existen tres métodos en la industria. El de la izquierda es un método de almacenamiento basado en una sola máquina. Este método es más común en escenarios de juegos. Usamos un nodo de computadora independiente en la capa superior y tres copias en la capa inferior. para garantizar la confiabilidad de los datos. Después de que un nodo informático falla, se puede migrar rápidamente a otro nodo informático. Por supuesto, nuestro Tencent Cloud MySQL también ha lanzado este modo, el precio es muy económico. Podemos comprar este modo. el sitio web oficial. El segundo se basa en el almacenamiento compartido, también llamado modo de disco compartido. Esta es una arquitectura más típica de Oracle RAC. La capa inferior se basa en almacenamiento compartido y la capa superior utiliza múltiples nodos informáticos. Si un nodo informático falla, se puede eliminar inmediatamente de la lista de IP sin afectar el acceso del usuario. La tercera capa se basa en el modo de replicación de datos y también se comparte sin modo. Logra la coherencia de los datos entre los dos hosts a través de protocolos de replicación y transmisión de datos, que también es el foco de esta explicación. Además, además de la alta disponibilidad del nodo de almacenamiento, todo su enlace también requiere alta disponibilidad, como nuestra sala de ordenadores IDC, conmutadores, servidores host, etc.
Ahora presentamos la alta disponibilidad de infraestructura. A menudo escuchamos algunos términos: el primero es doblemente activo en la misma ciudad y el segundo es tres centros en dos lugares, lo que es una fuerte demanda para escenarios relacionados con las finanzas. , significa que estamos en un lugar donde dos nodos están separados por 10 kilómetros en la misma ciudad y donde dos centros de datos están separados por 100 kilómetros, otros centros de recuperación ante desastres deben garantizar que la sala de computadoras esté altamente disponible. Además, incluyendo la red y el host, la arquitectura real es así. Al menos la red de su conmutador tiene respaldo. Si uno está roto, es necesario reemplazar el otro.
Ahora viene nuestro enfoque: la alta disponibilidad basada en la replicación de datos. Primero, introduzcamos que la copia de seguridad es realmente muy importante, y la copia de seguridad es de hecho la última garantía sin ningún método, por lo que recomendamos que todos, independientemente de. Ya sea una empresa que utiliza la nube o su propio IDC, intente realizar tantas copias de seguridad como sea posible.
Las copias de seguridad de MySQL son básicamente de dos tipos: copia de seguridad lógica y copia de seguridad física. La copia de seguridad lógica generalmente utiliza el MySQLDump oficial y la herramienta de terceros MyDumper. La ventaja de MyDumper es la copia de seguridad multiproceso y su alta velocidad.
La copia de seguridad física utiliza xtrabackup de Percona, que no descarta discos mediante compresión y concurrencia basadas en flujo, produce copias de seguridad con una mayor tasa de éxito, mayor velocidad y menor espacio de almacenamiento temporal. La última es una instantánea. Todas nuestras copias de seguridad de la versión básica de Tencent Cloud se generan a través de instantáneas.
¿Cómo garantizar la coherencia de los datos según el método de replicación de datos, que suele ser un nodo maestro-esclavo? De hecho, los datos se transmiten a través del protocolo de replicación y la conmutación Switch se utiliza para garantizar que el servicio pueda restaurarse lo antes posible después de una falla. La imagen de la derecha es básicamente consistente con la arquitectura de Tencent Cloud MySQL. Adoptamos un enfoque maestro-esclavo. El nodo esclavo solo es responsable de la conmutación por error. Cuando el nodo maestro cuelga, se utiliza la detección automática de fallas y la conmutación automática. recuperación del negocio lo antes posible. Además, para la separación de lectura y escritura, Tencent Cloud MySQL actualmente admite un nodo maestro y cinco nodos de solo lectura.
La siguiente es una introducción a la replicación. Antes de introducir la replicación, es necesario introducir un concepto importante: binlog. Binlog es un archivo binario que registra principalmente información SQL actualizada por los usuarios en la base de datos. ¿parece? Se ve así en el disco. Después de su uso, el evento binlog se verá así. Registrará cierta metainformación, como bits, eventos, etc. Usamos la herramienta de análisis oficial de MySQL mysqlbinlog para analizarlo de esta manera. se usa en él. La declaración SQL codificada en base64 se ve así después de la decodificación. Puede ver que hay una barra de inserción aquí. Lo primero que debe hacer es escribir la declaración. ¿Cuándo debería escribir binlog? Miremos esta imagen. Sabemos que el envío de transacciones tiene dos etapas: preparación y envío. ¿En qué etapa se escribe el binlog? Binlog en realidad se escribe después de la preparación y antes del envío. Al mismo tiempo, se generarán rehacer y deshacer registro durante el proceso de escritura de la transacción. Sabemos que MySQL es una base de datos relacional de múltiples motores, binlog es el registro de la capa del servidor MySQL y redolog es el registro de la capa InnoDB del motor MySQL. Otra diferencia es que el tiempo de escritura de los dos es diferente. redolog se ejecuta en la fase de preparación. La declaración SQL se rehace y el binlog se escribe después del envío. ¿Cómo garantiza MySQL la coherencia de los datos en una arquitectura maestro-esclavo? Como todos sabemos, MySQL primero escribe datos en la memoria y luego los descarta en el disco para garantizar el rendimiento. Cuando su base de datos se está ejecutando y se produce un tiempo de inactividad, es posible que parte de los datos se eliminen en el disco cuando la máquina se restaure nuevamente, y es posible que parte de los datos no se eliminen en el disco. En este momento, mysql está buscando el último bit de sincronización o GTID del binlog para determinar qué instancias en rehacer o deshacer deben revertirse y qué transacciones deben rehacerse. Además, al escribir registros como redolog o binlog, para garantizar un alto rendimiento, MySQL también escribirá primero en la memoria y luego lo descartará en el disco. Por lo tanto, la política de descarte de registros también afectará la coherencia de los datos. Para garantizar la coherencia de los datos, se recomienda configurar los parámetros relacionados con los registros en "doble 1", como se muestra en la figura.
De todo el proceso de replicación, es muy simple. El Maestro descartará el binlog a través del subproceso de volcado, y habrá dos subprocesos en el Esclavo, a saber, el subproceso IO y el subproceso SQL. El hilo SQL lee la información SQL en el registro de retransmisión en paralelo y realiza operaciones de reproducción. En términos generales, existen tres tipos de replicación: replicación asincrónica, replicación semisincrónica y replicación sincrónica fuerte. La diferencia entre los tres es cuando los resultados de la ejecución de SQL se devuelven al cliente. Durante la replicación asincrónica, el Maestro no se preocupa por el Esclavo. El Maestro regresa al cliente inmediatamente después de ejecutar SQL. Este método tiene el mejor rendimiento, pero pueden ocurrir inconsistencias de datos durante la sincronización fuerte, el Maestro se preocupa por completo por el Esclavo y el Esclavo. espera a que el Esclavo reproduzca el registro de retransmisión al Cliente. Este método puede garantizar una gran coherencia de los datos, pero su rendimiento sufrirá una cierta pérdida.
Este método puede garantizar una gran coherencia de los datos, pero existe una cierta pérdida de rendimiento; la semisincronización es parte del cuidado del Maestro del Esclavo, es decir, siempre que el binlog se transmita al Esclavo y caiga en el registro de retransmisión. se puede devolver al cliente. La semisincronización es un método de implementación equilibrado, por un lado, debe garantizar la coherencia de los datos y, por otro lado, debe tener en cuenta el rendimiento de la base de datos.
Durante el proceso de replicación, a menudo encontramos problemas de retraso. En la figura, podemos ver que la replicación pasa por tres etapas: el subproceso de volcado descarta el registro binlog del disco, el subproceso IO descarta el registro de retransmisión del disco y el SQL. Reproducción de hilos, ¿cuál de estos tres pasos es el cuello de botella? Es un subproceso SQL, porque durante el proceso de reproducción, el subproceso SQL ejecuta SQL en serie, mientras que el Maestro proporciona servicios externos en paralelo. Entonces el cuello de botella aquí es el hilo SQL. Puede resolver problemas de latencia habilitando la replicación paralela. MySQL 5.6 se basa en la replicación paralela a nivel de biblioteca; MySQL 5.7 se basa en la replicación paralela de reloj lógico, es decir, el paralelismo a nivel de tabla; MySQL 8.0 es una replicación paralela a nivel de fila, con una granularidad más fina y una mayor eficiencia de replicación.
Mientras hablamos de la replicación a nivel de protocolo, existe otra forma de copiar datos a nivel de bloque, que no se preocupa por las capas superiores y solo garantiza que los datos se copien a nivel de disco. Por supuesto, la escala de aplicación de este método es relativamente pequeña. Después de hablar de replicación, hablemos de conmutación. De hecho, MySQL oficialmente no proporciona la función de descubrir y transferir fallas automáticamente, y básicamente depende de herramientas de terceros para lograrlo.
El primero es Keepalived, donde el Maestro y el Esclavo se detectan mutuamente y se preguntan mutuamente el estado de supervivencia en cualquier momento. Cuando se producen fluctuaciones de red o problemas de red, puede ocurrir un problema de cerebro dividido, convirtiéndose en dos maestros y esclavos, y los datos se escriben incorrectamente. El segundo es el método MMM, M1M2 actúa como maestro y respaldo entre sí, además de un nodo esclavo como redundancia. Según la figura, aunque es un modo maestro dual, solo un nodo puede escribir al mismo tiempo en este modo. Cuando se descubre que el nodo de escritura principal falla, el vip se cambiará a otro nodo principal. En general, este método es más antiguo y tiene más problemas. El tercer tipo es MHA, que actualmente se usa ampliamente. Este método consta de un grupo de replicación y un nodo de administración. Cada grupo de replicación consta de al menos tres nodos de datos. Los nodos de datos implementan agentes de monitoreo e informan al nodo de administración periódicamente. hay un problema con el nodo maestro Cuando, el nodo de administración decide si cambiar al nodo esclavo. Tencent Cloud ha implementado un conjunto de detección de fallas por sí mismo. La estructura se muestra a la derecha. Los nodos de monitoreo de alta disponibilidad realizan la detección y conmutación de fallas. Además, actualmente estamos reconstruyendo MySQL para lograr alta disponibilidad, lo que permitirá la detección y recuperación de fallas en 30 segundos, lo que mejorará enormemente la alta disponibilidad.
Cuando se trata de la arquitectura de alta disponibilidad del clúster, las más famosas son PXC, MGC y MGR, y MGC es una arquitectura de alta disponibilidad proporcionada oficialmente con conmutación por error. . La estructura jerárquica general es así. MGR existe en forma de complemento. MGR transforma principalmente el protocolo de replicación. Debido a que MGR admite multiactividad, otro enfoque aquí es la detección de conflictos. Al mismo tiempo, siga lo que prevalezca, MGR implementa la detección de conflictos basada en el protocolo Paxos. Echemos un vistazo a la estructura a continuación. MGR admite la escritura en múltiples nodos, es decir, multiactivo. Admite la eliminación automática de un nodo si falla y se une automáticamente al clúster después de la recuperación. Esta imagen presenta la lógica de flujo de datos de MGR. Hay tres nodos en la imagen que forman el grupo MGR más pequeño. Suponiendo que DB1 tiene una confirmación de escritura, durante la fase de preparación, el complemento MGR genera un conjunto denominado WriteSet y lo transmite a otros nodos. Esta colección WriteSet contiene el binlog para esta confirmación y la clave única actualizada, que consta del nombre de la base de datos, el nombre de la tabla y la clave principal. Como se puede ver desde aquí, MGR tiene una restricción, es decir, debe haber una clave principal en la tabla; de lo contrario, no se puede realizar la detección de conflictos. Dijimos que cuando el nodo reciba esta información, realizará una comparación. Cada nodo tiene un caché para guardar la situación de sincronización actual, que es el GTID SET correspondiente a la clave única.
El resultado de la comparación se devolverá a DB1, siempre que más de la mitad de los nodos devuelvan OK, se puede enviar. Luego, DB1 realizará la operación de colocación del disco binlog y luego devolverá OK al cliente. Otros nodos realizarán la operación de escribir Relaylog y luego realizarán la operación de reproducción. Si la mayoría de los nodos devuelven conflictos, DB1 realizará una operación de reversión y otros nodos descartarán el binlog copiado.
De hecho, las ideas de PXC y MGC son similares. Debe decirse que tomaron prestadas las ideas de MGR, porque tanto PXC como MGC aparecieron relativamente temprano. Realizar la transmisión configurada en WriteSet. Transmisión verificada y adjudicada.
Finalmente, hablemos de la arquitectura de alta disponibilidad de NewSQL. En primer lugar, quiero rendir homenaje a AWS, que ha incubado un excelente producto NewSQL: Aurora. ¿Cómo surgió Aurora? Esto tiene que ver con la arquitectura de la base de datos de AWS. Miremos esta imagen. La arquitectura de la base de datos de AWS está en máquinas virtuales y discos en la nube. Todo el mundo sabe que MySQL tiene muchos registros, por lo que una gran cantidad de IO se completa a través de la red que consume mucho tiempo. La arquitectura de AWS, el rendimiento no se puede mejorar. Sobre esta base, conozcamos a Aurora.
Aurora es una arquitectura que separa la informática y el almacenamiento y es una estructura típica de disco compartido. El almacenamiento subyacente utiliza 6 copias y se implementa en 3 AZ diferentes para garantizar que, si una AZ falla o se pierde una copia de hasta dos AZ, los datos no se perderán y la empresa pueda atender al mundo exterior con normalidad. El concepto de Aurora es "el registro es una base de datos", ha transformado completamente la capa de almacenamiento de MySQL. El concepto de Aurora es "el registro es una base de datos", ha transformado completamente la capa de almacenamiento de MySQL, descartando muchos LOG y dejando solo Redolog, y Redolog tiene la capacidad de hacerlo. convertir páginas Innodb. De esta forma, Aurora pretende reducir el ratio de IO en al menos un 85%. Además, su copia de seguridad y archivo se trasladan a nodos de almacenamiento, lo que hace que la copia de seguridad y la recuperación sean más rápidas y seguras. La sensación general de Aurora es que es más realista y de costo relativamente bajo.
El otro es Polar de Alibaba Cloud, que tiene un concepto diferente al de AWS. Alibaba Cloud cree que la red futura no será un problema y que la calidad de la red futura puede estar cerca del autobús, por lo que es. La estructura de la red está en la sala de computadoras RDMA y hay relativamente pocas acciones de registro importantes. Esto garantiza que las nuevas funciones posteriores de la comunidad MySQL se puedan iterar rápidamente. Polardb también tiene una arquitectura de disco compartido y todos sus nodos de almacenamiento se implementan a través de discos paralelos. Polardb también tiene una arquitectura de disco compartido y sus nodos de almacenamiento utilizan el protocolo ParallelRaft para garantizar la integridad de los datos. Esta es una buena arquitectura, pero el costo es relativamente alto.
Nuestro propio NewSQL se está desarrollando en Tencent Cloud, pero aún no se ha lanzado oficialmente. Nuestro nombre es CynosDB. Por el contrario, nuestra filosofía es equilibrar los dos y construir una nueva base de hardware para alto nivel. redes de mayor velocidad en el futuro. Logrará un mayor rendimiento, servicios más robustos y una mayor disponibilidad en el futuro. Por favor espera y verás.
Esto termina mi intercambio esta vez.
Preguntas y respuestas
P: Me gustaría preguntar, en la industria de alta concurrencia de Tencent Games, ¿qué tipo de arquitectura utilizamos principalmente?
Respuesta: Tencent tiene muchos proyectos de autoinvestigación dentro de Tencent, pero básicamente todos nos basamos en la replicación de datos. Existe una arquitectura de clúster distribuida internamente, como phxsql.
P: ¿Cómo garantizar que la latencia general del repositorio permanezca sin cambios en condiciones de alta concurrencia?
Respuesta: Puede activar la replicación paralela y el negocio se completará en diferentes repositorios y tablas distribuidas en varias instancias.
P: Por ejemplo, en la categoría de juegos, hay muchas personas en línea al mismo tiempo durante el período pico del juego. En este caso, ¿cómo puedo ver los datos en segundo plano?
Respuesta: Los datos del punto de acceso se pueden superponer. La primera capa puede utilizar el método de almacenamiento en caché KV, como Redis, para mejorar la velocidad de lectura de los datos del punto de acceso. La última capa utiliza MySQL para sincronizar periódicamente los datos con el disco.
P: En este caso, ¿cómo garantizar la coherencia de la base de datos?
Respuesta: Los datos escritos se pueden escribir directamente en la base de datos MySQL sin pasar por el caché KV. No hay datos en el caché durante la lectura y es necesario extraerlos de la base de datos. Además, el caché KV también tiene una función de aterrizaje, y los datos no críticos también se pueden aterrizar sin usar MySQL.
Lecturas relacionadas
Recomendaciones diarias de cursos ¡Aprendizaje automático en acción! Comience rápidamente con el negocio de publicidad en línea y el conocimiento correspondiente al CTR
Este artículo ha sido autorizado por el autor para ser publicado por Tencent Cloud+ Community. Para obtener más artículos originales, haga clic aquí
Buscar. Y siga la cuenta pública "Comunidad Yunjia". Obtenga información técnica lo antes posible, sígala y responda al 1024 para recibir un paquete de regalo de curso técnico.
¡Masima experiencia práctica técnica, todo en la comunidad Yunga!
Cómo diseñar e implementar MySQL de alta disponibilidad
Etiquetas: Responsable Preguntas básicas Características Catálogo Tres formas **** Disfrute completamente de Alibaba