18 May 2015

Desfase en replicación de MySQL!!!

Desfase en replicación de MySQL!!!

Todos queremos información al momento, pero esto no se puede sin una buena planeación de la infraestructura con que contamos.

Cuando se presenta un desfase en un servidor de replicación, suele suceder por una carga de trabajo, pero antes de analizar que hacer (si es posible hacer algo), hay que entender que es lo que estamos leyendo al revisar el estatus de un servidor esclavo.

SHOW SLAVE STATUS\G;

Nos da la información actual de la replicación, pero leer únicamente el tiempo de desfase en

Seconds_Behind_Master: 2966 no es suficiente.

Más importante es leer los valores de

Master_Log_File: mysql-bin.000173
Relay_Master_Log_File: mysql-bin.000093

El primero nos dice el archivo log sobre el cual servidor principal está trabajando actualmente, y el segundo el archivo 'retrasado' que se está procesando.

Con el ejemplo, hay una diferencia de 80 archivos por procesar cada uno de 100Mb, haz cuenta del número de querys que están pendientes.

El otro valor a considerar es

Relay_Log_Space: 8179978166 que en este ejemplo dice que hay 7.6GB de logs pendientes por procesar.

Si ejecutamos SHOW PROCESSLIST; en el esclavo, podremos tener aún más datos de lo que está sucediendo para provocar este retraso.

Si esto es sólo por una carga de trabajo, se podría detener la descarga de sentencias en el log de relay, para procesar únicamente los comandos del flujo actual y contar con la información más reciente sin tener que esperar a procesar la histórica hasta empatar los flujos, y aunque no es una práctica recomendada, el comando para hacerlo es: STOP SLAVE IO_THREAD;, pero siempre será mejor revisar que es lo que hace que el proceso sea lento. Para ello puedes tomar los logs que ya tiene el esclavo para poder analizarlos y saber si hay algo que se pueda ajustar dentro de las configuraciones:

cd /var/lib/mysql
mysqlbinlog relay-bin.000093 > /root/querys_retraso.txt
less /root/querys_retraso.txt

Artículos relacionados