Protocolo de Recuperación de Slave Asincronico en Mariadb

Protocolo de recuperación de Slave asincronico
en Mariadb
A continuación se detallan los pasos a seguir para regenerar el Slave (172.26.48.17). Este
protocolo debe usarse en caso de que el slave alla perdido la sincronizacion y ya no se pueda
identificar la posicion actual del MASTER con respecto al SLAVE:
1- Ingresamos al SLAVE por Heidi o por terminal y lo detenemos:
STOP SLAVE;
2- Se deben dropear todas las bases de datos existentes en el 48.17. Para ello se usara el
siguiente script, tener en cuenta modificar el user y el password:
mysql -u root -p1234 -e "show databases" | grep -v Database | grep -v

mysql | grep -v information_schema | gawk '{print "SET
FOREIGN_KEY_CHECKS = 0;drop database" $1 ";select sleep(0.1);"}' | mysql
-u root -p1234
3- Se genera un backup en caliente de el MASTER 48.70 CORRIENDO ESTE COMANDO

DESDE EL 48.17 (esto es para que el restore sea mas rápido):
mysqldump --skip-lock-tables --single-transaction --extended-insert -u

nzelada -p -h 172.26.48.70 --flush-logs --master-data=2 -A >
dump_172.26.48.70_AAAAMMDD.sql
Donde:
 --skip-lock-tables: evitara bloquear las tablas durante el dump

 --single-transaction: el proceso se correra como un paquete unico
 --extended-insert: los insert generados se haran con formato extendido, esto es para que
el tamaño del bkp sea mas reducido
 --flush-logs:Limpia los logs de cada base de datos a dumpear
 --master-data: Incluira en el header del dump la poscicion actual del servidor master
(esto es para que luego podamos sincronizarlo)
 -A: Bkp de todas las bases
4- Ni bien finalice el dump, procedemos a importarlo en el motor del Slave (esta es la parte del
proceso que mas tiempo lleva):
mysql -u nzelada -p < dump_172.26.48.70_AAAAMMDD.sql
5- Ver que la configuracion del Slave este correcta, según la siguiente infromacion:
[mysqld]
#########################################################
#ESCLAVO DEL 48.70
server-id= 2
relay-log = mysql-relay-bin
log-slave-updates = 1
read-only = 1
relay_log_purge = 1
relay_log_space_limit = 5G
#########################################################
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security

risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
#########################################################
#########################################################
skip-networking=0
bind-address=0.0.0.0
skip-bind-address
max_allowed_packet = 256M
[mysqld_safe]
log-error=/var/lib/mysql/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
# include all files from the config directory
!includedir /etc/my.cnf.d
# The MySQL server
key_buffer_size = 384M
table_open_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
donde lo importante es:
server-id = 2
binlog-format = mixed
log_bin = mysql-bin
relay-log = mysql-relay-bin
log-slave-updates = 1
read-only = 1
6- Si se realizaron cambios en el archivo de configuracion, reiniciar el Mysql en 48.17
7- Chequeamos el MASTER_LOG_FILE y MATER_LOG_POS para ver en que posicion se

encuentraba el MASTER al moment del bkp, lo hacemos en el archivo de backup.
head dump_172.26.48.70_20190918.sql -n80 | grep "MASTER_LOG_POS"
8- Ahora configuramos los parametros principales del SLAVE, tales como el host del master, el
user que se va a usar para replicar, el password, el master log file (que obtuvimos en el punto
anterior, el master log pos (tambien del punto anterior) ESTE ES EL PUNTO MAS IMPORANTE
DEL PROTOCOLO. ingresamos al mysql a travez de terminal y ejecutamos
CHANGE MASTER TO
MASTER_HOST='<>',MASTER_USER='replicant',MASTER_PASSWORD='<>',
MASTER_LOG_FILE='<>', MASTER_LOG_POS=<>;
credenciales para replicar desde el 172.26.48.17 mariadb:
usuario: replicador
password: 744(CzbnVeaz5XO
9- Inciamos el SLAVE desde mysql:
START SLAVE;
10- Chequeamos el estado del servidor, corriendo
show slave status\G o "show slave status" en heidi
Tenemos que mirar los campos:
 Slave_IO_State: debe decir: "Waiting for master to send event"

 Slave_SQL_Running_State: debe estar vacio o decir "Slave has read all relay log;
waiting for the slave I/O thread to update it" si ya logro replicar toda la info y esta a la
espera
 En caso de que aun este sincronizando deberiamos tener un valor numerico en
"Seconds_Behind_Master"
11- Si esta todo ok BORRAMOS EL BACKUP y volvemos a respirar

Protocolo de Recuperación de Slave Asincronico en Mariadb

Cargado por

Copyright:

Formatos disponibles

Protocolo de Recuperación de Slave Asincronico en Mariadb

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Protocolo de Recuperación de Slave Asincronico en Mariadb

Cargado por

Copyright:

Formatos disponibles

Protocolo de recuperación de Slave asincronico

1- Ingresamos al SLAVE por Heidi o por terminal y lo detenemos:

mysql -u root -p1234 -e "show databases" | grep -v Database | grep -v

3- Se genera un backup en caliente de el MASTER 48.70 CORRIENDO ESTE COMANDO

mysqldump --skip-lock-tables --single-transaction --extended-insert -u

 --skip-lock-tables: evitara bloquear las tablas durante el dump

mysql -u nzelada -p < dump_172.26.48.70_AAAAMMDD.sql

#ESCLAVO DEL 48.70

# Disabling symbolic-links is recommended to prevent assorted security

# Settings user and group are ignored when systemd is used.

# If you need to run mysqld under a different user or group,

# customize your systemd unit file for mariadb according to the

# include all files from the config directory

# The MySQL server

# Try number of CPU's*2 for thread_concurrency

donde lo importante es:

6- Si se realizaron cambios en el archivo de configuracion, reiniciar el Mysql en 48.17

7- Chequeamos el MASTER_LOG_FILE y MATER_LOG_POS para ver en que posicion se

head dump_172.26.48.70_20190918.sql -n80 | grep "MASTER_LOG_POS"

credenciales para replicar desde el 172.26.48.17 mariadb:

9- Inciamos el SLAVE desde mysql:

10- Chequeamos el estado del servidor, corriendo

show slave status\G o "show slave status" en heidi

Tenemos que mirar los campos:

 Slave_IO_State: debe decir: "Waiting for master to send event"

También podría gustarte