¿Qué podemos hacer en MySQL 5.0 replicación a las preocupaciones de ancho de banda dirección?

Question

estoy desarrollando una aplicación se ejecute en el PC cliente (Win) que está configurado con un servidor MySQL 5.1 instancia que actuará como esclavo de sólo lectura al maestro remoto. El maestro remoto tiene docenas de esquemas, pero yo sólo necesito uno por cliente así que abastecen a la replicación-do-db en la configuración my.ini sólo para replicar el esquema que el cliente necesita. Las obras de replicación, pero cuando nuestros clientes consiguen en las regiones del mundo donde el acceso a Internet sólo está disponible de forma inalámbrica 3G, que cobran por el uso de datos, que superan rápidamente sus límites y el plan de datos a tener problemas costosos.

A mi entender, MySQL escribe todas las transacciones para todos los esquemas en un solo archivo binlog que significa que cada cliente tiene que descargar todas las transacciones que se realizan en cada esquema en el maestro, a continuación, una vez descargado, aplicar el filtro de base de datos por replicación-do-db en la configuración my.ini del cliente.

Para minimizar esta ineficiencia he empleado en el = 1 entorno slave_compressed_protocol , que parece reducir los datos transmitidos en un 50%, pero todavía causa de nuestros clientes de forma rápida excedan su límite de datos acumular la factura 3G .

No me puedo imaginar que soy el único que enfrenta este, así que estoy seguro de que obtendrá una tonelada de respuestas sobre cómo lograr esto mediante la creación x = y. Sin embargo, no puedo encontrar ninguna documentación de configuración tal, ni un enfoque recomienda tomar.

Hasta ahora, aquí está mi pensamiento a una posible solución, por favor proporcionar información o rutas alternas:

---

1. preparar un esclavo "proxy" para cada esquema (en otra carpeta, o de la misma caja con una instancia de MySQL / puerto diferente)
2. Configurar el esclavo proxy para replicarse-do-db sólo la base de datos que los clientes desean replicar.
3. instancia de MySQL Configurar el cliente de como esclavos a los esclavos sustitutivo adecuado.

Este debe resultado en el cliente sólo tirando de los datos binlog para su esquema. La desventaja (por lo que puedo decir) es que aumenta drásticamente la complejidad de nuestra configuración, por lo que es probable que más frágil.

Los pensamientos? Será este enfoque de trabajo aún?

Tenga en cuenta, que se ejecuta el servidor MySQL 5.0 en RedHat, pero que podría ascender a 5,5 si se produce una solución.

Answer 1

Sugerencia # 1: Uso Masters de distribución

Un Maestro de distribución es un esclavo MySQL con log-bin permitido, log-slave-updates habilitados y sólo contiene tablas con el BLACKHOLE motor de almacenamiento . Se puede aplicar la réplica-do-db al Maestro de distribución y crear registros binarios en el Master de distribución que contiene sólo el esquema (s) que desea DB binlogged. De esta manera se reduce el tamaño de binlogs salientes del Maestro de distribución.

Se puede configurar un maestro de distribución de la siguiente manera:

1. mysqldump su base de datos (s) utilizando la opción --no-datos para generar un volcado esquema solamente.
2. cargar el volcado esquema sólo al Maestro de distribución.
3. Convertir cada mesa en el Master de distribución al motor de almacenamiento InnoDB.
4. Configuración de la replicación con el Maestro de distribución de un maestro con datos reales.
5. Opción (s) réplica-do-db a /etc/my.cnf del Maestro Distribución Agregar.

Para los pasos 2 y 3 también se puede editar el esquema de sólo volcar y reemplazar ENGINE = MyISAM e InnoDB = MOTOR Con el motor = BLACKHOLE y luego cargar ese editado esquema de sólo volcar en el Maestro de distribución.

En el paso 3 solo, si quieres guión la conversión de todas las tablas MyISAM y InnoDB a BLACKHOLE en el Maestro de distribución, ejecute la siguiente consulta y la salida 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 añadida a secuencias de comandos de la conversión de la tabla para el motor de almacenamiento BLACKHOLE es que tablas del motor de almacenamiento MEMORY se convierten así. Mientras que el cuadro motor de almacenamiento de memoria no ocupa espacio en disco para el almacenamiento de datos, que se ocupará de la memoria. La conversión de las tablas de memoria para BLACKHOLE mantendrá la memoria en el Master de distribución ordenada.

Mientras usted no envía ninguna DDL en el Maestro de distribución, puede transmitir cualquier DML (INSERT, UPDATE, DELETE) así lo desea antes de dejar que los clientes se replican sólo la información DB que quieren.

Ya

escribí un post en otro sitio StackExchange la que se explica el uso de un Maestro distribución .

Sugerencia # 2: El uso más pequeño binario Registros y Registros de relé

Si define max_binlog_size a algo ridículamente pequeño, entonces binlogs pueden ser recolectados y enviados a cabo en trozos más pequeños. También hay una opción separada para establecer el tamaño de los troncos de relé, max_relay_log_size . Si max_relay_log_size = 0, por defecto lo que sea max_binlog_size está ajustado a.

Sugerencia # 3: Uso semisincrónicas replicación (MySQL 5.5 solamente)

Configuración de base de datos y la distribución múltiple principales Masters como MySQL 5.5. Habilitar semisincrónicas replicación de manera que la base de datos principal puede enviar rápidamente binlogs al Maestro de distribución. Si todos los esclavos son Maestros de distribución, puede que no necesite semisincrónicas replicación o MySQL 5.5. Si alguno de los esclavos, que no sean Maestros de distribución, tienen datos reales para la presentación de informes, alta disponibilidad, en espera pasiva o como copia de seguridad, y luego ir con MySQL 5.5 junto con semisincrónicas replicación.

Sugerencia # 4: Uso Declaración basada en binario registro no basados ??en filas

Si una instrucción SQL actualiza varias filas en una tabla, Declaración-Based Registro binario (SBBL) almacena sólo el SQLdeclaración. La misma instrucción SQL utilizando Fila-Based Registro binario (RBBL) lo hará el registro real de cambio de fila para cada fila. Esto hace que sea obvio que la transmisión de las instrucciones SQL ahorrará espacio en los registros binarios haciendo SBBL sobre RBBL.

Otro problema es el uso de RBBL en conjunción con la réplica-do-db donde nombre de la tabla tiene la base de datos antepone . Esto no puede ser bueno para un esclavo, especialmente para un maestro de distribución. Por lo tanto, asegúrese de que todos los LMD no tiene una base de datos y un período frente a cualquier nombre de tabla.

Answer 2

El max_binlog_size debería ser irrelevante -. Binlog de datos se transmite a cabo continuamente

Precaución sobre un "Maestro de Distribución" - se trata de un "punto único de fallo". Es decir, si muere, todo el esclavo (s) más allá de que no va a recibir los datos, y reconstruir el relé tendrá trabajo.

SBR vs RBR - que depende de la consulta. O bien puede ser mejor o peor que el otro.

Ponga el Masters de distribución en la misma máquina que el maestro real, o en una máquina de "cerca" del Maestro. Utilizar puertos separados para mantener las instancias separadas.