MySQL Explicar y SQL_NO_CACHE

Original post: http://anothermysqldba.blogspot.com/2014/04/mysql-explain-sqlnocache.html

Así que hoy me estaba ayudando a alguien con su rendimiento de base de datos y corrió a través de algunas consultas mal escritos. Ahora, sin duda todo el mundo comete errores, el objetivo es hacer todo lo posible para evitarlos.

Así que sólo un par de consejos útiles que hacer antes de dejar una consulta suelta a su entorno.

Siempre ejecutar la consulta a través de explicar primero. Algo tan simple como hacer a explicar primero confirmará sin faltas de ortografía (ya que no se ejecutará), y le permitirá optimizar la consulta.
Ya existen varios enlaces sobre cómo utilizar explique:

• http://ronaldbradford.com/blog/tag/explain/
• http://www.mysqlperformanceblog.com/2014/02/03/percona-toolkit-collection-pt-visual-explain/
• http://www.ustream.tv/recorded/15872720
• https://www.youtube.com/watch?v=qaB85pMVNJU
• https://dev.mysql.com/doc/refman/5.6/en/using-explain.html
• http://www.sitepoint.com/using-explain-to-write-better-mysql-queries/

El objetivo es simple. Usted quiere que las claves válidas en las possible_keys y llaves (no nulas) y cuando se trata de key_len no desea cada tabla sea 100s de filas. Si usted puede conseguir el primer key_len sea 200 (sólo un número que elegí como ejemplo), entonces lo siguiente es 5,4,3,2,1 y no otro 200, entonces su consulta debería funcionar bien. Esa es una afirmación muy simplista y de alto nivel y le sugiero que revise los hipervínculos que figuran entender Explicar más. La consulta que vi hoy tenía 5 + se une y un sub-select (a través de una combinación fue mejor en el dónde declaración) y 200 + filas para cada key_len. A pocos ajustes pueden permitir su consulta a caer a partir de 200 segundos a 1 segundo o menos. Siempre, siempre, siempre explican.

La siguiente pista, trata de poner a prueba sus consultas con SQL_NO_CACHE. Esto le permite probar la consulta real y optimizar de la mejor manera que pueda. Una vez que se convierte en caché (si va a ser), entonces sólo se ejecutará mucho más rápido para usted.

• https://dev.mysql.com/doc/refman/5.6/en/select.html
• http://ronaldbradford.com/blog/using-the-mysql-query-cache-effectively-2009-09-28/

Una última nota ... Echa un vistazo a los consejos de rendimiento de SQL para MySQL que existieron una vez en el sitio fragua, pero ahora están en - https://wikis.oracle.com/pages/viewpage.action?pageId=27263381

Puede replicación MySQL ponerse al día

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.

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.

Algunos de lectura adicional para usted:

• 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/