Procedimiento MySQL 5.7.42 (192.168.63.1) → MariaDB 10.6.24 slave (192.168.63.4), usando archivo/posición de binlog, que es lo correcto para este cruce MySQL→MariaDB. MariaDB documenta que 10.2+ puede replicar desde MySQL 5.7, y que no usa el GTID de MySQL, por lo que el replica debe engancharse con binary log file + position. También indica que, cuando MariaDB replica desde MySQL, puede ser necesario usar binlog_checksum=NONE en el primario MySQL. (MariaDB)
1) En el master MySQL 5.7.42 — 192.168.63.1
Edita my.cnf y asegúrate de tener esto:
[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW
bind-address=192.168.63.1
binlog_checksum=NONE
expire_logs_days=7
ROW es la opción más segura para este tipo de replicación, y binlog_checksum=NONE es un ajuste que MariaDB recomienda considerar cuando el replica es MariaDB. (MariaDB)
Reinicia MySQL.
Ahora crea el usuario de replicación:
CREATE USER 'repl'@'192.168.63.4' IDENTIFIED BY 'ClaveFuerteAqui';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.63.4';
FLUSH PRIVILEGES;
Ahora saca las coordenadas del binlog:
SHOW MASTER STATUS;
Te va a devolver algo así:
File: mysql-bin.000123
Position: 456789
Guarda exactamente esos dos valores.
2) Respaldar y copiar datos del master al slave
Para que el slave arranque consistente, lo correcto es sacar un dump con la posición embebida.
En el master, usando 4 cores exportacion paralela, con parametros para no afectar produccion con exceso de carga:
mkdir -p /respaldos/nombre_base_datos
mydumper \
--database nombre_base_datos \
--outputdir /respaldos/nombre_base_datos \
--threads 4 \
--trx-tables \
--routines \
--events \
--triggers \
--compress
cd /respaldos
tar -zcvf nombre_base_datos.tgz nombre_base_datosCópialo al slave:
scp nombre_base_datos.tgz root@192.168.63.4:/respaldos/
3) En el slave MariaDB 10.6.24 — 192.168.63.4
Edita el my.cnf del slave:
[mysqld]
server-id=4
relay-log=relay-bin
log_bin=mariadb-bin
read_only=1
skip-slave-start=1
bind-address=192.168.63.4
server-id debe ser único en la topología. El replica MariaDB debe usar archivo/posición del primario MySQL, no GTID de MySQL. (MariaDB)
Reinicia MariaDB.
Importa el dump:
mysql -e "DROP DATABASE IF EXISTS nombre_base_datos; CREATE DATABASE nombre_base_datos;"
cd /respaldos
tar -zxvf nombre_base_datos.tgz
myloader \
--database nombre_base_datos \
--directory /respaldos/nombre_base_datos \
--threads 4 \
--drop-table \
--overwrite-unsafe4) Apuntar el slave al master
Primero asegúrate de que el slave esté detenido:
STOP SLAVE;
RESET SLAVE ALL;
Luego configura la replicación con el archivo y posición que te dio SHOW MASTER STATUS en el MySQL:
CHANGE MASTER TO
MASTER_HOST='192.168.63.1',
MASTER_USER='repl',
MASTER_PASSWORD='ClaveFuerteAqui',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000123',
MASTER_LOG_POS=456789,
MASTER_CONNECT_RETRY=10;
Arranca la replicación:
START SLAVE;
Verifica:
SHOW SLAVE STATUS\G
Lo importante es ver:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
MariaDB sigue documentando esos campos como referencia de validación en la configuración de replicación. (MariaDB)
5) Si quieres sacar las coordenadas con bloqueo breve
Si prefieres máxima certeza manual en vez de confiar en --master-data, en el master puedes hacer:
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Sin cerrar esa sesión, sacas el dump con otra terminal:
con el comando que ya esta en la guia pasos antes
Y luego liberas:
UNLOCK TABLES;
Para InnoDB normalmente --single-transaction --master-data=2 evita ese bloqueo largo, pero este método manual existe si quieres control total.
6) Validaciones que te recomiendo hacer
En el master:
SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_checksum';
SHOW MASTER STATUS;
En el slave:
SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'read_only';
SHOW SLAVE STATUS\G
Y una prueba real:
En el master:
CREATE DATABASE pr_repl;
USE pr_repl;
CREATE TABLE t1 (
id INT PRIMARY KEY AUTO_INCREMENT,
dato VARCHAR(100)
);
INSERT INTO t1(dato) VALUES ('prueba replicacion');
En el slave:
SELECT * FROM pr_repl.t1;
7) Problemas típicos en este cruce MySQL 5.7 → MariaDB 10.6
Error por checksums
Si el slave no engancha bien o marca errores de lectura de binlog, revisa que en el master esté:
binlog_checksum=NONE
Eso está específicamente señalado por MariaDB para escenarios donde MariaDB replica desde MySQL. (MariaDB)
GTID
No intentes montarlo con MASTER_AUTO_POSITION=1 ni con GTID de MySQL. MariaDB no usa la implementación GTID de MySQL para este escenario. (MariaDB)
Motores o SQL incompatibles
La replicación puede arrancar bien y aun así fallar después si el origen usa algo muy específico de MySQL 5.7. MariaDB mantiene compatibilidad amplia, pero no es binariamente idéntico a MySQL en todos los comportamientos. (MariaDB)