Problemas que pueden surgir en la separación de lectura y escritura en MySQL

prefacio

La separación de lectura y escritura es una arquitectura de uso frecuente en MySQL. A través de la separación de lectura y escritura, se logra la expansión horizontal. Las operaciones de escritura y actualización se realizan en el servidor de origen y las operaciones de lectura de datos se realizan desde el servidor esclavo. Al aumentar la capacidad del servidor esclavo El número puede mejorar enormemente la capacidad de lectura de la base de datos.

La arquitectura de alta disponibilidad en MySQL ha mostrado una tendencia a volverse cada vez más compleja, pero ha evolucionado desde un maestro y un esclavo más básicos, por lo que aquí comprenderemos los principios básicos de maestro-esclavo.

Primero, comprendamos la diferencia entre el modo maestro-esclavo, maestro-esclavo y maestro dual.

doble maestro

imagen

Hay dos bibliotecas principales, cada biblioteca principal puede leer y escribir, y se pueden realizar operaciones de sincronización de datos entre las dos bibliotecas principales.

Maestro-esclavo

imagen

En maestro-esclavo, la escritura de datos se realiza en el nodo maestro, la lectura de datos se realiza en el nodo esclavo y la biblioteca maestra sincronizará los datos con la biblioteca esclava.

Activo y en espera

imagen

Las bases de datos primarias y secundarias solo se utilizan para la copia de seguridad de datos. No se realizan operaciones de lectura y escritura. La lectura y escritura de datos se realizan en la base de datos primaria, y la base de datos primaria sincronizará los datos con la base de datos secundaria.

El retraso de datos que se analiza a continuación se basa principalmente en el modo maestro-esclavo. La sincronización de datos maestro-esclavo, maestro-esclavo y maestro dual tienen los mismos principios, por lo que no los analizaremos aquí.

1. Arquitectura de separación de lectura y escritura.

La separación de lectura y escritura de uso común tiene las dos implementaciones siguientes:

1. El cliente se da cuenta de la separación entre lectura y escritura;

2. Implementar la separación de lectura y escritura según la capa de proxy intermedia.

Implementar separación de lectura y escritura según el cliente.

El cliente realiza activamente el equilibrio de carga y, de acuerdo con select、insert la clasificación de enrutamiento, la solicitud de lectura se envía a la biblioteca de lectura y la solicitud de escritura se reenvía a la biblioteca de escritura.

Este método se caracteriza por un mejor rendimiento, se implementa directamente en el código, no se requiere soporte de hardware adicional, la arquitectura es simple y la resolución de problemas es más conveniente.

Las desventajas deben estar integradas en el código y los desarrolladores deben implementarlo. La operación y el mantenimiento no pueden intervenir. Para códigos grandes, es necesario cambiar mucho código para lograr la separación de lectura y escritura.

imagen

Implementar separación de lectura y escritura basada en proxy intermedio

La capa de proxy intermedia implementa la separación de lectura y escritura. Hay un proxy de capa de proxy intermedia entre MySQL y el cliente. El cliente solo se conecta al proxy y el proxy determina la ruta de distribución de la solicitud en función del tipo y el contexto de la solicitud.

imagen

La arquitectura con proxy es más amigable para el cliente. El cliente no necesita prestar atención a los detalles del backend, y el mantenimiento de la conexión y el mantenimiento de la información del backend los realiza el proxy. Pero en este caso, los requisitos para el equipo de mantenimiento back-end serán mayores. Además, el proxy también debe tener una arquitectura de alta disponibilidad. Por lo tanto, todo lo relacionado con la arquitectura proxy es relativamente complicado.

Sin embargo, ese método de implementación encontrará el problema del retraso maestro-esclavo en la separación de lectura y escritura. Debido al retraso maestro-esclavo, el cliente acaba de completar una transacción de actualización y luego inicia inmediatamente una consulta. Si la consulta es del esclavo base de datos, puede leer El estado es el estado antes de la actualización.

2. Cómo garantizar la coherencia de los datos maestro-esclavo en MySQL

La sincronización maestro-esclavo de los datos MySQL se logra principalmente a través de binlog. La biblioteca esclava utiliza el binlog en la biblioteca principal para reproducir y lograr la sincronización maestro-esclavo.

Echemos un vistazo al principio de implementación.

En la replicación maestro-esclavo, la biblioteca esclava usa binlog en la biblioteca maestra para reproducir y lograr la sincronización maestro-esclavo.Durante el proceso de replicación, se utilizan principalmente dump thread，I/O thread，sql thread estos tres subprocesos .

IO threadstart slave : Creado al ejecutar declaraciones de la biblioteca esclava , responsable de conectarse a la biblioteca principal, solicitar binlog, recibir binlog y escribir en el registro de retransmisión;

dump thread: Se utiliza para que la biblioteca maestra sincronice el binlog con la biblioteca esclava y es responsable de responder a las IO thread solicitudes del esclavo. La biblioteca principal creará una conexión para cada biblioteca esclava dump thready luego sincronizará el binlog con la biblioteca esclava;

sql thread: Lee relay log y ejecuta comandos para actualizar los datos del esclavo.

Eche un vistazo al proceso de replicación:

1. La biblioteca principal recibe el comando de actualización, realiza la operación de actualización y genera binlog;

2. La biblioteca esclava establece una conexión larga entre el maestro y el esclavo;

3. La biblioteca principal dump_thread lee el binlog localmente y lo envía a la biblioteca esclava;

4. La biblioteca esclava obtiene el binlog de la biblioteca principal y lo almacena localmente para convertirlo en relay logun (registro de retransmisión);

5. El hilo sql_thread lee, relay log analiza y ejecuta comandos para actualizar datos.

hay que tener en cuenta es

Cuando se crea inicialmente la relación maestro-esclavo, la biblioteca esclava especifica la sincronización. Por ejemplo, en una relación maestro-esclavo basada en sitio, si la biblioteca esclava dice "Quiero iniciar la sincronización desde la posición P del archivo binlog A", la biblioteca maestra comenzará desde esta posición especificada y luego enviará datos hacia atrás.

Una vez establecida la relación de replicación maestro-esclavo, es la base de datos maestra la que decide "enviar datos a la base de datos esclava". Solo si la base de datos maestra tiene nuevos registros, se enviará a la base de datos esclava.

Binlog tiene tres formatos statement，row y mixto.

1. Declaración (Replicación basada en declaraciones, SBR): cada SQL que modifique datos se registrará en el binlog, que registra el SQL ejecutado;

El modo de declaración solo registra el SQL ejecutado y no necesita registrar cambios en cada fila de datos, por lo que reduce en gran medida la cantidad de registros binlog, evita una gran cantidad de operaciones de IO y mejora el rendimiento del sistema.

Es precisamente porque el modo Declaración solo registra SQL, y si algunos SQL contienen funciones, los resultados de la ejecución pueden ser inconsistentes.

Por ejemplo, la función uuid () genera una cadena aleatoria cada vez que se ejecuta, y el uuid se registra en el maestro. Después de sincronizar con el esclavo, si se ejecuta nuevamente, se obtendrá otro resultado.

Por lo tanto, habrá algunos problemas de coherencia de los datos al utilizar el formato Declaración.

2. Fila (replicación basada en filas, RBR): no registra información de contexto de la declaración SQL, solo registra cómo se ha modificado un determinado registro;

El contenido del registro en formato Fila registrará claramente los detalles de cada fila de modificación de datos, de modo que no habrá ninguna situación en la que los datos en la Declaración no se puedan copiar normalmente.

Por ejemplo, si hay 100 filas de datos que cumplen las condiciones para una modificación, estas 100 filas de datos se registrarán detalladamente en binlog. Por supuesto, en este momento, el contenido del archivo binlog es mucho más que el primero.

Sin embargo, el formato de fila también tiene un gran problema, es decir, la cantidad de registros es demasiado grande, especialmente para operaciones como actualización por lotes, eliminación de tabla completa y modificación de tabla, ya que es necesario registrar los cambios en cada fila de datos. , se generará una gran cantidad de registros, que también pueden causar problemas de rendimiento de IO.

3. Mixto (Replicación de base mixta, MBR): una mezcla de Declaración y Fila.

Debido a que algunos binlogs de formato de declaración pueden causar inconsistencia maestro-esclavo, se debe utilizar el formato de fila.

Pero la desventaja del formato de fila es que ocupa mucho espacio. Por ejemplo, si usa una declaración de eliminación para eliminar 100,000 filas de datos, si usa una declaración, se registrará una declaración SQL en el binlog, ocupando docenas de bytes de espacio. Pero si usa binlog en formato de fila, debe escribir los 100.000 registros en el binlog. Hacerlo no solo ocupará más espacio, sino que también consumirá recursos de IO al escribir binlog, lo que afectará la velocidad de ejecución. Por lo tanto, MySQL tomó una solución de compromiso: tener un binlog de formato mixto.

El formato mixto significa que MySQL determinará por sí mismo si esta declaración SQL puede causar inconsistencia maestro-esclavo. Si es posible, use el formato de fila; de lo contrario, use el formato de declaración. En otras palabras, el formato mixto puede aprovechar las ventajas del formato de declaración y al mismo tiempo evitar el riesgo de inconsistencia de los datos.

Sin embargo, ahora cada vez más escenarios establecerán el formato binlog de MySQL en fila, como el siguiente escenario de recuperación de datos.

Aquí delete、insert analizamos el problema de la recuperación de datos desde la perspectiva de tres declaraciones SQL: actualización y actualización.

1. Eliminar: si se realiza una operación de eliminación, es necesario restaurar los datos. Binlog en formato de fila también guardará la información completa de la fila eliminada. Por lo tanto, si después de ejecutar una declaración de eliminación, descubre que se han eliminado datos incorrectos, puede convertir directamente la declaración de eliminación registrada en el binlog en una inserción e insertar los datos eliminados incorrectamente nuevamente para recuperarlos;

2. Insertar: si se realiza una operación de inserción, es necesario restaurar los datos. En el formato de fila, toda la información del campo se registrará en el binlog de la declaración de inserción. Esta información se puede utilizar para ubicar con precisión la fila que se acaba de insertar. En este momento, puede convertir directamente la instrucción de inserción en una instrucción de eliminación para eliminar la fila de datos insertada por error;

3. Actualización: si se realiza una operación de actualización, se requiere la recuperación de datos. El binlog registrará toda la fila de datos antes de la modificación y toda la fila de datos después de la modificación. Por lo tanto, si la declaración de actualización se ejecuta por error, solo necesita intercambiar las dos líneas de información antes y después del evento y luego ejecutarla en la base de datos para restaurar la operación de actualización.

Problema de copia circular

A partir del principio de binlog anterior, podemos saber que la sincronización de datos maestro-esclavo en MySQL utiliza binlog para mantener la coherencia de los datos.

Sin embargo, la estructura doble M puede tener problemas con la replicación cíclica.

imagen

¿Qué es la arquitectura doble M, la estructura doble M y la estructura MS? De hecho, la diferencia es solo una línea más, es decir: siempre existe una relación maestro-esclavo entre los nodos A y B. De esta forma, no es necesario modificar la relación maestro-esclavo al cambiar.

La lógica empresarial actualiza una declaración en el nodo A y luego envía el binlog generado al nodo B. El nodo B también generará binlog.

Si el nodo A también es la biblioteca esclava del nodo B, el nodo B también pasará el binlog al nodo A, y el nodo A ejecutará el binlog pasado por el nodo B. De esta manera, el nodo A y el nodo B repetirán continuamente esta declaración de actualización, que es una replicación circular.

¿Cómo resolverlo?

1. Se estipula que las dos bibliotecas server id deben ser diferentes, si son iguales no se puede establecer la relación maestro-esclavo entre ellas;

2. Una biblioteca esclava recibe el binlog y durante el proceso de reproducción, server id se genera un nuevo binlog que es el mismo que el binlog original;

3. Después de que cada biblioteca recibe el registro enviado desde su propia biblioteca principal, primero juzga server idque si es igual que el suyo, significa que el registro fue generado por ella misma y luego lo descarta directamente.

De esta manera, cuando se establece la estructura doble M, el flujo de ejecución del registro quedará así:

1. Todas las transacciones actualizadas desde el nodo A se registran en el binlog server id;

2. Después de ser transferido al nodo B y ejecutado una vez, el binlog generado por el nodo B server id también es el de A server id;

3. Envíelo de regreso al nodo A, y A juzgará que server id es el mismo que el suyo, por lo que no volverá a procesar este registro. Por tanto, aquí se rompe el bucle infinito.

3. Retraso de sincronización maestro-esclavo

El retraso de sincronización maestro-esclavo es la diferencia entre el momento en que la biblioteca esclava completa la ejecución y el momento en que la biblioteca maestra completa la ejecución de la misma transacción.

1. La biblioteca principal A completa una transacción y la escribe en binlog. El tiempo registrado es T1;

2. Pase los datos a la biblioteca esclava y la biblioteca esclava recibirá el binlog. La hora en que se completa la recepción se registra como T2;

3. La biblioteca esclava B ejecuta y completa la transacción recibida. Este tiempo se registra como T3.

El tiempo de retardo maestro-esclavo es la diferencia de tiempo entre T3-T1.

El valor de second_behind_master se puede obtener mediante show slave status el comando, que indica cuántos segundos está retrasada la biblioteca esclava actual.

Cómo se calcula second_behind_master:

1. El binlog de cada transacción tiene un campo de hora, que se utiliza para registrar la hora de escritura en la base de datos principal;

2. Obtenga el valor del campo de hora de la transacción que se está ejecutando actualmente de la biblioteca, calcule la diferencia entre este y la hora actual del sistema y podrá obtener segundos_behind_master.

En pocas palabras, second_behind_master es T3 -T1 la diferencia horaria anterior.

Si la configuración de tiempo de las máquinas maestra y esclava es inconsistente, ¿dará lugar a retrasos maestro-esclavo inexactos?

La respuesta es no. Cuando la biblioteca esclava se conecta a la biblioteca principal, obtendrá SELECT UNIX_TIMESTAMP()la hora actual de la biblioteca maestra a través de una función. Si se descubre que la hora del sistema de la biblioteca principal no coincide con la suya, la biblioteca esclava la deducirá activamente. al realizar el cálculo de second_behind_master.Esta diferencia.

4. Razones del retraso en la sincronización maestro-esclavo

Posibles razones del retraso en la sincronización maestro-esclavo:

1. El rendimiento de la base de datos esclava es peor que el de la máquina donde se encuentra la base de datos principal;

Compare el rendimiento de la biblioteca esclava: si la capacidad de replicación de la biblioteca esclava es menor que la de la biblioteca maestra, cuando la biblioteca maestra esté bajo una gran presión de escritura, provocará retrasos de datos a largo plazo en la biblioteca esclava.

2. La presión sobre la biblioteca esclava es alta;

Realizar una gran cantidad de consultas en la biblioteca esclava puede consumir muchos recursos de CPU en la biblioteca esclava, lo que afectará la velocidad de sincronización y provocará un retraso maestro-esclavo.

3. Ejecución de asuntos importantes;

Cuando ocurre una transacción, la base de datos maestra debe esperar a que se complete la transacción antes de poder escribirla en el binlog. Supongamos que la transacción que se está ejecutando es una inserción de datos muy grande. Estos datos se transmiten a la base de datos esclava y también Se necesita una cierta cantidad de tiempo para sincronizar los datos de la base de datos esclava, lo que provocará retrasos en los datos en el nodo esclavo.

4. La conmutación maestro-esclavo o maestro-esclavo ocurre cuando la biblioteca principal es anormal.

Cuando se produce un cambio de base de datos maestra, pueden ocurrir inconsistencias en los datos. Existen dos estrategias para el cambio maestro-esclavo:

Estrategia de prioridad de confiabilidad:

1. Primero, juzgue los segundos_detrás_master de la biblioteca esclava. Si es menor que un valor tolerable, continúe con el siguiente paso; de lo contrario, continúe reintentando este paso;

2. Cambie la biblioteca principal A al estado de solo lectura y establezca solo lectura en verdadero;

3. Determine second_behind_master de la biblioteca esclava B hasta que este valor sea 0;

4. Cambie la biblioteca esclava B a un estado de lectura-escritura, establezca solo lectura en falso y la biblioteca esclava B se convierte en la nueva biblioteca maestra;

5. La solicitud comercial de actualización se cambiará a la biblioteca esclava B.

Hay un tiempo no disponible durante este proceso de conmutación. Después del paso 2, tanto la biblioteca principal A como la biblioteca esclava B están en estado de solo lectura. En este momento, el sistema está en un estado de no escritura. Hasta que el estado de solo lectura de la La biblioteca esclava B se vuelve falsa. En este momento, solo entonces las solicitudes de escritura se pueden recibir normalmente.

Paso 3: Determine segundos_behind_master como 0. Esta operación es la que lleva más tiempo. A través del juicio temprano en el paso 1, puede asegurarse de que el valor de segundos_behind_master sea lo suficientemente pequeño como para reducir el tiempo de espera en el paso 3.

Estrategia de prioridad de disponibilidad:

Si los pasos 4 y 5 se ajustan para ejecutarse desde el principio, sin esperar la sincronización de datos de la base de datos principal, la conexión se cambia directamente a la base de datos esclava B, de modo que la base de datos esclava B puede leer y escribir directamente, por lo que que el sistema casi no tendrá tiempo indisponible.

Esta estrategia puede garantizar la disponibilidad del servicio en la mayor medida posible, pero se producirán inconsistencias en los datos porque la solicitud de escritura se cambia directamente a la biblioteca esclava B, es decir, B se establece como la nueva biblioteca maestra, porque la última base de datos no tiene se ha sincronizado con la biblioteca B. Una vez que los datos se convierten en la biblioteca principal, esta parte de los datos se pierde.

5. Cómo lidiar con el retraso maestro-esclavo

Ante el retraso maestro-esclavo, existen varias soluciones:

1. Fuerce la solución de base de datos principal;

2. plan de sueño;

3. Determinar el esquema maestro-esclavo sin demoras;

4. Cooperar con la solución semisincronizada;

5. Espere el plano de ubicación del almacén principal;

6. Etc. Esquema GTID.

Forzar el plan de la biblioteca principal

El acceso forzado a la solución de la base de datos principal es esencialmente para clasificar las consultas, y las consultas que no pueden tolerar retrasos en la sincronización se procesan directamente en la base de datos principal.

1. Para las solicitudes que deben obtener los últimos resultados, se obliga a enviarlos a la base de datos principal.

2. Solo las solicitudes que pueden leer datos antiguos se envían a la base de datos esclava.

Este método es un poco especulativo: si no se permite retrasar todas las consultas, significa que todas las consultas aparecerán en la base de datos principal. Esto equivale a renunciar a la separación de lectura y escritura, toda la presión de lectura y escritura recae en la biblioteca principal, lo que equivale a renunciar a la escalabilidad.

Esquema de sueño

Una vez completada la actualización de la base de datos maestra, la base de datos esclava duerme por un tiempo antes de leer los datos. La solución específica es similar a ejecutar un select sleep(1) comando.

La suposición de esta solución es que, en la mayoría de los casos, el retraso maestro-esclavo es de 1 segundo y dormir puede tener una alta probabilidad de obtener los datos más recientes.

Este método no es una solución confiable.

1. Si una solicitud de consulta puede obtener el resultado correcto de la base de datos esclava en 0,5 segundos, aún esperará 1 segundo;

2. Si el retraso excede 1 segundo, aún se producirá una lectura caducada.

Juzgar el esquema maestro-esclavo sin demora

Puede verificar si hay un retraso entre el maestro y el esclavo. Si no hay retraso, puede ejecutar la operación de consulta en la base de datos esclava. Hay tres métodos a continuación.

1, juicio second_behind_master;

Antes de cada consulta, primero determine si el valor de second_behind_master es igual a 0. Si no es igual a 0, significa que todavía hay un retraso y la operación de consulta no se realizará hasta que sea igual a 0.

2. El punto de comparación garantiza que no haya retrasos entre el maestro y el esclavo;

Master_Log_File y Read_Master_Log_Pos representan la última posición de la biblioteca maestra leída;
Relay_Master_Log_File y Exec_Master_Log_Pos representan el último punto de ejecución de la biblioteca.

Si Master_Log_File y

Relay_Master_Log_File、Read_Master_Log_Pos

Los dos conjuntos de valores son exactamente iguales a Exec_Master_Log_Pos, lo que significa que el registro recibido se ha sincronizado.

3. Compare el GTID configurado para garantizar que no haya demoras entre el maestro y el esclavo:

Auto_Position=1 , Indica que la relación maestro-esclavo utiliza el protocolo GTID;
Retrieved_Gtid_Set, es una colección de GTID de todos los registros recibidos de la biblioteca;
Executed_Gtid_Set, es una colección de todos los GTID que se han ejecutado desde la biblioteca.

Si los dos conjuntos Retrieved_Gtid_Set y Executed_Gtid_Set son iguales, significa que el registro recibido de la biblioteca se ha sincronizado.

¿Qué es GTID?

El nombre completo de GTID es Global Transaction Identifier, que es el ID de transacción global. Se genera cuando se envía una transacción y es el identificador único de la transacción.

Consta de dos partes, el formato es:

GTID=uuid_servidor:gno

server_uuid se genera automáticamente cuando se inicia una instancia por primera vez y es un valor globalmente único;
gno es un número entero con un valor inicial de 1. Se asigna a esta transacción y se incrementa en 1 cada vez que se confirma una transacción.

En el modo GTID, cada transacción tendrá una correspondencia uno a uno con un GTID. Hay dos formas de generar GTID, que están determinadas por el valor de la variable de sesión gtid_next:

1. Si es gtid_next=automatic, significa usar el valor predeterminado. En este momento, MySQL asignará server_uuid:gno esta transacción.

a. Al grabar binlog, grabe una línea primero

SET @@SESSION.GTID_NEXT=‘server_uuid:gno’;

b. Agregue este GTID al conjunto de GTID de esta instancia.

2. Si gtid_next es un valor GTID especificado, como set gtid_next='current_gtid’ current_gtid, existen dos posibilidades:

a. Si current_gtid ya existe en el conjunto GTID de la instancia, el sistema ignorará directamente la transacción ejecutada a continuación;

b. Si current_gtid no existe en el conjunto GTID de la instancia, este current_gtid se asignará a la transacción que se ejecutará a continuación, es decir, el sistema no necesita generar un nuevo GTID para esta transacción, por lo que gno no es necesario sumar 1.

Un current_gtid solo puede ser utilizado por una transacción. Después de enviar esta transacción, si desea ejecutar la siguiente transacción, debe ejecutar el comando set para configurar gtid_next en otro gtid o automático.

Cada instancia de MySQL mantiene una colección GTID que corresponde a "todas las transacciones ejecutadas por esta instancia".

Ahora que entendemos el concepto de GTID, veamos el uso de la replicación maestro-esclavo basada en GTID.

En el modo GTID, la sintaxis para que la biblioteca esclava C se establezca como biblioteca maestro-esclavo B es la siguiente:

En este momento, marcamos el conjunto GTID de la instancia B como set_b y el conjunto GTID de la instancia C como set_c. A continuación, echemos un vistazo a la lógica de conmutación maestro-esclavo actual.

Ejecutamos el comando en la instancia C start slave y la lógica de tomar binlog es la siguiente:

1. La instancia C especifica la biblioteca maestra B y establece una conexión basada en el protocolo maestro-esclavo.

2. La instancia C envía set_c a la biblioteca principal B.

3. La instancia B calcula la diferencia entre set_b y set_c, es decir, el conjunto de todos los GITD que existen en set_b pero no en set_c, y juzga si B contiene localmente todas las transacciones binlog requeridas por la diferencia.

a. Si no está incluido, significa que B ha eliminado el binlog requerido por la instancia C y devuelve un error directamente;

b. Si se confirma que todas están incluidas, B encuentra la primera transacción que no está en set_c de su propio archivo binlog y la envía a C;

Luego comience desde esta transacción, lea el archivo más tarde, obtenga el binlog en orden y envíelo a C para su ejecución.

Esta lógica contiene una idea de diseño: en la relación maestro-esclavo basada en GTID, el sistema cree que siempre que se establezca la relación maestro-esclavo, debe garantizar que los registros enviados por la biblioteca maestra a la biblioteca esclava estén completos. Por lo tanto, si el registro requerido por la instancia C ya no existe, B se niega a enviar el registro a C.

Esto es diferente del protocolo maestro-esclavo basado en sitio. El protocolo basado en el sitio lo determina la biblioteca esclava. El sitio especificado por la biblioteca esclava será enviado por la biblioteca maestra sin juzgar la integridad del registro.

Echemos un vistazo a cómo se implementa la conmutación maestro-esclavo en un escenario de conmutación maestro-esclavo después de la introducción de GTID.

Como no es necesario encontrar una ubicación, las bibliotecas esclavas C y D solo necesitan ejecutar change master comandos para apuntar a la instancia B respectivamente.

De hecho, estrictamente hablando, no es que el cambio maestro-esclavo no requiera encontrar la ubicación, sino que el trabajo de encontrar la ubicación se completa automáticamente dentro de la instancia B. Pero como este trabajo es automático, resulta muy sencillo para los desarrolladores de sistemas HA.

Después de eso, el sistema será escrito por la nueva biblioteca principal B. El formato de colección GTID en el binlog generado por la biblioteca principal B es: server_uuid_of_B:1-M.

Al configurar la sincronización maestro-esclavo de GTID, si la biblioteca maestra A descubre que el registro GTID que se sincronizará se ha eliminado, A informará un error.

Solución:

La biblioteca esclava C necesita configurar gtid_purged antes de iniciar la sincronización y especificar el punto de inicio de la sincronización GTID. Esta configuración es necesaria cuando se utiliza una copia de seguridad para crear una biblioteca esclava.

Si se realiza una operación separada en la biblioteca esclava, lo que resulta en una falta de GTID en la biblioteca maestra, puede simular una transacción vacía en la biblioteca maestra con el mismo GTID que en la biblioteca esclava C, de modo que la sincronización maestro-esclavo no reportar un error.

Cooperar con semisincronización

MySQL tiene tres modos de sincronización, a saber:

1. Replicación asincrónica: la replicación predeterminada en MySQL es asincrónica. La biblioteca maestra devolverá inmediatamente el resultado al cliente después de ejecutar la transacción enviada por el cliente, y no le importa si la biblioteca esclava la ha recibido y procesado. El problema es que si el registro de la base de datos maestra no se sincroniza con la base de datos esclava a tiempo, y luego la base de datos maestra está inactiva y la conmutación por error se realiza en este momento, los datos en la base de datos maestra seleccionada pueden estar incompletos;

2. Replicación sincrónica completa: cuando la base de datos maestra ejecuta una transacción y espera hasta que todas las bases de datos esclavas también completen la transacción, la base de datos maestra envía la transacción y devuelve datos al cliente. Debido a que es necesario esperar a que todas las bases de datos esclavas se sincronicen con los datos de la base de datos maestra antes de devolver los datos, se puede garantizar la coherencia de los datos maestro-esclavo, pero el rendimiento de la base de datos inevitablemente se verá afectado;

3. Replicación semisincrónica: es un tipo entre sincronización completa y sincronización asincrónica completa. La biblioteca principal necesita esperar a que al menos una biblioteca esclava reciba y escriba en el archivo. La biblioteca principal no necesita esperar a que todos los Relay Log esclavos bibliotecas para devolver ACK a la biblioteca principal. La biblioteca principal recibe el ACK, que indica que la transacción se completó y devuelve los datos al cliente.

La replicación predeterminada en MySQL es asincrónica, por lo que habrá un cierto retraso en la sincronización entre la biblioteca maestra y la biblioteca esclava y, lo que es más importante, la replicación asincrónica también puede causar pérdida de datos. El rendimiento de la replicación sincrónica completa es demasiado pobre, por lo que desde MySQL 5.5 el principio, MySQL admite la replicación semisincrónica semisincrónica en forma de complemento.

Debido a que esta replicación sincrónica no necesita esperar a que todas las bibliotecas esclavas se sincronicen correctamente, la consulta en la biblioteca esclava en este momento enfrentará dos situaciones:

1. Si la consulta recae en la base de datos esclava que respondió al reconocimiento, puede garantizar que se lean los datos más recientes;

2. Si la consulta recae en otras bibliotecas esclavas, es posible que no hayan recibido los registros más recientes, lo que provocará el problema de lectura caducada.

Esperando el plano de ubicación del almacén principal

Antes de comprender el plan de ubicación del almacén principal, primero observe el significado del siguiente comando.

seleccione master_pos_wait(archivo, pos[, tiempo de espera]);

Eche un vistazo a algunos parámetros de este comando:

1. Este comando se ejecuta en la biblioteca esclava;

2. El archivo de parámetros y pos se refieren al nombre del archivo y la ubicación en la biblioteca principal;

3. El tiempo de espera es opcional y se establece en un número entero positivo N para indicar que esta función esperará hasta N segundos.

El retorno normal de este comando es un entero positivo M, que representa el número de transacciones ejecutadas con éxito desde el comienzo de la ejecución del comando hasta la finalización de la aplicación de la posición binlog representada por archivo y pos.

Si la biblioteca esclava ejecuta este comando, significa que la biblioteca esclava ha sincronizado la posición binlog indicada por archivo y pos, y el número de transacciones que se sincronizarán, y devuelve M normalmente, lo que indica que los datos de la biblioteca esclava no se han retrasado en relación con a la biblioteca maestra dentro del tiempo de espera.

Además de las devoluciones normales, también habrá otra información de devolución de ejecución.

1. Si ocurre una excepción durante la sincronización de la biblioteca esclava durante la ejecución, se devolverá NULL;

2. Si la espera excede N segundos, se devolverá -1;

3. Si descubre que esta posición ya se ha ejecutado cuando comienza a ejecutarla por primera vez, se devolverá 0.

Después de comprender la función de este comando, veamos el proceso de ejecución específico del plan de ubicación de la biblioteca principal del siguiente nivel. Si realizamos una actualización de datos en la biblioteca principal y luego consultamos en la biblioteca esclava, el proceso de ejecución es:

1. Una vez completada la ejecución de la transacción de actualización, show master status el archivo y la posición ejecutados por la biblioteca principal actual se pueden obtener inmediatamente;

2. Seleccione una biblioteca esclava para ejecutar la consulta;

3. Ejecutar en la biblioteca esclava select master_pos_wait(File, Position, 1);

4. Si el valor de retorno es un entero positivo> = 0, ejecute la instrucción de consulta en esta biblioteca esclava;

5. En caso contrario, vaya a la base de datos principal para ejecutar la consulta.

Si el retraso de la biblioteca esclava excede el tiempo de espera, todas las solicitudes eventualmente caerán en la biblioteca principal y la presión de consulta aún aumentará hasta la biblioteca principal.

Esperando el esquema GTID

Si el modo GTID está activado, también existe una solución correspondiente para esperar el GTID.

MySQL también proporciona comandos para esperar la sincronización.

seleccione wait_for_executed_gtid_set(gtid_set, 1);

Lógica de ejecución:

1. La biblioteca esclava lleva el gtid de la transacción al ejecutar el comando. Si se devuelve 0, significa que la transacción se ha sincronizado normalmente con la biblioteca esclava y la consulta se puede ejecutar en la biblioteca esclava;

2. La prueba de tiempo de espera devuelve 1.

En el plan anterior, después de ejecutar la transacción, tenemos que ir activamente a la base de datos principal para ejecutarla show master status. A partir MySQL 5.7.6 de la nueva versión, se permite devolver el GTID de esta transacción al cliente después de ejecutar una transacción de actualización, de modo que la solución de esperar el GTID puede reducir una consulta.

El proceso de espera del esquema GTID es

1. Después de ejecutar una transacción en la biblioteca principal, el GTID de la transacción se obtiene directamente del paquete de devolución y se registra como gtid1;

2. Seleccione una biblioteca esclava para ejecutar la declaración de consulta;

3. Ejecutar desde la biblioteca select wait_for_executed_gtid_set(gtid1, 1);

4. Si el valor de retorno es 0, ejecute la consulta en la biblioteca esclava;

5. Si el valor de retorno no es 0, significa que la transacción no se ha sincronizado con la base de datos esclava y debe ejecutar la consulta en la base de datos maestra.

Al igual que la solución de esperar la ubicación de la base de datos principal, si se agota el tiempo de espera, debe iniciar una consulta a la base de datos principal.

6. Resumen

1. La separación de lectura y escritura en MySQL es una arquitectura de uso frecuente. Mediante la separación de lectura y escritura para lograr la capacidad de expansión horizontal, las operaciones de escritura y actualización se realizan en el servidor de origen y los datos se leen desde el servidor La cantidad de servidores puede mejorar en gran medida la capacidad de lectura de la base de datos;

2. La sincronización maestro-esclavo de los datos MySQL se logra principalmente a través de binlog. La biblioteca esclava utiliza el binlog en la biblioteca principal para reproducir y lograr la sincronización maestro-esclavo;

3. Habrá problemas con la sincronización de datos y retrasos en la sincronización oportuna;

4. Posibles motivos del retraso en la sincronización maestro-esclavo:

1. El rendimiento de la base de datos esclava es peor que el de la máquina donde se encuentra la base de datos principal;
2. La presión sobre la biblioteca esclava es alta;
3. Ejecución de asuntos importantes;
4. La conmutación maestro-esclavo o maestro-esclavo ocurre cuando la biblioteca principal es anormal.

5. ¿Cómo se debe manejar el retraso maestro-esclavo?

Ante el retraso maestro-esclavo, existen varias soluciones: