La configuración y creación de réplicas de las bases de datos es un proceso muy importante para poder disponer de escalabilidad en nuestro cluster de bases de datos, pues nos permite escalar de forma horizontal (número de instancias) y no solo vertical (más RAM, más CPU).

Con la nueva versión de MySQL, la 8, que ya lleva un tiempo con nosotros, se cambió la nomenclatura que se le daba a las instancias maestra y esclava. Ahora se llaman «Fuente» (Source) y «Replica» (Replica). Aquí se usarán ambas nomenclaturas para ayudar aquellas personas que se estén actualizando desde MySQL 5.7.

1. Configurando la instancia maestra/fuente

En primer lugar tenemos que configurar la instancia que hará de instancia maestra, y desde ella se replicarán los datos hacia las instancias replicadas.

En el fichero de configuración de MySQL (normalmente estará en /etc/mysql/my.cnf) tendremos que indicar las siguientes líneas:

server_id=1
enforce-gtid-consistency = 1
log_bin                         = /var/log/mysql/mysql-bin
expire_logs_days                = 7
sync_binlog                     = 1
gtid-mode = ON

Esta configuración de MySQL está diseñada para habilitar y gestionar la replicación basada en GTID (Global Transaction Identifiers). Vamos a desglosar cada uno de los parámetros:

1. server_id=1:
   • Este parámetro asigna un identificador único a la instancia del servidor MySQL. En un entorno de replicación, cada servidor debe tener un server_id único para distinguirse de otros servidores. En este caso, el identificador es 1.
2. enforce-gtid-consistency = 1:
   • Asegura que todas las transacciones que se ejecutan en el servidor sean compatibles con GTID. Cuando está habilitada (= 1), no se permite el uso de transacciones que no sean compatibles con GTID, lo cual es necesario para mantener la consistencia en un entorno de replicación con GTID.
3. log_bin = /var/log/mysql/mysql-bin:
   • Especifica la ruta y el nombre base para los archivos de registro binario (bin logs). Los bin logs registran todas las modificaciones de datos y son esenciales para la replicación y recuperación de datos. Aquí, los bin logs se almacenarán en /var/log/mysql/mysql-bin.
4. expire_logs_days = 7:
   • Define el número de días que los archivos de registro binario se mantienen antes de ser automáticamente eliminados. En este caso, los registros binarios se conservarán durante 7 días.
5. sync_binlog = 1:
   • Controla la frecuencia con la que MySQL sincroniza el registro binario a disco. Cuando se establece en 1, MySQL sincroniza los bin logs con el disco después de cada transacción. Esto proporciona la máxima seguridad de datos, asegurando que todas las transacciones se registren en disco en caso de un fallo del sistema.
6. gtid-mode = ON:
   • Habilita el modo GTID en el servidor MySQL. Cuando gtid-mode está activado (ON), MySQL utiliza GTID para identificar y rastrear transacciones de forma global en el entorno de replicación. Esto facilita la gestión y recuperación de las transacciones en un sistema de replicación distribuido.

Esta configuración está orientada a establecer un entorno de replicación robusto y consistente utilizando GTID en MySQL. Se asegura que las transacciones sean compatibles con GTID, los bin logs sean mantenidos y sincronizados de manera adecuada, y que cada servidor en la configuración de replicación tenga un identificador único. Este conjunto de configuraciones es esencial para garantizar la consistencia y la recuperación eficiente de datos en un entorno de replicación MySQL.

2. Crear usuario de replicación en la instancia maestra/fuente

Hay que crear un usuario que tenga solamente el privilegio «REPLICATION_SLAVE», configurado con su respectiva contraseña, y el host correspondiente. Este privilegio le permite a este usuario leer los ficheros binlogs de la instancia fuente.

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

Sustituye los datos del usuario (nombre del usuario y host) por los que consideres.

Valida que el usuario puede acceder al servidor:

mysql -urepl -p

Verifica los privilegios:

SHOW GRANTS;

3. Haz una copia de seguridad de la instancia maestra/fuente

Voy a explicarte dos formas de hacer una copia de los datos de la instancia maestra. La primera con «mysqldump» y la segunda con «Percona XtraBackup». Dependiendo de el tamaño de la base de datos, del número de bases de datos y del número de peticiones que procese la base de datos, te interesará usar una u otra.

3.1. Copia de seguridad con «mysqldump»

mysqldump es una herramienta de línea de comandos proporcionada por MySQL que se utiliza para crear copias de seguridad de bases de datos. Genera un archivo de texto SQL que contiene todos los comandos necesarios para recrear la base de datos desde cero, incluyendo la estructura de las tablas (definiciones de tablas) y los datos contenidos en ellas (inserciones).

Para asegurarte de que tienes una copia coherente de los datos, bloquea las tablas y obtén el estado actual del registro binario.

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Anota el archivo del registro binario y la posición (binlog file y position) que se muestran en la lista.

Ahora ejecuta el siguiente comando para copiar los datos a un fichero:

mysqldump -u root -p --all-databases --master-data > data_dump.sql

Luego, transfiere este archivo al servidor esclavo y restáuralo:

mysql -u root -p < data_dump.sql

3.2. Copia de seguridad con Percona XtraBackup

Percona XtraBackup es una herramienta de código abierto diseñada para realizar copias de seguridad y restauraciones de bases de datos MySQL y MariaDB de manera eficiente y sin tiempos de inactividad. Desarrollada por Percona, XtraBackup permite a los administradores de bases de datos (DBAs) realizar copias de seguridad en caliente, lo que significa que las copias se pueden realizar mientras la base de datos está en funcionamiento y en uso, sin necesidad de interrumpir el servicio.

Características principales de Percona XtraBackup:

1. Copias de seguridad en caliente: Permite realizar copias de seguridad mientras la base de datos está en uso.
2. Rápido y eficiente: Utiliza técnicas avanzadas para minimizar el impacto en el rendimiento de la base de datos durante el proceso de copia de seguridad.
3. Compatibilidad: Funciona con MySQL, MariaDB, y Percona Server, incluyendo versiones específicas de estos sistemas de gestión de bases de datos.
4. Incrementales y diferenciales: Permite realizar copias de seguridad incrementales y diferenciales, reduciendo el tiempo y el espacio necesarios para las copias de seguridad.
5. Compresión y cifrado: Soporta la compresión y el cifrado de las copias de seguridad para ahorrar espacio en disco y asegurar los datos.
6. Restauración rápida: Ofrece mecanismos para una restauración rápida y eficiente de las bases de datos desde las copias de seguridad.
7. Sin bloqueo: No requiere bloquear las tablas durante la copia de seguridad, lo que ayuda a mantener la disponibilidad del sistema.

Beneficios del uso de Percona XtraBackup:

• Minimiza el tiempo de inactividad: Al no requerir que la base de datos esté inactiva durante la copia de seguridad, los servicios pueden continuar sin interrupciones.
• Reducción del uso de recursos: Al ser eficiente en términos de CPU y disco, reduce la carga en el sistema durante las operaciones de copia de seguridad.
• Seguridad de los datos: Con opciones de cifrado, asegura que las copias de seguridad estén protegidas contra accesos no autorizados.
• Flexibilidad: Ofrece múltiples opciones de configuración y personalización para adaptarse a diferentes necesidades y entornos de bases de datos.

Percona XtraBackup es ampliamente utilizado en entornos de producción donde la alta disponibilidad y la integridad de los datos son críticas, y es una herramienta esencial para los DBAs que gestionan grandes volúmenes de datos y requieren soluciones de copia de seguridad y recuperación confiables y eficientes.

Para utilizar Percona Xtrabackup para realizar una réplica de una base de datos MySQL, debes seguir una serie de pasos detallados que incluyen realizar una copia de seguridad, preparar la copia de seguridad y restaurarla en el servidor de réplica.

Ejecuta el siguiente comando:

xtrabackup --backup --user=usuarioDB --password=usuarioDBPassword --target-dir=/ruta/al/directorio/del/backup

Aquí, reemplaza «/ruta/al/directorio/del/backup" por la ruta donde deseas almacenar la copia de seguridad, y «usuarioDB" y «usuarioDBPassword" por las credenciales de tu base de datos.

El backup terminará cuando veas el siguiente texto:

xtrabackup: completed OK!

Para que el backup sea consistente ejecuta el siguiente comando:

xtrabackup --prepare --target-dir=/ruta/al/directorio/del/backup

Una vez que finalice, XtraBackup te devolverá el mismo mensaje que antes

Desde la instancia maestra usamos rsync para enviar la copia a la réplica:

rsync -avpP -e ssh /ruta/al/directorio/del/backup Replica:/ruta/al/directorio/del/backup_temporal

Asegúrate que MySQL está parado en la instancia de réplica:

service mysql stop

Asegúrate de que el directorio de datos de MySQL en el esclavo/replica esté vacío o muévelo a otra ubicación antes de restaurar:

mv /ruta/a/mysql/data /ruta/a/mysql/data_bak

Movemos la copia del maestro a donde le corresponde:

xtrabackup --move-back --target-dir=/ruta/al/directorio/del/backup_temporal

Cuando se haya realizado la copia cambia el usuario y el grupo:

chown -R mysql:mysql /ruta/a/mysql/data

5. Configurar el servidor MySQL de la instancia de la réplica

Copia la configuración de la instancia maestra a la instancia de la réplica, bien copiando el fichero o su contenido.

Cuando lo tengas, entra en el fichero y modifica el valor de «server-id»:

server-id=2
enforce-gtid-consistency = 1
log_bin                         = /var/log/mysql/mysql-bin
expire_logs_days                = 7
sync_binlog                     = 1
gtid-mode = ON

Si tuvieras más réplicas, indica el identificador que correspondiese.

Ahora puedes volver a iniciar el servidor de MySQL:

service mysql start

6. Iniciar la replicación

De la instancia maestra tenemos que obtener el valor del registro del binlog en el que se encuentra (si no lo has hecho previamente), de tal forma que se lo podamos indicar a la réplica para que se sincronicen. Por tanto entra a MySQL de la instancia maestra y ejecuta la siguiente consulta:

show master status;

Nos quedaremos con los datos de los campos «File» y «Position» (verás algo como «mysql-bin.000002» y «197» respectivamente).

Ahora, en la instancia de la réplica entramos a MySQL y configuramos la replicación (reemplaza los valores según tu configuración):

change replication source to source_host='instancia_maestraip', source_user='usuario_replica', source_password='usuario_replica_password', source_log_file='valor_campo_File_maestro', source_log_pos=numero_valor_campo_Position_maestro;

Los valores de MASTER_LOG_FILE y MASTER_LOG_POS deben ser obtenidos de los logs de MySQL en el servidor maestro justo antes de hacer la copia de seguridad o durante la configuración inicial de la replicación.

Si todo ha ido bien, ya puedes iniciar la réplica:

start replica;

7. Comprobaciones

Ahora puedes validar que todo va bien en la réplica:

show replica status\G;

Verás un listado de variables como las siguientes:

*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: masterdb
                  Source_User: repl
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000002
          Read_Source_Log_Pos: 1955663
               Relay_Log_File: replicadb-relay-bin.000002
                Relay_Log_Pos: 13046
        Relay_Source_Log_File: mysql-bin.000002
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 1955663
              Relay_Log_Space: 13257
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File: 
           Source_SSL_CA_Path: 
              Source_SSL_Cert: 
            Source_SSL_Cipher: 
               Source_SSL_Key: 
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Source_Server_Id: 1
                  Source_UUID: 67a9f8bd-f869-11ed-a46a-42010a010032
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Source_Retry_Count: 86400
                  Source_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Source_SSL_Crl: 
           Source_SSL_Crlpath: 
           Retrieved_Gtid_Set: 67a9f8bd-f869-11ed-a46a-42010a010032:619401-619424
            Executed_Gtid_Set: 67a9f8bd-f869-11ed-a46a-42010a010032:1-619424
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Source_TLS_Version: 
       Source_public_key_path: 
        Get_Source_public_key: 0
            Network_Namespace: 
1 row in set (0.00 sec)

Asegúrate de que los valores de «Slave_IO_Running» y «Slave_SQL_Running" estén en Yes y que no haya errores en la replicación.

Conclusión

Siguiendo estos pasos, deberías poder configurar con éxito una réplica de base de datos MySQL. La replicación te ayudará a mejorar la disponibilidad y escalabilidad de tus aplicaciones.