Posts tagged with “binlog”
Los peligros de binlog-do-db en la replicación
A la hora de configurar una replicación, el punto más importante es aquel en el que decidimos que replicar. Y para ello debemos seleccionar que guardar en el log binario. Tenemos muchas opciones, pero hay algunas que debemos evitar:
- binlog-do-db
- binlog-ignore-db
- replicate-do-db
- replicate-ignore-db
Para ver la razón, nada mejor que un ejemplo practico de un sistema master-master.
El servidor A tiene dos bases de datos, VIDA y MUERTE. VIDA será la que se replicará al segundo maestro.
El servidor B solo tiene la base de datos VIDA.
Servidor A:
server-id=101 log-bin=mysql-bin log-slave-updates replicate-same-server-id=0 auto_increment_increment=2 auto_increment_offset=1 binlog-do-db=vida
Servidor B:
server-id=102 log-bin=mysql-bin log-slave-updates replicate-same-server-id=0 auto_increment_increment=2 auto_increment_offset=2 binlog-do-db=vida
Ejecutamos en el servidor A:
node1 [localhost] {msandbox} ((none)) > insert into vida.t values(10); Query OK, 1 row affected (0.00 sec) node1 [localhost] {msandbox} ((none)) > use vida; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A node1 [localhost] {msandbox} (vida) > create table muerte.t (i int); Query OK, 0 rows affected (0.00 sec)
Ya nos hemos cargado la replicación por dos sitios. El valor 10 no se ha insertado en la tabla t de VIDA y por otro lado, el servidor B intentará crear la tabla t en la base de datos MUERTE (que en realidad no tiene).
Last_SQL_Error: Error 'Unknown database 'muerte'' on query. Default database: 'vida'. Query: 'create table muerte.t (i int)'
¿Y cual es la razón de este comportamiento si le hemos indicado que queremos solo la replicación de VIDA? Respuesta corta, binlog-do-db no hace lo que nosotros creemos :) Bien... ¿y la respuesta larga?
Los 4 parámetros para el log binario que hemos visto antes, se aplican si son la base de datos por defecto, esto es, si hemos hecho un USE VIDA. Una vez que convertimos mediante ese comando VIDA en la base de datos por defecto, todos los comandos que ejecutemos se logearán en el log binario.
Por lo tanto, si vemos los comandos SQL ejecutados anteriormente se puede entender la razón por la cual hemos roto la replicación:
- Hemos realizado un insert en la tabla t de VIDA sin que esta sea nuestra base de datos por defecto. MAL! No se logeará, el esclavo no recibirá las actualizaciones.
- Hemos creado una tabla t en MUERTE siendo VIDA nuestra base de datos por defecto. MAL! La sentencia se logeará y enviará al esclavo. Cuando este intente replicarla fallará por no tener dicha base de datos.
Ahora sabemos cual es el problema, hay que saber la solución. Y en esta ocasión tenemos dos:
- Hacer uso de replicate-wild-do-table=VIDA.% Esto logeará todo lo que modifique la base de datos VIDA, sea nuestra base de datos por defecto o no.
- Activar la replicación en base a filas (MySQL 5.1)
Este es un fallo muy común, por lo que os recomiendo revisar las configuraciones de vuestras replicaciones ante posibles fallos de configuración.