Detalles de MySQL Master-Slave

MySQL master-slave tiene las siguientes características:

• Replicación asíncrona: en cuanto se ejecuta una query de modificación en el master, ésta se lanza al momento para ejecutárse en los slaves.
• La replicación puede basarse en:
  • Statement Based Replication (SBR): ejecuta en los slaves, la sentencia SQL ejecutada en el master.
  • Row Based Replication (RBR): replica en los slaves, únicamente las filas que han cambiado en el master (replica datos en lugar de sentencias que han de ejecutarse).
  • Mixed Based Replication (MBR): una mezcla de las dos anteriores.
  • Se puede verificar el tipo de replicación utilizado, ejecutando en cualquier server:

mysql> show global variables like ‘binlog_format’;
+—————+———–+
| Variable_name | Value |
+—————+———–+
| binlog_format | STATEMENT |
+—————+———–+
1 row in set (0.00 sec)

• Binary log: el master guarda todos los datos a replicar en unos ficheros de log, que contendrán las queries a replicar en el caso de estar usando SBR. Por esta razón, se podrá símplemente leer dichos ficheros de log para revisar las queries que se han o se van a replicar. El binary log, contendrá pues, todos los eventos que modifican la estructura o el contenido de la base de datos (las consultas tipo SELECT no quedarán registradas, puesto que no modifican la base de datos).

[root@master]# tail /var/lib/mysql/mysql-bin.000165

• Relay bin log: los slaves hacen un pull para recibir cada fichero binary log del master, y una vez recibido, ejecutan las sentencias (si se usa SBR) que encuentra en el fichero de log, con tal de realizar las mismas modificaciones en los datos que ha realizado el master, al ejecutar las mismas consultas. Los slaves almacenan una copia local del fichero binary log que traen del master, en su directorio dbpath local:

[root@slave01]# tail /var/lib/mysql/mysqld-relay-bin.000148

• Replication threads: la replicación Master-Slave Mysql, usa 3 threads.
  • Binlog Dump thread: En el master, se podrá ver un comando «Binlog Dump» por cada slave, al ejecutar un «show processlist». Este thread sirve para mantener abierta una comunicación con cada slave, para ir enviando los datos del «binary log». El «show processlist» además, mostrará el estado de la replicación del binlog para cada slave.

  mysql> show processlist;

  • Slave i/o thread: thread que se abre en los slaves cuando se inician, y que conecta contra el master, usado para que el slave le pida al master las actualizaciones realizadas en los ficheros «binary log». Este thread, lee los updates que el thread «binlog dump» envía y los guarda en los ficheros «relay bin log» locales. Se puede ver el estado de éste thread mirando el estado del slave. El thread estará funcionando si se obtiene «Slave_IO_running:Yes». En caso contrario, habrá un error en la replicación.
  • Slave SQL thread: thread abierto en los slaves, que lee del fichero «relay bin log» local y va ejecutando las queries, para mantenerse actualizado respecto al master. Se puede consultar el estado de los threads «slave i/o» y «slave SQL» mediante:

mysql> show slave status\G;

Además de las características descritas, hay ciertos puntos a tener en cuenta. A continuación una muestra de ellos:

• Flush: algunas sentencias con flush, no se replican puesto que pueden causar problemas. Así pues, no es extraño que tras modificar permisos en el master y realizar un «flush privileges», éstos permisos no se vean reflejados en los slaves, hasta no ejecutar manualmente un «flush privileges» en cada uno de los slaves. Ídem con «flush tables». Más info aquí.
• Repair table: será necesario parar la replicación antes de ejecutar un repair table en el master. Una vez ejecutada la reparación de la/s tabla/s, se deberán comparar las tablas afectadas para ver si hay discrepancias entre master y slave, y corregírlas manualmente en caso de haberlas. Más info aquí.
• max_allowed_packet: esta variable define el límite para un mensaje entre el master y el slave. Por defecto está a 1MB. Si este valor es demasiado pequeño en el master y/o en el slave, ocurrirá un error que parará el «Slave i/o thread». Más info aquí.
• Shutdowns en el master: no hay problema en reiniciar el servidor master. Los slaves intentarán reconectar con el master cada 60 segundos (por defecto). Sin embargo, si el master se ha apagado por un crash, posiblemente ocurra que el binlog del master haya acabado en una posición menor que la última posición leída por el slave, y que por tanto no pueda replicar tras levantar el master. Se recomienda usar el parámetro «sync_binlog=1» en el my.cnf del master, para minimizar este tipo de problemas. Más info aquí.
• Shutdowns en el slave: es seguro apagar o reiniciar el slave, puesto que éste mantiene la última posición leída del binlog. Se podrá apagar primero ejecutando un «slave stop» y posteriormente parando el servicio mysqld. Más info aquí.

Finalmente, algunos enlaces útiles:

• Forzar a resincronizar una pequeña tabla. En este post explican un método que consiste en guardar la información de una tabla en un fichero temporal, eliminar la tabla, crearla vacía y volcar el contenido guardado en la tabla recién creada. De esta manera se fuerza a que el master incluya estas sentencias en su binlog, aunque con un downtime para los datos de dicha tabla. También existe la posibilidad de renombrar la tabla. Aquí cómo hacerlo.
• Descubrir diferencias entre el master y el slave con Maatkit. Aquí la info.
• Pasos para resincronizar toda la base de datos, con interrupción del servicio. Aquí la info de StackOverflow.
• Backups veloces con LVM Snapshots. Info.

Fuentes:

• http://dev.mysql.com/doc/refman/5.1/en/replication.html
• http://dev.mysql.com/doc/refman/5.1/en/replication-features.html

Foto por JD Hancock