Deseamos brindarte la mejor solución que encontramos en todo internet. Esperamos que te sea de mucha ayuda y si puedes comentarnos algo que nos pueda ayudar a mejorar hazlo con total libertad.
Solución:
aquí hay una idea
Para que sepa que MySQL está procesando completamente el SQL de los registros de retransmisión. Prueba lo siguiente:
STOP SLAVE IO_THREAD;
Esto evitará que la replicación descargue nuevas entradas del maestro en sus registros de retransmisión.
El otro subproceso, conocido como subproceso SQL, continuará procesando las sentencias SQL que descargó del maestro.
cuando corres SHOW SLAVE STATUSGmantén tus ojos en Exec_Master_Log_Pos. Correr SHOW SLAVE STATUSG otra vez. Si Exec_Master_Log_Pos no se mueve después de un minuto, puedes seguir corriendo START SLAVE IO_THREAD;. Esto puede reducir el número de Seconds_Behind_Master.
Aparte de eso, realmente no hay nada que puedas hacer excepto:
- Replicación de confianza
- Monitor
Seconds_Behind_Master - Monitor
Exec_Master_Log_Pos - Correr
SHOW PROCESSLIST;tome nota del subproceso SQL para ver si está procesando consultas de ejecución prolongada.
Por cierto, tenga en cuenta que cuando ejecuta SHOW PROCESSLIST; con la replicación en ejecución, debe haber dos conexiones de base de datos cuyo nombre de usuario sea system user. Una de esas conexiones de base de datos tendrá la instrucción SQL actual procesada por replicación. Siempre que una instrucción SQL diferente sea visible cada vez que ejecute SHOW PROCESSLIST;puede confiar en que mysql todavía se está replicando correctamente.
¿Qué formato de registro binario está utilizando? ¿Está utilizando FILA o DECLARACIÓN?
SHOW GLOBAL VARIABLES LIKE 'binlog_format';
Si está utilizando ROW como formato binlog, asegúrese de que todas sus tablas tengan una clave principal o única:
SELECT t.table_schema,t.table_name,engine
FROM information_schema.tables t
INNER JOIN information_schema .columns c
on t.table_schema=c.table_schema
and t.table_name=c.table_name
and t.table_schema not in ('performance_schema','information_schema','mysql')
GROUP BY t.table_schema,t.table_name
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;
Si ejecuta, por ejemplo, una declaración de eliminación en el maestro para eliminar 1 millón de registros en una tabla sin PK o único key entonces solo se realizará un escaneo completo de la tabla en el lado del maestro, lo que no es el caso en el esclavo.
Cuando se usa ROW binlog_format, MySQL escribe los cambios de filas en los registros binarios (no como una declaración como STATEMENT binlog_format) y ese cambio se aplicará en el lado del esclavo fila por fila, lo que significa que se llevará a cabo un escaneo completo de 1 millón de tablas. en el esclavo para reflejar solo una declaración de eliminación en el maestro y eso está causando un problema de retraso del esclavo.
“segundos detrás” no es una herramienta muy buena para averiguar cuánto detrás del maestro estás realmente. Lo que dice es “la consulta que acabo de ejecutar se ejecutó hace X segundos en el maestro”. Eso no significa que lo alcanzará y estará justo detrás del maestro en el próximo segundo.
Si su esclavo normalmente no se queda atrás y la carga de trabajo del maestro es más o menos constante, se pondrá al día, pero puede tomar algún tiempo, incluso podría tomar “una eternidad” si el esclavo normalmente apenas se mantiene al día con el maestro. Los esclavos operan en un solo subproceso, por lo que es mucho más lento que el maestro, además, si hay algunas consultas que tardan un tiempo en el maestro, bloquearán la replicación mientras se ejecutan en el esclavo.
valoraciones y reseñas
Nos puedes corroborar nuestro ensayo dejando un comentario o valorándolo te damos las gracias.