¿La replicación de MySQL se ve afectada por una interconexión de alta latencia?

Tenemos una configuración MySQL maestra y esclava vainilla que reside en diferentes centros de datos, y otra esclava en el mismo centro de datos que el maestro.

El ancho de banda entre el centro de datos es bastante alto (en los puntos de referencia de red que hemos hecho podemos alcanzar los 15 MB / segundo), pero existe latencia, es de alrededor de 28 ms. No es alto de ninguna manera, pero es mucho más alto que la latencia de menos de un segundo en el mismo centro de datos.

Ocasionalmente, experimentamos retrasos graves (2000 segundos y más) con la eliminación de esclavos, mientras que el esclavo local se mantiene actualizado. Al mirar al esclavo remoto retrasado, el subproceso SQL generalmente pasa el tiempo esperando que el subproceso IO actualice el registro de retransmisión. El maestro muestra "esperando por la red" o algo por el estilo al mismo tiempo.

Entonces significa que es una red, pero todavía tenemos ancho de banda libre en el momento en que esto sucede.

Mi pregunta es : ¿puede la latencia entre los centros de datos afectar el rendimiento de la replicación? ¿El subproceso esclavo io simplemente transmite los eventos hasta que el maestro deja de enviarlos, o está agrupando al maestro de alguna manera entre eventos?

La respuesta directa a su pregunta es Sí, pero depende de la versión de MySQL que esté ejecutando. Antes de MySQL 5.5, la replicación funcionaría de la siguiente manera:

• El maestro ejecuta SQL
• Evento SQL de registros maestros en sus registros binarios
• El esclavo lee el evento SQL de los registros binarios maestros
• Slave almacena el evento SQL en sus registros de retransmisión a través de un hilo de E / S
• Slave lee el siguiente evento SQL del registro de retransmisión a través de un subproceso SQL
• Esclavo ejecuta SQL
• Slave reconoce maestro de la ejecución completa del evento SQL

A partir de MySQL 5.5, utilizando la replicación semisincrónica , ahora la replicación funcionaría de la siguiente manera:

• El maestro ejecuta SQL
• Evento SQL de registros maestros en sus registros binarios
• El esclavo lee el evento SQL de los registros binarios maestros
• Slave reconoce maestro del recibo del evento SQL
• Slave almacena el evento SQL en sus registros de retransmisión a través de un hilo de E / S
• Slave lee el siguiente evento SQL del registro de retransmisión a través de un subproceso SQL
• Esclavo ejecuta SQL
• Slave reconoce maestro de la ejecución completa del evento SQL

Este nuevo paradigma permitirá que un esclavo esté más sincronizado con su maestro.

No obstante, la latencia dentro de la red podría obstaculizar la replicación de sincronización de MySQL hasta el punto en que vuelva a la replicación asincrónica de estilo antiguo. Por qué ? Si se produce un tiempo de espera sin que ningún esclavo haya reconocido la transacción, el maestro vuelve a la replicación asincrónica. Cuando al menos un esclavo semisincrónico se pone al día, el maestro vuelve a la replicación semisincrónica.

ACTUALIZACIÓN 2011-08-08 14:22 EDT

La configuración de la replicación semisíncrona de MySQL 5.5 es sencilla

Paso 1) Agregue estas cuatro (4) líneas a /etc/my.cnf

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
#rpl_semi_sync_master_enabled
#rpl_semi_sync_master_timeout=5000
#rpl_semi_sync_slave_enabled

Paso 2) Reinicia MySQL

service mysql restart

Paso 3) Ejecute estos comandos en el cliente MySQL

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave  SONAME 'semisync_slave.so';

Paso 4) Descomente las tres opciones rpm_semi_sync después de la opción plugin-dir

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_slave_enabled

Paso 5) Reinicie MySQL

service mysql restart

Todo listo !!! Ahora solo configure MySQL Replication como de costumbre.

Realmente me gusta cómo Rolando describió la secuencia de operaciones que realiza una replicación. Sin embargo, creo que sería más claro si agregamos otro componente: el cliente.

Con el cliente, la secuencia de operaciones para la replicación asincrónica podría ser la siguiente:

1. El cliente envía al maestro la consulta SQL (por ejemplo, insertar) utilizando transacciones

2. El maestro ejecuta la transacción. En caso de éxito, el registro se almacena en el disco, pero la transacción aún no se ha confirmado.

3. El maestro registra el evento de inserción en el registro binario maestro Si el maestro no puede almacenarlo en el registro binario, la transacción se revierte.

4. El cliente recibe la respuesta del maestro (éxito o reversión).

5. En caso de éxito de la transacción, el subproceso de volcado en el maestro lee el evento del registro binario y lo envía al subproceso de E / S esclavo.

6. El subproceso de E / S esclava recibe el evento y lo escribe al final del archivo de registro de retransmisión.

7. Una vez que el evento entró en el registro de retransmisión, el subproceso SQL esclavo ejecuta
   el evento para aplicar los cambios a la base de datos en el esclavo.

En este escenario, al maestro no le importa el esclavo y el cliente solo sabe que algo está mal en el esclavo ejecutando manualmente el comando "MOSTRAR ESTADO ESCLAVO".

En el caso de una replicación semisíncrona, la secuencia de operaciones podría ser la siguiente:

1. El cliente envía al maestro la consulta SQL (por ejemplo, insertar) utilizando transacciones.

2. El maestro ejecuta la transacción. En caso de éxito, el registro se almacena en el disco, pero la transacción no se confirma.

3. El maestro registra el evento de inserción en el registro binario maestro Si el maestro no pudo almacenarlo en el registro binario, la transacción se revierte y el cliente recibe la respuesta solo en caso de reversión.

4. Debido al éxito de la transacción en el maestro, el subproceso de volcado en el maestro lee el evento del registro binario y lo envía al subproceso de E / S esclavo.

5. El subproceso de E / S esclava recibe el evento y lo escribe al final del archivo de registro de retransmisión.

6. Slave reconoce al maestro de la grabación del evento en el archivo de registro de retransmisión.

7. El maestro confirma la transacción de inserción.

8. El cliente recibe la respuesta del maestro (éxito).

9. Una vez que el evento entró en el registro de retransmisión, el subproceso SQL esclavo ejecuta
   el evento. El maestro y el cliente no saben si la ejecución fue exitosa o no.

La replicación semisíncrona resolvió un caso importante cuando el esclavo o la red murieron y el maestro continuó avanzando. Entonces el maestro muere y desea reiniciar el viejo esclavo como nuevo maestro solo porque solucionó ese nodo.

Entonces comenzaste ese nodo como nuevo maestro, arreglaste el viejo maestro y ahora quieres usarlo como esclavo. Ese nodo todavía tiene los datos, pero si el nuevo esclavo comienza desde la posición donde comenzó el nuevo maestro, habrá registros duplicados.

Si el período de espera es infinito, la posición del registro binario maestro siempre estará sincronizada con la posición del registro del relé esclavo, suponiendo que todas las consultas sobre el esclavo tuvieron éxito. ¿Cuán realista es esta suposición?

Creo que es muy realista. Uno de los casos más comunes del error de consulta esclava es "registro duplicado". ¿Dónde llegó el registro duplicado al esclavo si el maestro no lo tenía? Vino de una posición incorrecta dada al esclavo para comenzar a replicar. La posición de replicación inicial incluía el registro que ya estaba replicado. En caso de replicación semisíncrona, esta situación no ocurrirá.

Jacob Nikom

Calificador : No soy un usuario de MySQL, así que principalmente, esto es solo mi investigación en Internet.

Como estoy seguro de que sabe, la mayor limitación de la replicación MySQL es que es de un solo subproceso. Entonces, mientras el hilo está ocupado enviando datos al esclavo interno, no podrá enviar datos al esclavo remoto. Esto es por aquí .

Por aquí :

Una cosa que debe asegurarse es reducir el tiempo de transacción. Esto permite que su hilo de replicación tenga la oportunidad de ponerse al día con lo que está sucediendo en la base de datos. Desea que sus transacciones sean lo más cortas posible.

Una forma de hacerlo es mediante la consulta de corte; limite las filas modificadas por UPDATE o DELETE mediante el uso de cláusulas WHERE. Si lo mantiene dentro de un bucle, puede recorrer la lista, comenzando y confirmando la transacción cada vez. (ACTUALIZAR / ELIMINAR el primer tercio, el segundo tercio, luego el tercio final cada uno en su propia transacción). Personalmente, le recomendaría encarecidamente que no lo haga porque se abre a la posibilidad de que los datos en la tabla cambien entre transacciones. Pero, es una posibilidad de mejorar este rendimiento si está seguro de que nadie más está jugando con la mesa (y nunca lo hará) .

Otra posibilidad es no replicar esas transacciones de larga duración, sino ejecutarlas en el maestro (que se replica en el esclavo local) y luego ejecutarlas en el esclavo remoto por separado. Esto liberaría el hilo de replicación para que no se atasque en la marca de más de 30 minutos.

Por aquí :

Una posibilidad final sería ajustar el tamaño de sus buffers TCP. El objetivo es reducir la cantidad de comunicaciones que está haciendo entre el maestro y el esclavo. Esto podría ayudar a reducir la latencia.

Personalmente, intentaría esto si todo lo demás falla. Sospecho que el problema se debe más al sistema de replicación de subproceso único que a la latencia de la red. Las redes normalmente expiran mucho antes de los 30 minutos. (¡¿30 minutos?!)

Los marcadores Delicious de JHammerb tienen varios enlaces para la replicación de mysql que también puede consultar.

Espero que eso ayude.