Cómo montar la réplica de la bbdd (y limpiarla bastante)

[angelhc]

Os pongo los pasos para montar una réplica de la bbdd con dos objetivos, el primero es tener una copia actualizada al segundo por si la bbdd master sufriera algún contratiempo. El segundo objetivo, y no menos importante, es que cuando hacemos un dump y lo volcamos se optimiza el espacio libre en mysql y se puede liberar una gran cantidad de espacio en disco.

PASOS:
============================================
Modificar en el master /etc/mysql/my.cnf añadiendo estas líneas:

server-id=1
binlog-format = mixed
log-bin=mysql-bin
datadir=/var/lib/mysql
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Reiniciamos el servicio de mysql en el master.
Creamos un usuario en servidor master para que pueda accer a la réplica

CREATE USER replicant@<<slave-server-ip>>;
GRANT REPLICATION SLAVE ON *.* TO replicant@<<slave-server-ip>> IDENTIFIED BY '<<choose-a-good-password>>';


Realizamos un backup de la bbdd del master:

mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > ~/dump.sql

Cuando acaba tenemos que ver los valores MASTER_LOG_FILE y MASTER_LOG_POS ya que luego arrancaremos el slave con ellos.

head dump.sql -n80 | grep "MASTER_LOG_POS"

transferimos el backup al servidor slave

scp ~/dump.sql.gz mysql-user@<<slave-server-ip>>:~/

Añadimos las siguientes líneas en el /etc/mysql/my.cnf del servidor SLAVE:

server-id = 101
binlog-format = mixed
log_bin = mysql-bin
relay-log = mysql-relay-bin
log-slave-updates = 1
read-only = 1


Reiniciamos el slave y cargamos la copia en la bbdd:

mysql -u root -p < ~/dump.sql

Añadimos la configuración del server master en la bbdd del SLAVE y arrancamos el servicio de slave:

CHANGE MASTER TO MASTER_HOST='<<master-server-ip>>',MASTER_USER='replicant',MASTER_PASSWORD='<<s lave-server-password>>', MASTER_LOG_FILE='<<value from above>>', MASTER_LOG_POS=<<value from above>>;
START SLAVE;


Para chequear que todo es correcto:
SHOW SLAVE STATUS \G

Si todo es correcto el valor "Last_Error" debe estar en blanco
Cuando el valor Slave_IO_State aparezca “Waiting for master to send event” y el "Seconds_Behind_Master" indique que está a "0" indicará que está la réplica 100% correcta y sin delays.

Si tenemos problemas en la réplica (por ejemplo si hemos tocado un campo en el server slave) podemos decir que se salte el error así:
STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;


Y con eso tenemos una mysql replicada, con un downtime del servidor master menor a 1 minuto (lo que tarda en reiniciar el servicio de mysql) y muy controlable /limpio
Espero que os sirva!
Saludos!

[CesarVC]

Muchas gracias Angel.
Seguro que le damos uso.

[cnunez]

Gracias, se ve interesante

[angelhc]

Probadlo, a mi me ha ido de perlas y tengo que decir que con un downtime tan bajo es una de las mejores opciones que he encontrado.
Además te deja la bbdd limpia limpia