Evitar problemas replicación MySQL con nuevo slave.

Problema:
Se usa un backup o snapshot para montar un nuevo servidor de tipo slave. Resulta que al hacer el backup/snapshot había cierto retraso, por lo que usar la posición del máster que hay anotada en el fichero master.info, puede dar lugar (seguro) a discrepancias en los datos.
 
Explicación:
Partimos de la base de la siguiente vista de situación del status del slave:

mysql> show slave status\G
*************************** 1. row**********************
Slave_IO_State: Waiting for master to send event
Master_Host: 127.0.0.1
Master_User: msandbox
Master_Port: 26768
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 4723
Relay_Log_File: mysql_sandbox26769-relay-bin.000002
Relay_Log_Pos: 874
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_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_Master_Log_Pos: 729
Relay_Log_Space: 1042
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)

mysql>


En las replicaciones hay dos puntos que hay que tener en consideración:
la Posición Ejecución Máster y
la Posición Lectura Máster
La Posición Ejecución Máster, que se aprecia en la variable Relay_Master_Log_File y Exec_Master_Log_Pos, es la posición en el binlog del máster del actual estamento que está siendo ejecutado por el slave extraido desde relay log.
La Posición Lectura Máster, indicada por el Master_Log_File y Exec_Master_log_Pos, es la posición del binlog del máster desde la que el slave está leyendo para ir escribiendo en el relay log.
El problema radica en que si había algún tipo de retraso (cosa harto fácil en el mundo MySQL), la Posición Lectura Máster será diferente y por defecto, más reciente que la Posición Ejecución Máster.
A nivel de filesystem, la Posición Lectura Máster se guarda en el fichero master.info, y la Posición Ejecución Máster se guarda en el fichero relay-log.info.

Como indicaba, si el slave tenía cierto retraso cuando se hizo el snapshot, o se paró para el backup, las dos posiciones indicadas serán diferentes. Siguiendo el siguiente ejemplo, tenemos que el fichero master.info contiene:

--(Fri:20110114:1027)-(0:$)-- cat master.info
15
mysql-bin.000001
4723
127.0.0.1
msandbox
msandbox
26768
60
0

0
--(manuel@klingon)-(/home/manuel/sandboxes/rsandbox_5_1_53/node1/data)--

Y el fichero relay-log muestra lo siguiente:

--(Fri:20110114:1027)-(0:$)-- cat relay-log.info
./mysql_sandbox26769-relay-bin.000002
874
mysql-bin.000001
729
--(manuel@klingon)-(/home/manuel/sandboxes/rsandbox_5_1_53/node1/data)--

Cuando la replicación se inicia en el nuevo servidor, partiendo de la posición del fichero master.info, los estamentos en el binary-log entre la Posición Ejecución Máster y la Posición Lectura Máster son evitados y causa corrupción de datos.

Solución:
La solución consiste en iniciar el nuevo slave usando la posición marcada en el fichero de relay-log (en este caso, resaltada en azul claro).

Have a nice day ;-)
TooManySecrets

 

Tagged mysql replicacion
​