Configurar esclavo MySQL con SSL

Propósito y alcance

Esta sección describe cómo convertir un servidor secundario en un esclavo de replicación MySQL usando conexión SSL. Define los pasos mínimos: ajustar my.cnf, reiniciar el servicio, crear e importar la base de datos vacía, ejecutar CHANGE MASTER con las rutas de los certificados y comprobar el estado de la replicación.

Definición rápida: “esclavo” — servidor MySQL que aplica los cambios enviados por el “maestro” mediante replicación binaria.

Important: el valor server-id debe ser único en cada instancia MySQL en la topología de replicación.

Requisitos previos

Acceso root/administrador en el servidor esclavo (SSH + permisos para editar /etc/my.cnf y reiniciar MySQL).
Credenciales del usuario de replicación creadas en el maestro (usuario y contraseña con privilegios REPLICATION SLAVE).
Snapshot SQL del maestro (snapshot.sql) y la contraseña root para importar el volcado, o un método alternativo de sincronización consistente.
Certificados SSL en el esclavo: ca-cert.pem, client-cert.pem, client-key.pem (rutas relativas usadas más abajo). Asegúrese de que los permisos de las claves privadas sean restrictivos (por ejemplo 600).

1. Editar /etc/my.cnf en el esclavo

Abra /etc/my.cnf y asegúrese de que la sección [mysqld] contenga los ajustes necesarios (server-id, master-connect-retry, replicate-do-db). En este ejemplo el servidor esclavo se denomina server2:

server2:

vi /etc/my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
ssl
server-id=2
master-connect-retry=60
replicate-do-db=exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Nota: server-id debe ser distinto del server-id del maestro. master-connect-retry es el tiempo en segundos que MySQL reintentará la conexión al maestro.

2. Reiniciar MySQL

Después de editar my.cnf, reinicie MySQL:

/etc/init.d/mysqld restart

En sistemas systemd use: systemctl restart mysqld

3. Crear la base de datos vacía en el esclavo

Antes de aplicar el volcado del maestro, cree una base de datos vacía con el mismo nombre que se va a replicar:

mysql -u root -p

Dentro del cliente MySQL:

CREATE DATABASE exampledb;
quit;

4. Importar el snapshot en el esclavo

Detenga cualquier proceso de slave activo y copie/importe el volcado snapshot.sql en exampledb:

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

Asegúrese de que snapshot.sql sea coherente con el estado mostrado por SHOW MASTER STATUS en el maestro (archivo y posición). Si el volcado fue creado con mysqldump –master-data, éste incluirá la posición binlog.

5. Conectar y ejecutar CHANGE MASTER

Conéctese de nuevo al servidor MySQL en el esclavo:

mysql -u root -p

Ejecute el comando CHANGE MASTER usando los valores obtenidos en el maestro con SHOW MASTER STATUS; (reemplazar los valores por los reales):

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

Significado de los parámetros claves:

MASTER_HOST: IP o hostname del maestro (ej. 192.168.0.100).
MASTER_USER: usuario con permisos de replicación creados en el maestro.
MASTER_PASSWORD: contraseña de MASTER_USER.
MASTER_LOG_FILE y MASTER_LOG_POS: archivo y posición binlog del maestro tomados con SHOW MASTER STATUS;.
MASTER_SSL y rutas MASTER_SSL_CA/CERT/KEY: habilitan SSL y señalan los certificados a usar en la conexión esclavo→maestro.

6. Iniciar el esclavo y comprobar el estado

Inicie la replicación en el esclavo:

START SLAVE;

Y consulte el estado:

SHOW SLAVE STATUS \G

Es importante que en la salida los campos Slave_IO_Running y Slave_SQL_Running sean Yes. También, al usar SSL, espere valores en Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert y Master_SSL_Key.

Ejemplo de salida (muestra informativa):

mysql> SHOW SLAVE STATUS \G * 1. row * Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.100 Master_User: slave_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 3096416 Relay_Log_File: mysqld-relay-bin.000002 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: exampledb 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_Master_Log_Pos: 3096416 Relay_Log_Space: 235 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Yes Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem Master_SSL_CA_Path: Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem Master_SSL_Cipher: Master_SSL_Key: /etc/mysql/newcerts/client-key.pem Seconds_Behind_Master: 0 1 row in set (0.00 sec)

mysql>

Posteriormente puede salir del cliente MySQL:

quit;

Pruebas rápidas para validar la replicación

En el maestro cree una tabla y añada una fila:

mysql -u root -p -h 192.168.0.100
USE exampledb;
CREATE TABLE replication_test (id INT PRIMARY KEY AUTO_INCREMENT, msg VARCHAR(100));
INSERT INTO replication_test (msg) VALUES ('prueba desde maestro');

En el esclavo compruebe que la tabla y los datos aparezcan:

mysql -u root -p
USE exampledb;
SELECT * FROM replication_test;

Si aparecen los mismos datos en el esclavo, la replicación está funcionando.

Resolución de problemas común

Slave_IO_Running = No: comprobar conectividad de red, firewall, DNS y que MASTER_HOST resuelva. Revisar /var/log/syslog o /var/log/mysqld.log.
Slave_SQL_Running = No: inspeccione Last_Error y Last_Errno en SHOW SLAVE STATUS; errores de SQL suelen indicar conflictos de esquema o valores no válidos.
Problemas SSL: verifique permisos y formato de los archivos ca-cert.pem, client-cert.pem y client-key.pem; asegúrese de que MASTER_SSL_CA/CERT/KEY apunten a rutas exactas y accesibles por el servicio MySQL.
Posición errónea: si el snapshot no coincide con la posición del maestro, es posible que necesite volver a generar el snapshot o usar una copia binaria consistente.

Comandos útiles de diagnóstico:

SHOW MASTER STATUS;
SHOW SLAVE STATUS \G
tail -n 200 /var/log/mysqld.log
cat /var/log/syslog | grep mysql

Checklist por roles

DBA:
- Verificar usuario de replicación y privilegios en el maestro.
- Generar snapshot consistente (mysqldump –master-data o método lógico/consistente).
Operaciones/Sysadmin:
- Transferir snapshot y certificados al esclavo.
- Configurar /etc/my.cnf y reiniciar mysqld.
Seguridad:
- Asegurar archivos de clave con permisos 600.
- Validar la cadena de certificados y fecha de expiración.

Alternativas y consideraciones

GTID: en despliegues modernos, GTID-based replication puede simplificar la conmutación y recuperación; requiere configuración adicional en maestro y esclavo.
Replicación sin SSL: solo si la red es de confianza o se usa VPN; preferible habilitar SSL para entornos de producción.
Replicación a múltiples esclavos: cada esclavo necesita server-id único y, opcionalmente, filtros de replicación para limitar bases/tablases a replicar.

Pequeña metodología de verificación (mini-playbook)

Confirmar SHOW MASTER STATUS en maestro y anotar File/Position.
Crear base de datos vacía en esclavo y aplicar snapshot.
Ejecutar CHANGE MASTER TO … con los valores correctos y rutas SSL.
START SLAVE y comprobar SHOW SLAVE STATUS \G.
Ejecutar pruebas funcionales (INSERT/SELECT) y revisar Seconds_Behind_Master.

Seguridad y privacidad

Mantenga las claves privadas fuera de directorios públicos y con permisos restrictivos.
No registre contraseñas en ficheros de log o en scripts sin protección.
Si maneja datos personales (GDPR/LPD), asegúrese de que la replicación y el almacenamiento en el esclavo cumplan los requisitos de retención y cifrado establecidos por la normativa.

Criterios de aceptación

El esclavo tiene server-id único y my.cnf configurado correctamente.
Después de START SLAVE, SHOW SLAVE STATUS \G muestra Slave_IO_Running: Yes y Slave_SQL_Running: Yes.
MasterSSL* muestra las rutas a CA/CERT/KEY y Master_SSL_Allowed es Yes.
Una inserción de prueba en el maestro aparece en el esclavo dentro del intervalo esperado.

Atajos y tabla de comandos (cheat sheet)

Editar my.cnf: vi /etc/my.cnf
Reiniciar MySQL (SysV): /etc/init.d/mysqld restart
Reiniciar MySQL (systemd): systemctl restart mysqld
Detener replicación: STOP SLAVE;
Iniciar replicación: START SLAVE;
Ver estado: SHOW SLAVE STATUS \G
Forzar rescan de logs: FLUSH LOGS;

Enlaces

MySQL: http://www.mysql.com/
CentOS: http://www.centos.org/

Resumen final: configure server-id único, importe un snapshot consistente, ejecute CHANGE MASTER con las rutas SSL correctas y verifique que Slave_IO_Running y Slave_SQL_Running sean Yes. Realice pruebas sencillas de inserción para validar la replicación.

Configurar el esclavo de MySQL