¿Qué tan rápido es la replicación MySQL?

Estoy considerando configurar la replicación de nuestra base de datos mysql para poder tener esclavos locales en cada una de nuestras sucursales, mientras tengo al maestro en la oficina principal para mejorar el rendimiento de la aplicación (significativamente) en nuestras sucursales.

El db en sí no es tan grande (<1gb) pero me pregunto; considerando 200-300 actualizaciones de registros / min topes: ¿qué tan rápido es la replicación? (suponiendo, primero, una conexión dsl genérica de 5mb, más rápida si es necesario, tratando de mantener los costos lo más bajos posible pero el dinero está ahí para más)

¿Se replican tablas enteras en lotes? ¿Se realiza la replicación, a pedido, a medida que se actualiza cada registro en una tabla (de los documentos, creo que estoy viendo que es configurable)?

Notas:

• Estoy pensando en 1 maestro, 2 esclavos (2 sucursales por ahora) configurados como en los documentos aquí, excepto que es una aplicación, no un cliente web
• Cualquier actualización realizada en el maestro necesita replicarse a los otros esclavos en <10 minutos.
• Todo esto supone que puedo hacer que nuestro ORM (DevExpress XPO) esté contento con el concepto de leer del esclavo y escribir al maestro.

La replicación de MySQL ocurre lo más cerca posible en tiempo real, según lo limitado por el disco y la E / S de red. Los esclavos abren un enchufe al maestro, que se mantiene abierto. Cuando se produce una transacción en el maestro, se registra en el binlog y simplemente se reproduce en los esclavos. Si se interrumpe la conexión entre maestro y esclavo, el binlog se reproduce para el esclavo en la siguiente conexión exitosa.

La replicación multimaestro hace lo mismo, pero en ambas direcciones.

Algunos cálculos básicos lo ayudarán a tomar una mejor determinación de sus necesidades de ancho de banda.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Espero que esto ayude.

La replicación en el lado de los esclavos es manejada por dos hilos independientes.

• El proceso del lector de registro, que se conecta al maestro, recibe cada declaración de modificación de datos, la escribe en el registro de retransmisión.
• El proceso de escritura sql, que toma nuevos elementos del registro de retransmisión, confirma las declaraciones en la base de datos de esclavos, luego mueve el puntero de esclavo más allá de esa declaración para indicar la recepción de la consulta.

La latencia de replicación está limitada por IO, en primer lugar, el IO en la base de datos esclava para aplicar las transacciones desde el registro de retransmisión (que puede implicar consultas SQL complejas) y, en segundo lugar, por el IO en el maestro para leer su binlog y transmitirlo a cada esclavo.

La replicación MySQL aumenta la capacidad de consulta de lectura, pero no aumenta el rendimiento de la consulta de escritura, que se activa a la velocidad en que las E / S se pueden vaciar al binlog tanto en el maestro como en el esclavo

La replicación en MySQL es bastante rápida para llevar los datos al esclavo (más rápido de lo que podrá ejecutar UPDATEen el maestro y cambiar a otra ventana para ejecutar un SELECTesclavo, si(y solo si) las conexiones de red están activas y todo funciona bien. Cualquier conexión de clase DSL debería estar bien para el caso general de sus consultas pequeñas regulares, pero las consultas de inserción / actualización grandes pueden demorar un poco en copiarse y volver a sincronizarse en caso de un relleno de replicación (y MySQL es muy propenso a esos, desafortunadamente) tomarán un tiempo (copiando toda su base de datos del maestro nuevamente) Hay trucos para limitar el impacto de la resincronización en su maestro, como poner su MySQL en LVM para que pueda hacer un bloqueo / instantánea muy rápido y sincronizar el contenido de la instantánea con el esclavo, pero finalmente una resincronización va a succionar.