¿Qué podemos hacer en MySQL 5.0 Replication para abordar problemas de ancho de banda?

Estoy desarrollando una aplicación para ejecutar en la PC del cliente (Win) que está configurada con una instancia del servidor MySQL 5.1 que actuará como esclavo de solo lectura para el maestro remoto. El maestro remoto tiene docenas de esquemas, pero solo necesito uno por cliente, por lo que proporciono la configuración replication-do-db en my.ini para replicar solo el esquema que el cliente necesita. La replicación funciona, pero cuando nuestros clientes ingresan a regiones del mundo donde el acceso a Internet solo está disponible a través de la conexión inalámbrica 3G, que cobra por el uso de datos, rápidamente exceden los límites de su plan de datos y se enfrentan a problemas costosos.

Según tengo entendido, MySQL escribe todas las transacciones para todos los esquemas en un solo archivo binlog, lo que significa que cada cliente tiene que descargar todas las transacciones que se realizan en cada esquema en el maestro, luego, una vez descargado, aplique el filtro de base de datos por replicación. Configuración de do-db en el archivo my.ini del cliente.

Para minimizar esta ineficiencia, he empleado la configuración slave_compressed_protocol = 1 , que parece reducir los datos transmitidos en un 50%, pero aún así hace que nuestros clientes superen rápidamente su límite de datos acumulando la factura 3G.

No puedo imaginar que soy el único que enfrenta esto, así que estoy seguro de que obtendré un montón de respuestas sobre cómo lograr esto estableciendo x = y. Sin embargo, no puedo encontrar ninguna documentación de tal configuración, ni un enfoque recomendado para tomar.

Hasta ahora, he pensado en una posible solución, por favor envíe sus comentarios o rutas alternativas:

1. Configure un esclavo "proxy" para cada esquema (en un cuadro diferente, o el mismo cuadro con una instancia / puerto MySQL diferente)
2. Configure el esclavo proxy para replicar-do-db solo la base de datos que los clientes desean replicar.
3. Configure la instancia de MySQL del cliente como esclavos del esclavo proxy apropiado.

Esto debería dar como resultado que el cliente solo extraiga los datos de binlog para su esquema. La desventaja (por lo que puedo decir) es que aumenta dramáticamente la complejidad de nuestra configuración, probablemente haciéndola más frágil.

Pensamientos? ¿Funcionará este enfoque?

Tenga en cuenta que estamos ejecutando el servidor MySQL 5.0 en RedHat, pero podríamos actualizar a 5.5 si produce una solución.

SUGERENCIA # 1: Usar maestros de distribución

Un maestro de distribución es un esclavo mysql con log-bin habilitado, log-slave-updates habilitado y contiene solo tablas con el motor de almacenamiento BLACKHOLE . Puede aplicar replicate-do-db al maestro de distribución y crear registros binarios en el maestro de distribución que contenga solo los esquemas de base de datos que desea registrar en bin. De esta forma, reduce el tamaño de los binlogs salientes del maestro de distribución.

Puede configurar un maestro de distribución de la siguiente manera:

1. mysqldump sus bases de datos utilizando la opción --no-data para generar un volcado de solo esquema.
2. Cargue el volcado de solo esquema en el maestro de distribución.
3. Convierta cada tabla en el maestro de distribución al motor de almacenamiento BLACKHOLE.
4. Configure la replicación en el maestro de distribución desde un maestro con datos reales.
5. Agregue las opciones replicate-do-db a /etc/my.cnf del Distribution Master.

Para los pasos 2 y 3, también puede editar el volcado de solo esquema y reemplazar ENGINE = MyISAM y ENGINE = InnoDB con ENGINE = BLACKHOLE y luego cargar ese volcado de solo esquema editado en el Maestro de distribución.

Solo en el paso 3, si desea ejecutar la conversión de todas las tablas MyISAM e InnoDB a BLACKHOLE en el Maestro de distribución, ejecute la siguiente consulta y envíela a un archivo de texto:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Una ventaja adicional de crear scripts para la conversión de la tabla al motor de almacenamiento BLACKHOLE es ese motor de almacenamiento MEMORY tablas del se convierten. Si bien la tabla del motor de almacenamiento MEMORY no ocupa espacio en disco para el almacenamiento de datos, ocupará memoria. La conversión de tablas de MEMORIA a BLACKHOLE mantendrá la memoria en el maestro de distribución ordenada.

Siempre y cuando no envíe ningún DDL al maestro de distribución, puede transmitir cualquier DML (INSERTAR, ACTUALIZAR, BORRAR) que desee antes de permitir que los clientes repliquen solo la información de base de datos que desean.

Ya escribí una publicación en otro sitio de StackExchange que trata sobre el uso de un maestro de distribución .

SUGERENCIA # 2: Utilice registros binarios más pequeños y registros de retransmisión

Si configura max_binlog_size en algo ridículamente pequeño, los binlogs se pueden recopilar y enviar en trozos más pequeños. También hay una opción separada para establecer el tamaño de los registros de retransmisión, max_relay_log_size . Si max_relay_log_size = 0, el valor predeterminado será el valor máximo de max_binlog_size.

SUGERENCIA # 3: Usar replicación semisincrónica (solo MySQL 5.5)

Configure su base de datos principal y múltiples maestros de distribución como MySQL 5.5. Habilite la replicación semisincrónica para que la base de datos principal pueda enviar rápidamente binlogs al maestro de distribución. Si TODOS sus esclavos son maestros de distribución, es posible que no necesite la replicación semisincrónica o MySQL 5.5. Si alguno de los esclavos, aparte de los maestros de distribución, tiene datos reales para fines de informes, alta disponibilidad, espera pasiva o copia de seguridad, vaya con MySQL 5.5 junto con la replicación semisincrónica.

SUGERENCIA # 4: Use el registro binario basado en declaraciones NO basado en filas

Si una instrucción SQL actualiza varias filas en una tabla, el registro binario basado en instrucciones (SBBL) almacena solo la instrucción SQL. La misma instrucción SQL que usa el registro binario basado en filas (RBBL) registrará el cambio de fila para cada fila. Esto hace obvio que la transmisión de sentencias SQL ahorrará espacio en los registros binarios que realizan SBBL sobre RBBL.

Otro problema es usar RBBL junto con replicate-do-db donde el nombre de la tabla tiene la base de datos antepuesta . Esto no puede ser bueno para un esclavo, especialmente para un maestro de distribución. Por lo tanto, asegúrese de que todos los DML no tengan una base de datos y un punto delante de los nombres de las tablas.

Max_binlog_size debe ser irrelevante: los datos de binlog se transmiten continuamente.

Precaución sobre un "Maestro de distribución": es un "punto único de falla". Es decir, si muere, todos los esclavos más allá no recibirán datos, y la reconstrucción del relé tomará trabajo.

SBR vs RBR: depende de la consulta. Cualquiera puede ser mejor o peor que el otro.

Coloque los maestros de distribución en la misma máquina que el maestro real, o en una máquina "cerca" del maestro. Use puertos separados para mantener las instancias separadas.