Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html
Así que la replicación se ha mejorado recientemente en MySQL 5.6. Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que algunas de estas mejoras tendrán que esperar para golpear el mundo real.
Recientemente ayudé a paso en esta dirección con una solución de replicación de geo-localizada. Una parte del país tenía un servidor MySQL 5.1 y la otra parte del país tuvo un nuevo servidor MySQL 5.6 instalado.
Después de lidiar con los problemas de obtener la copia de seguridad inicial de los datos desde el primario al servidor secundario (tardó varias horas para decir lo menos), tuve que decidir podría replicación ponerse al día y mantener el ritmo. El servidor principal tenía algunos grandes consultas y optimización es siempre un buen lugar para empezar. Tuve que hacer el servidor secundario tirando y aplicar lo más rápido que pude primero sin embargo.
Así que aquí hay algunas cosas que debe revisar y tener en cuenta cuando se trata de la réplica. He añadido algunos enlaces de abajo que ayudan a apoyar mis pensamientos mientras trabajaba en esto.
La replicación puede ser muy de E / S pesada. Dependiendo de su aplicación. Un sitio blog no tiene que muchas escrituras por lo que la replicación de E / S es la luz, pero un servidor primario en gran medida por escrito y actualizado va a conducir a un servidor de replicación escribir mucho relay_logs y binary_logs si están habilitadas. Los logs binarios pueden ser activados en la secundaria que le permite ejecutar copias de seguridad o usted puede ser que este servidor sea un primario a otros.
Dividí los registros en una partición de datos diferente del directorio de datos.
Esto se establece en el archivo my.cnf - relay-log
El buffer de InnoDB ya se estableció en un valor de más de 10 GB. Esto fue suficiente para este servidor.
El camarero fue más de 90.000 segundos por detrás todavía.
Así que empecé a hacer algunos ajustes en el servidor y terminamos con estos ajustes en el final. Concedido cada servidor es diferente.
mysql> select @ @ sync_relay_log_info \ G
*************************** 1. fila ***************************
@ @ Sync_relay_log_info: 0
1 row in set (0.08 sec)
mysql> select @ @ innodb_flush_log_at_trx_commit \ G
*************************** 1. fila ***************************
@ @ Innodb_flush_log_at_trx_commit: 2
1 row in set (0.00 sec)
mysql> select @ @ log_slave_updates \ G
*************************** 1. fila ***************************
@ @ Log_slave_updates: 0
mysql> select @ @ sync_binlog \ G
*************************** 1. fila ***************************
@ @ Sync_binlog: 0
1 row in set (0.00 sec)
mysql> select @ @ max_relay_log_size \ G
*************************** 1. fila ***************************
@ @ Max_relay_log_size: 268435456
Me volví el registro binario fuera como yo supervisé diferentes configuraciones y opciones para ayudar a la replicación de ponerse al día. Me tomó un tiempo. Algunos de los ajustes que ves arriba puede o no se han aplicado a medida que trabajaba dentro de este marco de tiempo. Sin embargo, no ponerse al día en 0 segundos atrás. Ahora usted puede notar que muchos de estos ajustes anteriores se relacionan en y alrededor del registro binario. Así que me encontré una pequeña prueba. Por lo tanto, he reiniciado y permitió a los registros de basura. Me registré en el servidor más tarde y encontró que 10,000 + segundos atrás. Así que una vez más, reinicié y desactivado los registros de basura. Se alcanzó (0 segundos detrás) con el servidor principal en menos de 15 minutos. Solía Aurimas ' herramienta mientras veía a ponerse al día también. Si aún no lo use antes, es una herramienta muy agradable y práctico.
Algunos de lectura adicional para usted:
Así que la replicación se ha mejorado recientemente en MySQL 5.6. Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que algunas de estas mejoras tendrán que esperar para golpear el mundo real.
Recientemente ayudé a paso en esta dirección con una solución de replicación de geo-localizada. Una parte del país tenía un servidor MySQL 5.1 y la otra parte del país tuvo un nuevo servidor MySQL 5.6 instalado.
Después de lidiar con los problemas de obtener la copia de seguridad inicial de los datos desde el primario al servidor secundario (tardó varias horas para decir lo menos), tuve que decidir podría replicación ponerse al día y mantener el ritmo. El servidor principal tenía algunos grandes consultas y optimización es siempre un buen lugar para empezar. Tuve que hacer el servidor secundario tirando y aplicar lo más rápido que pude primero sin embargo.
Así que aquí hay algunas cosas que debe revisar y tener en cuenta cuando se trata de la réplica. He añadido algunos enlaces de abajo que ayudan a apoyar mis pensamientos mientras trabajaba en esto.
La replicación puede ser muy de E / S pesada. Dependiendo de su aplicación. Un sitio blog no tiene que muchas escrituras por lo que la replicación de E / S es la luz, pero un servidor primario en gran medida por escrito y actualizado va a conducir a un servidor de replicación escribir mucho relay_logs y binary_logs si están habilitadas. Los logs binarios pueden ser activados en la secundaria que le permite ejecutar copias de seguridad o usted puede ser que este servidor sea un primario a otros.
Dividí los registros en una partición de datos diferente del directorio de datos.
Esto se establece en el archivo my.cnf - relay-log
El buffer de InnoDB ya se estableció en un valor de más de 10 GB. Esto fue suficiente para este servidor.
El camarero fue más de 90.000 segundos por detrás todavía.
Así que empecé a hacer algunos ajustes en el servidor y terminamos con estos ajustes en el final. Concedido cada servidor es diferente.
mysql> select @ @ sync_relay_log_info \ G
*************************** 1. fila ***************************
@ @ Sync_relay_log_info: 0
1 row in set (0.08 sec)
mysql> select @ @ innodb_flush_log_at_trx_commit \ G
*************************** 1. fila ***************************
@ @ Innodb_flush_log_at_trx_commit: 2
1 row in set (0.00 sec)
mysql> select @ @ log_slave_updates \ G
*************************** 1. fila ***************************
@ @ Log_slave_updates: 0
mysql> select @ @ sync_binlog \ G
*************************** 1. fila ***************************
@ @ Sync_binlog: 0
1 row in set (0.00 sec)
mysql> select @ @ max_relay_log_size \ G
*************************** 1. fila ***************************
@ @ Max_relay_log_size: 268435456
Me volví el registro binario fuera como yo supervisé diferentes configuraciones y opciones para ayudar a la replicación de ponerse al día. Me tomó un tiempo. Algunos de los ajustes que ves arriba puede o no se han aplicado a medida que trabajaba dentro de este marco de tiempo. Sin embargo, no ponerse al día en 0 segundos atrás. Ahora usted puede notar que muchos de estos ajustes anteriores se relacionan en y alrededor del registro binario. Así que me encontré una pequeña prueba. Por lo tanto, he reiniciado y permitió a los registros de basura. Me registré en el servidor más tarde y encontró que 10,000 + segundos atrás. Así que una vez más, reinicié y desactivado los registros de basura. Se alcanzó (0 segundos detrás) con el servidor principal en menos de 15 minutos. Solía Aurimas ' herramienta mientras veía a ponerse al día también. Si aún no lo use antes, es una herramienta muy agradable y práctico.
Lo que todo esto significa es que el servidor principal debe ser conforme a ACID. Con esta configuración también está en función del sistema operativo para el caché y limpiar. Este es el servidor se puede utilizar como un servidor de lectura principalmente para alimentar a la información a los demás. También quiere decir que sí, la replicación geo-localizada puede mantenerse al día con un servidor primario.
¿Qué pasa si usted necesita parar el esclavo, se sigue ponerse al día rápidamente?
¿Cómo y por qué te detienes el esclavo es mi primera respuesta. Usted debe entrar en el hábito de usar SLAVE STOP SQL_THREAD , en lugar de SLAVE STOP ; Esto permite que los logs retardados continúen para recopilar datos y no aplicarlo a su servidor principal. Así que si usted puede tomar ventaja de que va a ayudar a reducir el tiempo que toma para que usted pueda rellenar los logs retardados después.
¿Qué pasa si usted necesita parar el esclavo, se sigue ponerse al día rápidamente?
¿Cómo y por qué te detienes el esclavo es mi primera respuesta. Usted debe entrar en el hábito de usar SLAVE STOP SQL_THREAD , en lugar de SLAVE STOP ; Esto permite que los logs retardados continúen para recopilar datos y no aplicarlo a su servidor principal. Así que si usted puede tomar ventaja de que va a ayudar a reducir el tiempo que toma para que usted pueda rellenar los logs retardados después.
- http://www.mysqlperformanceblog.com/2011/07/29/reasons-for-mysql-replication-lag/
- http://www.mysqlperformanceblog.com/2007/05/24/predicting-how-long-data-load-would-take/
- http://www.mysqlperformanceblog.com/2012/08/29/heres-a-quick-way-to-foresee-if-replication-slave-is-ever-going-to-catch-up-and-when/
