[MySQL] Performance Tuning (5): Arquitectura. Subtabla de clúster y subbase de datos

1. Clúster de base de datos

Si un solo servicio de base de datos no puede cumplir con los requisitos de acceso, entonces podemos hacer una solución de clúster de base de datos. El clúster inevitablemente enfrentará un problema, es decir, el problema de la coherencia de los datos entre diferentes nodos. Si lee y escribe varios nodos de base de datos al mismo tiempo, ¿cómo mantener la coherencia de todos los datos de los nodos?

1.1 Arquitectura maestro-esclavo

En este momento, necesitamos usar tecnología de replicación. El nodo replicado se llama maestro y el nodo replicado se llama esclavo. El esclavo en sí también se puede utilizar como fuente de datos para otros nodos, lo que se denomina replicación en cascada.

¿Cómo se logra la replicación maestro-esclavo? La declaración de actualización registrará el binlog , que es una especie de registro lógico. Con este binlog, el servidor esclavo obtendrá el archivo binlog del servidor maestro, luego analizará la declaración SQL interna y la ejecutará en el servidor esclavo para mantener la coherencia de los datos maestro y esclavo.

Hay tres hilos involucrados:

1. Subproceso de volcado de registro: hay un subproceso de volcado de registro en el nodo maestro, que se utiliza para enviar binlog al esclavo.
2. Subproceso de E / S: conéctese al maestro para obtener el binlog y analice el binlog para escribir el registro de retransmisión (registro de retransmisión).
3. Subproceso SQL: el subproceso SQL de la biblioteca se utiliza para leer el registro de retransmisión y escribir datos en la base de datos.

1.2 Separación de lectura y escritura

Después de realizar el esquema de replicación maestro-esclavo, solo escribimos datos en el nodo maestro y la solicitud de lectura se puede compartir con el nodo esclavo. A esta solución la llamamos separación de lectura y escritura.

PD: ¿Cuál es la relación entre la replicación maestro-esclavo y la separación de lectura y escritura? La replicación maestro-esclavo de mysql y la separación de lectura y escritura de mysql están estrechamente relacionadas.

1. Primero, debemos implementar la replicación maestro-esclavo. Solo cuando se complete la replicación maestro-esclavo, la lectura y escritura de datos se pueden separar sobre esta base.
2. Generalmente, después de sincronizar los datos a través de la replicación maestro-esclavo, se usa la separación de lectura y escritura para mejorar la capacidad de carga concurrente de la base de datos.

La separación de lectura-escritura significa escribir solo en el servidor maestro mysql y solo leer en el servidor esclavo mysql. El principio básico es dejar que la base de datos principal maneje las consultas transaccionales, mientras que la base de datos esclava maneja las consultas seleccionadas. La replicación de la base de datos se utiliza para sincronizar los cambios provocados por las consultas transaccionales en las bases de datos del clúster.

La separación de lectura y escritura puede reducir la presión de acceso del servidor de la base de datos hasta cierto punto, pero es necesario prestar especial atención al problema de la coherencia de los datos maestro-esclavo. Si escribimos en el maestro e inmediatamente consultamos al esclavo, y los datos del esclavo no se han sincronizado en este momento, ¿qué debemos hacer?

problema

¿Dónde es lenta la replicación maestro-esclavo? En el MySQL temprano, el hilo SQL del esclavo era de un solo hilo . El maestro puede soportar la ejecución paralela de sentencias SQL El número máximo de conexiones configuradas es el número máximo de ejecuciones SQL simultáneas. El SQL del esclavo solo se puede ejecutar en una cola de un solo subproceso. En el caso de una gran cantidad de concurrencia en la biblioteca principal, los datos de sincronización definitivamente se retrasarán.

¿Por qué no se puede ejecutar el hilo SQL en la biblioteca esclava en paralelo? Por ejemplo, la biblioteca principal ejecutó varias declaraciones SQL. Primero, el usuario publicó un comentario, luego modificó el contenido y finalmente eliminó el comentario. El orden de ejecución de estas tres sentencias en la biblioteca esclava no debe invertirse. ·

insert into user_comments(10000009,'nice'); 
update user_comments set content ='verygood' where id=10000009; 
delete from user_comments where id=10000009;

¿Cómo resolver este problema, es decir, cómo reducir el retraso de la replicación maestro-esclavo?

1.3 Solución de demora

En primer lugar, debemos saber que en el proceso de replicación maestro-esclavo, MySQL se replica de forma asíncrona de forma predeterminada. En otras palabras, para el nodo maestro, se escribe el binlog, finaliza la transacción y se devuelve al cliente. Para el esclavo, cuando se recibe el binlog, se termina, al maestro no le importa si los datos del esclavo se escribieron correctamente.

Si desea reducir el retraso de la replicación maestro-esclavo, ¿puede esperar a que se completen todas las transacciones de la base de datos esclava antes de regresar al cliente? Este método se denomina replicación sincrónica completa. Una vez que los datos se escriben en la biblioteca esclava, la biblioteca maestra los devolverá al cliente. Aunque este método puede garantizar que los datos se hayan sincronizado correctamente antes de la lectura, debería poder pensar en los efectos secundarios de que el tiempo de ejecución de la transacción se alargará, lo que hará que el rendimiento del nodo maestro disminuya.

¿Existe una forma mejor? No solo reduce la latencia de las escrituras esclavas, sino que no aumenta significativamente el tiempo que el maestro regresa al cliente.

1. Modo de conexión maestro-esclavo: replicación semisincrónica

Entre la replicación asincrónica y la replicación completamente sincrónica, existe otra forma de replicación semisincrónica. ¿Qué aspecto tiene la replicación semisincrónica?

La biblioteca principal no regresa al cliente inmediatamente después de ejecutar la transacción enviada por el cliente, sino que espera al menos uno de los binlogs recibidos de la biblioteca y escrito en el registro de retransmisión antes de regresar al cliente. El maestro no esperará mucho tiempo, pero cuando regrese al cliente, los datos se escribirán con éxito, porque solo le queda el último paso: leer el registro del relé y escribir en la biblioteca esclava.

Si queremos utilizar la replicación semisincrónica en la base de datos, debemos instalar un complemento, que es aportado por un ingeniero de Google. Este complemento ya está disponible en el directorio de complementos de mysql:

cd /usr/lib64/mysql/plugin/

La biblioteca principal y la biblioteca secundaria son complementos diferentes, que deben habilitarse después de la instalación:

-- 主库执行 
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1; 
show variables like '%semi_sync%';

-- 从库执行 
INSTALL PLUGIN rpl_semi_sync_slave SONAME'semisync_slave.so'; 
set global rpl_semi_sync_slave_enabled=1;
show global variables like '%semi%';

En comparación con la replicación asincrónica, la replicación semisincrónica mejora la seguridad de los datos. Al mismo tiempo, también causa un cierto grado de retraso. Es necesario esperar a que un esclavo escriba el registro de retransmisión. Hay un proceso de interacción de red adicional. Por lo tanto, Replicación semisincrónica Se utiliza mejor en redes de baja latencia.

Esto es para asegurar la escritura de datos esclavos desde la perspectiva de la conexión entre la biblioteca principal y la biblioteca esclava. Otra idea, si desea reducir el retraso de la sincronización maestro-esclavo y reducir el tiempo de espera causado por la ejecución de SQL, ¿hay alguna manera de permitir que se ejecuten múltiples declaraciones SQL en paralelo en la base de datos esclava en lugar de estar en cola para su ejecución?

2. Replicación paralela de múltiples bases de datos: replicación GTID de la replicación asincrónica

¿Cómo implementar la replicación en paralelo? Imagínese que si se ejecutan tres sentencias en tres bases de datos y operan en sus respectivas bases de datos, ¿es seguro que no habrá problemas de concurrencia? Tampoco se requiere el orden de ejecución. Por supuesto que lo es, por lo que si está operando tres bases de datos, los subprocesos SQL de las tres bases de datos se pueden ejecutar simultáneamente. Esta es la replicación paralela de múltiples bases de datos admitida en la versión MySQL 5.6.

Pero en la mayoría de los casos, tenemos una sola base de datos con múltiples tablas ¿Cómo podemos lograr la replicación en paralelo en una base de datos? En otras palabras, sabemos que la base de datos en sí admite múltiples transacciones al mismo tiempo; ¿por qué estas transacciones se pueden ejecutar en paralelo en la base de datos principal, pero no habrá problemas?

Debido a que no interfieren entre sí, por ejemplo, estas transacciones operan en diferentes tablas u operan en diferentes filas. No hay competencia por los recursos e interferencia con los datos. Las transacciones ejecutadas en paralelo en la biblioteca principal ciertamente se pueden ejecutar en paralelo en la biblioteca esclava, ¿verdad? Por ejemplo, hay tres transacciones en el maestro que operan en tres tablas al mismo tiempo ¿Se pueden ejecutar estas tres transacciones en paralelo en el esclavo?

Por lo tanto, podemos dividir las transacciones que se ejecutan en paralelo en la biblioteca principal en un grupo y darles números.Las transacciones de este grupo también se pueden ejecutar en paralelo en la biblioteca esclava. Este número, lo llamamos GTID (GlobalTransaction Identifiers), este tipo de replicación maestro-esclavo, lo llamamos replicación basada en GTID.

Si queremos usar la replicación GTID, podemos abrirlo modificando los parámetros de configuración, que está cerrado por defecto:

show global variables like 'gtid_mode';

resumen

Ya sea optimizando la conexión entre maestro y esclavo, o permitiendo que el esclavo ejecute SQL en paralelo, se trata de resolver el problema de la demora en la replicación maestro-esclavo desde el nivel de la base de datos.

Además del nivel de la base de datos en sí, a nivel de aplicación, también tenemos algunos métodos para reducir el retraso de la sincronización maestro-esclavo. Después de haber realizado la replicación maestro-esclavo, si los datos almacenados en un solo nodo maestro o en una sola tabla son demasiado grandes, por ejemplo, una tabla tiene cientos de millones de datos, el rendimiento de la consulta de la única tabla seguirá disminuyendo, y necesitamos comparar aún más la clasificación de datos de una sola tabla y la división de los nodos de la base de datos, esta es la subtabla de la subbase de datos.

2. Subbase de datos y subtabla

La subbase de datos vertical reduce la presión de concurrencia. Nivele la mesa para solucionar el cuello de botella de almacenamiento.

1) Sub-biblioteca vertical

Divida una base de datos en diferentes bases de datos según el negocio

2) Subtabla de subbase de datos horizontal

Distribuya los datos de una sola tabla a múltiples bases de datos de acuerdo con ciertas reglas.

3. Consiga una alta disponibilidad

A través de la subtabla maestro-esclavo o sub-base de datos se puede reducir la presión de acceso y la presión de almacenamiento de un solo nodo de base de datos, y lograr el propósito de mejorar el rendimiento de la base de datos, pero ¿y si el nodo maestro deja de funcionar? Por lo tanto, High Available también es la base para un alto rendimiento.

1) Replicación maestro-esclavo: El esquema tradicional HAProxy + keepalived se basa en la replicación maestro-esclavo.

2) Clúster NDB: Clúster MySQL basado en el motor de almacenamiento del clúster NDB. Enlace de referencia ...

3) Galera: una solución de clúster de replicación síncrona multimaestro.

4) MHA / MMM: MMM (administrador de replicación maestro-maestro para MySQL), una arquitectura de alta disponibilidad multimaestro, fue desarrollada por un japonés.Las empresas como Meituan también usaron mucho MMM en los primeros días. MHA (MySQL Master High disponible).

Tanto MMM como MHA proporcionan una IP virtual al exterior y monitorean el nodo maestro y el nodo esclavo. Cuando el nodo maestro falla, un nodo esclavo debe ser promovido al nodo maestro, y los datos faltantes en el nodo esclavo en lugar del maestro. El nodo debe estar lleno. Apunte el VIP al nuevo nodo maestro. Link de referencia...

5) MGR: InnoDB Cluster lanzado por MySQL versión 5.7.17, también llamado MySQL Group Replicatioin (MGR), este paquete incluye mysql shell y mysql-route. Enlace de referencia 1 , enlace de referencia 2

En resumen: el problema que debe resolver una solución HA de alta disponibilidad es cómo actualizar un esclavo con los datos más recientes para convertirse en maestro cuando un nodo maestro está inactivo. Si ejecuta varios maestros al mismo tiempo, debe resolver el problema de la replicación de datos entre maestros y el enrutamiento de la conexión para los clientes. Las diferentes soluciones tienen diferentes dificultades de implementación y diferentes costos de gestión de operación y mantenimiento.

Lo anterior es la optimización de la arquitectura, puede comenzar con clusters, sub-bases de datos y sub-tablas, y prestar atención a lograr una alta disponibilidad.