Un resumen de las topologías y principios comunes de la replicación maestro-esclavo de MySQL y cómo mejorar la eficiencia de la replicación maestro-esclavo

2. Subproceso de E/S esclavo, en el lado del servidor esclavo

3. Subproceso de volcado de Binlog (también llamado subproceso IO), en. el lado del servidor maestro

Nota: si un servidor maestro está emparejado con dos servidores esclavos, habrá dos subprocesos de volcado de Binlog en el servidor maestro y dos subprocesos en cada servidor esclavo.

Para implementar la replicación MySQL, la función de registro binlog (mysql-bin.xxxxxx) primero debe activarse en el servidor maestro; de lo contrario, no se puede lograr la replicación maestro-esclavo de MySQL. Porque todo el proceso de replicación maestro-esclavo de MySQL es en realidad: la estación esclava obtiene el registro binlog de la estación maestra y luego realiza varias operaciones SQL en su propio texto de acuerdo con el orden exacto del registro. Para obtener información detallada sobre cómo habilitar la función de registro binlog de mysql, busque en línea usted mismo.

3.4. Proceso de replicación maestro-esclavo

El proceso de interacción básico de la replicación maestro-esclavo de MySQL es el siguiente:

1. El lado está conectado al lado maestro y solicita ver el contenido del registro copiado comenzando desde la posición del nodo pos especificada del archivo de registro binlog especificado (o desde el comienzo del registro).

2. Después de recibir la solicitud del subproceso IO esclavo, el maestro notificará al subproceso IO responsable del proceso de replicación para que lea la información de registro después del nodo de ubicación especificado del registro binlog especificado de acuerdo con la solicitud. del subproceso IO esclavo y luego lo devuelve al subproceso IO del lado esclavo. Además de la información contenida en el registro binlog, la información devuelta también incluye el nombre del archivo binlog del maestro y la ubicación del nodo pos en el registro binlog.

3. Después de recibir la información devuelta por IO en el lado maestro, el subproceso IO en el lado esclavo escribirá el contenido del registro binlog recibido en el archivo de registro de retransmisión en el lado esclavo (mysql-relay-bin). . xxxxxx) y registre el nombre del archivo binlog en el lado de la estación principal y la ubicación del nodo pos. El nombre y la ubicación del archivo binlog maestro leído se registrarán en el archivo de información maestra (almacenado en el esclavo), de modo que la próxima vez que se lea, se le pueda decir claramente al maestro: "¿Qué nodo binlog necesito?" ¿Desde qué archivo binlog en la ubicación comienza a leerse? Envíeme el contenido del registro a partir de este nodo".

4. Una vez que el hilo SQL en el lado esclavo detecta el nuevo contenido del archivo de registro de retransmisión, lo analizará inmediatamente. Luego restaure las declaraciones SQL realmente ejecutadas por el maestro y ejecute estas declaraciones SQL en orden SF por sí sola. De esta manera, el maestro y el esclavo realmente ejecutan la misma declaración SQL, por lo que los datos del maestro y el esclavo son exactamente los mismos.

El proceso de interacción de replicación maestro-esclavo de MySQL anterior es torpe y problemático de entender, por lo que simplifiqué el proceso de interacción. Los detalles son los siguientes:

1. Después de ejecutar sql, la estación principal registra el archivo de registro binario (bin-log).

2. El esclavo se conecta al maestro y obtiene el registro bin del maestro, lo almacena en el registro de retransmisión local y luego ejecuta la instrucción SQL desde la última posición recordada, una vez que se encuentra un error. , detenga la sincronización.

Se puede ver en el principio de replicación de MySQL anterior:

Las bases de datos entre el maestro y el esclavo no están sincronizadas en tiempo real. Incluso si la conexión de red es normal, el maestro-. Los datos del esclavo serán momentáneamente inconsistentes.

Si la red entre la estación maestra y la estación esclava se desconecta, la estación esclava se sincronizará en lotes después de que la red vuelva a la normalidad.

Si modifica los datos en el dispositivo esclavo, si el dispositivo esclavo está ejecutando el registro bin del dispositivo maestro en ese momento, se producirá un error y la sincronización se detendrá, lo cual es una operación muy peligrosa. . Por tanto, en general, debemos tener mucho cuidado a la hora de modificar datos en dispositivos esclavos.

Una configuración derivada es una configuración maestro-esclavo mutua de doble maestro, que puede ejecutarse normalmente siempre que las modificaciones de ambas partes no entren en conflicto.

Si se necesitan varias estaciones maestras, se puede utilizar una configuración en anillo, de modo que las modificaciones en cualquier nodo se puedan sincronizar con todos los nodos.

3.5. El proceso general es:

La replicación de MySQL se basa en que el servidor maestro rastrea todos los cambios en la base de datos (actualizaciones, eliminaciones, etc.) en el registro binario. Cada servidor esclavo recibe actualizaciones guardadas del servidor maestro, y el servidor maestro registra estas actualizaciones en su registro binario para que los servidores esclavos puedan realizar las mismas actualizaciones en sus copias de los datos.

Una forma de copiar datos de un servidor maestro a un servidor esclavo es utilizar la instrucción LOAD DATA FROM MASTER. Tenga en cuenta que LOAD DATA FROM MASTER actualmente solo funciona en servidores maestros que usan el motor de almacenamiento MyISAM para todas las tablas. Además, la declaración adquirirá un bloqueo de lectura global.

MySQL utiliza tres subprocesos para realizar funciones de replicación, uno en el servidor maestro y dos en el servidor esclavo. Cuando se emite START SLAVE, el servidor esclavo crea un subproceso de E/S para conectarse al servidor maestro y permite que el servidor maestro envíe declaraciones registradas en su registro binario.

El servidor maestro creará un hilo (hilo de E/S) para enviar el contenido del registro binario al servidor esclavo. Este hilo se puede identificar como un hilo de Binlog Dump en la salida SHOW PROCESSLIST del servidor maestro.

El subproceso de E/S del servidor esclavo lee el contenido enviado por el subproceso Binlog Dump del servidor maestro y copia los datos al archivo local en el directorio de datos del servidor esclavo, es decir, el registro de retransmisión.

Se crea un tercer hilo (hilo SQL) desde el servidor para leer el registro de retransmisión y realizar las actualizaciones contenidas en el registro.

Un servidor maestro con múltiples esclavos crea un subproceso para cada esclavo actualmente conectado; cada esclavo tiene sus propios subprocesos de E/S y SQL.

Cuatro: tipos de replicación admitidos por MySQL y sus ventajas y desventajas

El archivo de registro bin-log tiene dos formatos, uno es replicación basada en declaraciones y el otro está basado en filas. Replicación: Replicación basada en declaraciones: las declaraciones SQL ejecutadas en el servidor maestro se copian en el servidor esclavo. MySQL utiliza la replicación basada en declaraciones de forma predeterminada, que es más eficiente. Cuando se descubre que la replicación exacta no es posible, se selecciona automáticamente la replicación basada en filas.

(2): Replicación basada en filas: Replica cambios en lugar de ejecutar comandos en el servidor esclavo. Compatible desde mysql 5.0

(3): Replicación de tipo mixto: la replicación basada en declaraciones se usa de forma predeterminada y la replicación basada en filas se usa una vez que se descubre que la replicación basada en declaraciones no se puede replicar con precisión.

4.1 Análisis de ventajas y desventajas basado en declaraciones

Ventajas

El registro bin-log contiene eventos que describen las operaciones de la base de datos, pero estos eventos solo incluyen situaciones en las que el La base de datos ha sido modificada, como insertar, actualizar, crear, eliminar, etc. Por otro lado, las operaciones de selección, desc y similares no se registran, se registran como declaraciones y, por lo tanto, ocupan menos espacio de almacenamiento que las basadas en filas.

Dado que el archivo de registro bin-log registra todas las declaraciones que cambian la base de datos, el archivo se puede utilizar como base para futuras auditorías de la base de datos.

Desventajas

Inseguro , No todas las declaraciones que cambian datos se registran y replican. Cualquier comportamiento no determinista es difícil de registrar y replicar.

Por ejemplo, para una declaración de eliminación o actualización que usa límite pero no ordena por, es una declaración no determinista y no se registrará.

Para una declaración de actualización sin una condición de índice, se deben bloquear más datos, lo que reduce el rendimiento de la base de datos.

La instrucción insert?select también necesita bloquear una gran cantidad de datos, lo que reducirá el rendimiento de la base de datos.

Para obtener información más detallada, consulte la documentación oficial: Análisis de pros y contras basado en declaraciones

4.2 Análisis de pros y contras basado en filas

Ventajas

Todos los cambios se copiarán, esta es la forma más segura de copiar una declaración. Replicación basada en filas

Para actualizaciones, inserciones, selecciones y otras declaraciones, se bloquean menos filas

Este enfoque es común a la mayoría de los sistemas de bases de datos, por lo que las personas que conocen otros sistemas es fácil de cambiar a mysql

Desventajas

Inconveniente, no podemos ver qué declaraciones se ejecutaron a través del archivo de registro bin-log. No podemos ver qué declaraciones se ejecutaron o qué declaraciones se recibieron del servidor. Solo podemos ver qué datos han cambiado.

Dado que se registran los datos, el archivo de registro bin-log es mucho más pequeño que el anterior. Los archivos de registro basados ​​en declaraciones ocupan más espacio de almacenamiento.

Para operaciones con mayor volumen de datos, lleva más tiempo

Para obtener más detalles, consulte la documentación oficial: Ventajas y desventajas basadas en filas

El valor predeterminado El formato del archivo de registro bin-log se basa en declaraciones. Si desea utilizar la opción -binlog-format para cambiar el formato al abrir el servicio, el comando específico es el siguiente

mysqld_safe _user=msyql _binlog-format=format &

4. Análisis del proceso del servidor principal

4.1 Hilo de volcado de binlog del hilo del servidor principal

El hilo de volcado de Binlog es creado por el servidor principal cuando hay una conexión con el servidor esclavo. Su proceso de trabajo general continúa. las siguientes etapas:

Primero bloquee el archivo de registro bin-log, luego realice la operación de lectura y actualización, libere el bloqueo una vez completada la lectura y luego envíe el registro de lectura al servidor esclavo. Los registros de lectura se envían al servidor esclavo.

Podemos usar el siguiente comando para ver la información de este hilo

mysql> SHOW PROCESSLIST\G

Tome mi sistema como ejemplo, porque mi sistema Hay un servidor maestro y dos servidores esclavos, por lo que se enumerará la información de los dos subprocesos de volcado de Binlog

**** ******************* ** ****** 1. fila ****************************

Identificación: 2

Usuario: repuser

Host: 192.168.144.131:41544

db.NULL

Comando: Binlog Dump

Hora: 54

Estado: La estación maestra ha enviado todos los binlogs a la estación esclava; esperando actualizar el binlog

Información: NULL

***** ************************* 2. OK****************** ********** **

Id: 3

Usuario: repuser

Host: 192.168.144.132:40888

db: NULL

Comando: Binlog Dump

Hora: 31

Estado: La estación maestra ha enviado todos los binlogs a la estación esclava en espera; actualizar el binlog

Información: NULL

El campo de estado en los campos anteriores tendrá el siguiente estado:

1. Enviar el evento binlog al servidor esclavo

Indica que el hilo de volcado de Binlog ha terminado de leer el binlog y enviarlo al esclavo

Slave_IO_Running: No

Slave_SQL_Running: No

Esto significa que ambos hilos han dejado de ejecutarse. Si usa el comando SHOW PROCESSLIST\G nuevamente en este momento, no se mostrarán resultados

5.1 Subproceso de E/S esclavo

Subproceso de E/S esclavo para conectarse al Binlog. volcado del hilo del servidor principal y le pide que envíe las operaciones de actualización registradas en el registro de binlog, luego copia los datos enviados por el hilo de volcado de Binlog al hilo de volcado de Binlog y los envía al servidor principal. Subproceso, copia los datos enviados por el subproceso de volcado de Binlog al registro de retransmisión de archivos en el servidor esclavo (es decir, localmente).

Por supuesto, para ver si el hilo se está ejecutando, además del método anterior, también puedes usar

mysql> SHOW SLAVE LIKE 'Slave_running'

; p>Entonces, si aparecen los siguientes resultados, significa que el hilo se está ejecutando

+-----------------+------- ------ ------+

| Nombre_variable |

+----------------- +----- ---------------+

| Slave_running |

+-------- ------- --+-----------------+

En el resultado 1 anterior, podemos ver que 1.row es la información del hilo de E/S esclavo, su estado es: Estado: Esperando que el maestro envíe el evento indica que está esperando que el servidor maestro envíe contenido.

Por supuesto, el estado no es el único valor, hay otros valores, todos los valores del estado se enumeran a continuación

1 Espere a que se actualice la estación maestra

El estado inicial. antes de conectarse a la estación principal

2. Conéctese a la estación principal

El hilo se está conectando a la estación principal Por supuesto, si está conectado a la estación principal, lo hará. conectarse a la estación principal. Conéctese al sitio principal

Si la condición de la red es buena, este estado casi nunca ocurrirá

3 Verifique la versión del sitio principal

Establezca una conexión con. el sitio principal en el hilo Más adelante, este estado aparecerá brevemente.

4. Registre la máquina esclava en la máquina maestra

Siempre que se conecte una nueva máquina esclava, registre la máquina esclava en la máquina maestra

5. volcado de binlog