Replicación

1. Utilidad de la replicación

La replicación le puede ayudar para un gran número de problemas con las bases de datos:

1. Replicación maestro-esclavo(s)

a. Configuración

Comenzaremos por el caso más simple: aquel en el que el maestro y el esclavo están recién instalados, es decir, sin ningún dato. Deberá realizar los siguientes pasos:

• Crear un usuario para la replicación en el maestro:

  El esclavo debe poder conectarse con el maestro (IO_THREAD). Es necesario crear una cuenta dedicada en el maestro con el derecho REPLICATION SLAVE. En realidad, muchas veces, es conveniente crear también una cuenta simétrica en el esclavo (útil si el esclavo puede ser ascendido a maestro; en este caso, la replicación tendrá que ejecutarse en el sentido opuesto) y añadir el derecho REPLICATION CLIENT, que permite comandos extensos para el control de la replicación.

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 
'repli_user'@'IP_esclavo' IDENTIFIED BY 'mi_cont';
 

• Configurar el maestro:

  Hay que activar los registros binarios en el maestro y declarar un usuario llamado server_id, que deberá ser único entre todos los servidores asociados por la replicación. Estos cambios se hacen en el archivo my.cnf/my.ini y requieren un reinicio del servidor:

[mysqld] 
log_bin = /var/lib/mysql/mysql-bin 
server_id = 100
 

• Configurar el esclavo:

  Cada esclavo también debe tener un server_id único. Es inútil activar los registros binarios, salvo si el esclavo es él mismo maestro de otros esclavos:

[mysqld] 
server_id = 101
 

• Introducir las coordenadas de replicación:

  Obtendrá las coordenadas de replicación en el maestro con la instrucción siguiente:

mysql> SHOW MASTER STATUS; 
+---------------+----------+--------------+------------------+ 
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
+---------------+----------+--------------+------------------+ 
| mysql-bin.004 | 106      |              |                  | 
+---------------+----------+--------------+------------------+
 

A continuación debemos utilizar estas coordenadas en el esclavo:

mysql> CHANGE MASTER TO MASTER_HOST = 'IP_maestro', 
MASTER_USER = 'repli_user', 
MASTER_PASSWORD...

1. Impedir la replicación de algunas peticiones

Por defecto, todas las escrituras del maestro se escriben en los registros binarios. Estos registros binarios se copian en los esclavos; por lo tanto, los esclavos replican todas las peticiones del maestro. Sin embargo, en algunos casos, podemos no desear replicar algunas peticiones; por ejemplo, si queremos tener un esclavo que no contiene uno de los esquemas del maestro. En este caso, deberemos usar un filtro de replicación.

Se puede filtrar en el maestro empleando las opciones binlog-do-db y binlog-ignore-db, o en los esclavos empleando las opciones replicate-do-db y replicate-ignore-db. Salvo excepciones, se prefieren siempre los filtros sobre los esclavos. En efecto, un filtro en el maestro impedirá la copia de algunas peticiones en los registros binarios. Sin embargo, en el peor de los casos, podemos necesitar recuperar los datos restaurando primero una copia de seguridad y luego aplicando todas las escrituras almacenadas en los registros binarios. Si las peticiones no se han registrado en los registros binarios, las escrituras correspondientes se perderán.

Otro punto importante es que las reglas de filtrado no funcionan de la misma manera, según el formato de los registros binarios.

Con el formato SBR (Statement-Based Replication), solo se verifica la base actual. Por ejemplo, si utilizamos binlog-do-db=db1, el comando INSERT siguiente se replicará del mismo modo:

mysql> USE db1; 
Database changed 
mysql > INSERT INTO db2.t1 values(10);
 

A la inversa, la siguiente petición no se replicará, aunque la tabla t2 pertenezca a la base db1 que replicamos:

mysql> USE db2;   
Database changed   
mysql > INSERT INTO db1.t2 values(10);
 

Con el formato RBR (Row-Based Replication), las órdenes de modificación serán replicadas si los objetos a los que se aplican conciernen a las reglas. Si la tabla modificada no pertenece a la base db1, entonces no será replicada, incluso en el caso de UPDATE múltiples:

mysql> USE db2; 
Database changed 
mysql> UPDATE db1.t1,db2.t2 SET i=1232,j=4310;
 

Así, durante la replicación del UPDATE anterior, solo las modificaciones de la tabla t1 se replicarán con el modo RBR.

Puede ser difícil recordar de forma exacta qué reglas se aplican para...

1. Promoción de un esclavo

La replicación es muy útil para garantizar la disponibilidad de servidores MySQL: si el maestro se vuelve inservible (crash software, problema de hardware, por ejemplo), a menudo es mucho más rápido sustituir el maestro por un esclavo en lugar de tratar de reparar el maestro. Las operaciones necesarias para la promoción no son, en teoría, demasiado complejas, pero deberán efectuarse minuciosamente, en particular para no cometer errores en las coordenadas de replicación. Además, estas operaciones suelen ser necesarias solo en caso de crisis, y es bien sabido que, bajo presión, es mucho más fácil cometer errores. Por eso recomendamos dominar las técnicas explicadas en esta sección y tratar de probarlas, para sentirnos cómodos el día en que las tengamos que usar.

Antes de comenzar la promoción de un esclavo, se aconseja suspender las escrituras en el antiguo maestro. He aquí la lista de los pasos que es preciso realizar:

1. Escalabilidad en lectura

Uno de los usos más comunes de la replicación es permitir ofrecer a una aplicación varios servidores para efectuar las lecturas. En efecto, si todas las grabaciones deben ejecutarse en el maestro, las lecturas pueden, en teoría, efectuarse indistintamente en el maestro o sobre cualquier esclavo, y en la mayoría de las aplicaciones que utilizan MySQL hay más lecturas que escrituras.

Como ya se ha mencionado, la realidad es diferente: la replicación MySQL es asíncrona, no es posible saber si un esclavo tiene los mismos datos que el maestro. Tenga en cuenta que el retraso de replicación dado por la variable Seconds_behind_master en el resultado de SHOW SLAVE STATUS no es un indicador fiable, puesto que la granularidad del contador es el segundo.

Si el maestro ejecuta 1 000 grabaciones por segundo, un retraso de 100 ms (que aparecerá como 0 con Seconds_behind_master) significa un retraso de 100 peticiones.

Por lo tanto, la aplicación deberá contar sin duda con una lógica lo suficientemente específica como para saber qué lecturas se pueden enviar a un esclavo y qué lecturas deberán enviarse al maestro. Tenemos varias estrategias posibles. Por ejemplo, podemos decidir que algunas lecturas necesitan leer la última versión de los datos (que se realizará en el maestro), mientras que otras...

1. Identificadores de transacción

A partir de la versión 5.6, podemos configurar MySQL para que cada transacción tenga un identificador único (GTID - Global Transaction IDentifier). Este identificador es mucho más interesante que las clásicas coordenadas de replicación, ya que es el mismo en todos los servidores involucrados en un sistema de replicación. Hemos visto que la reconstrucción de un esclavo a partir de otro esclavo puede ser difícil por el hecho de que una misma transacción no tiene las mismas coordenadas de replicación en el maestro y en los esclavos (dos esclavos tienen, por otra parte, posiciones diferentes para una misma transacción). Los GTID solucionan este problema.

Para poder utilizar los GTID, es necesario primero activar algunas opciones en cada uno de los servidores:

[mysqld] 
log-bin 
log_slave_updates 
gtid_mode = ON
 

Luego hay que reiniciar cada uno de los servidores. La replicación se configura ahora de forma ligeramente diferente:

mysql> CHANGE MASTER TO MASTER_HOST = 'ip_master', MASTER_USER = 
'mi_usuario', MASTER_PASSWORD = 'mi_cont', MASTER_AUTO_POSITION = 1;
 

Tenga en cuenta que con MySQL 5.6 es obligatorio que reinicie el conjunto de los servidores al mismo tiempo, ya que la replicación no puede funcionar si algunos servidores usan los GTID y otros no. Esta limitación se eliminó con MySQL 5.7. Existe un procedimiento disponible para actualizar la configuración servidor por servidor. Este procedimiento es bastante complejo; lo mejor es consultar la documentación en línea: https://dev.mysql.com/doc/refman/5.7/en/replication-mode-change-online-enable-gtids.html

Otra mejora de MySQL 5.7: no es necesario activar los registros binarios en todos los servidores. Podemos mantener los registros binarios solo en los esclavos susceptibles de ser promovidos a maestros.

La administración de replicación con GTID puede ser desconcertante si no estamos preparados. El principal escollo aparecerá si deseamos ignorar una transacción con SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1. En efecto, este comando está prohibido con GTID; obtendremos un error si intentamos ejecutarlo. En realidad, no es posible ignorar una transacción...