Wow, tienes un hardware terriblemente robusto para este problema. No hay mucho más que pueda ofrecerle en cuanto a hardware, con la excepción de actualizar a quizás CPUs Sandy / Ivy Bridge para un 20-50% de mejor rendimiento de las búsquedas de Btree, etc.
Tenga en cuenta que mi fuerte es Innodb, así que voy a
- Ignora que eres myisam y actúa como si no hiciera la diferencia.
- Suponga que este problema es un impulso suficiente para que pueda actualizar. Sí, es una actualización.
Innodb puede ayudar a aprovechar al máximo toda esa memoria almacenando estas filas de acceso frecuente en su grupo de búferes. Puede ajustarlo para que sea tan grande como desee (digamos el 80% de la memoria) y las nuevas lecturas / escrituras permanecen en la memoria hasta que necesite empujarlas al disco para dejar más espacio para los últimos datos accedidos. En la memoria es un orden de magnitud más rápido que sus FusionIOs.
Hay muchas más características de Innodb, como hashes adaptativos, mecanismos de bloqueo automático, etc. que pueden ser de gran ayuda para su entorno. Sin embargo, usted conoce sus datos mejor que yo.
En el mundo innodb, una buena solución a corto plazo es optimizar su esclavo: ¿realmente necesita todos los índices de su esclavo que tenga en su maestro? Los índices son una bola y una cadena en inserciones / actualizaciones / eliminaciones, INCLUSO con tarjetas Fusion IO. Los IOPS no lo son todo aquí. Sandy / Ivy Bridge Procs tienen mucho mejor rendimiento de memoria y rendimiento informático: pueden marcar una gran diferencia en los Westmeres que tiene ahora. (Figura 20-50% en general). ¡Elimine todos los índices que no necesita en el esclavo!
En segundo lugar, y casi con certeza solo se aplica a innodb, es que mk-prefetch puede saber qué actualizaciones y antes de que el esclavo las escriba. Esto permite que mk-prefetch ejecute primero una consulta de lectura, forzando así que los datos estén en la memoria para cuando la única respuesta ejecute la consulta de escritura. Esto significa que los datos están en la memoria y no en fusionIO, un aumento rápido en el rendimiento del orden de magnitud. Esto hace una GRAN diferencia, más de lo que cabría esperar. Muchas empresas usan esto como una solución permanente. Obtenga más información visitando el Kit de herramientas de Percona .
Tercero, y lo más importante, una vez que hayas actualizado a Innodb, definitivamente revisa Tokutek. Estos muchachos tienen algunas cosas terriblemente increíbles que superan el rendimiento de escritura / actualización / eliminación de Innodb por mucho. Ellos promocionan la velocidad de replicación mejorada como uno de los beneficios clave, y puede ver en sus puntos de referencia por qué Fusions crazy IOPS aún no lo ayudará en el caso de Btrees . (Nota: no verificado de forma independiente por mí). Usan un reemplazo directo de un índice btree que, si bien es horriblemente más complejo, mejora muchas de las limitaciones de velocidad algorítmica de los índices btree.
Estoy en el proceso de considerar la adopción de Tokutek. Si liberan tanta velocidad de escritura, eso me permite agregar más índices. Dado que comprimen los datos y los índices en proporciones tan maravillosas (25x que citan), ni siquiera paga un precio (rendimiento, mantenimiento) por el aumento de datos. Sin embargo, usted paga ($) por su motor, $ 2500 / año por GB precomprimido, IIRC. Tienen descuentos si tiene los datos replicados, pero incluso puede instalar Tokutek en su esclavo y mantener su maestro tal como está. Echa un vistazo a los detalles técnicos en la conferencia MIT Algoritms Open Courseware . Alternativamente, tienen toneladas de material técnico en su blog y libros blancos regulares para aquellos que no tienen 1:20 para ver el video. Creo que este video también ofrece la fórmula Big-O de lo rápido que son las lecturas. Yo tengoasumir que las lecturas son más lentas (¡siempre hay una compensación!), pero la fórmula es demasiado compleja para que yo pueda calcular cuánto. Afirman que es más o menos lo mismo, pero prefiero entender las matemáticas (¡no es probable!). Puede estar en una mejor situación para descubrir esto que yo.
PD: No estoy afiliado a Tokutek, nunca he ejecutado su producto y ni siquiera saben que los estoy mirando.
Actualización :
Veo que tienes algunas otras preguntas en esta página y pensé que debería incluir:
Primero, la búsqueda previa de esclavos seguramente no funcionará para myisam a menos que tenga un entorno excepcional. Esto se debe principalmente a que la captación previa bloqueará las tablas en las que desea escribir, o el subproceso esclavo tiene la tabla bloqueada que necesita el demonio de captación previa. Si sus tablas están extremadamente bien equilibradas para la replicación y se escriben diferentes tablas de forma circular, esto puede funcionar, pero tenga en cuenta que esto es muy teórico. El libro "High Performance Mysql" tiene más información en la sección "Problemas de replicación".
En segundo lugar, presumiblemente su esclavo tiene una carga de 1.0-1.5, puede ser mayor si tiene otros procesos o consultas ejecutándose pero una línea de base de 1.0. Esto significa que es probable que esté vinculado a la CPU, lo cual es probable con su FusionIO a bordo. Como mencioné anteriormente, Sandy / Ivy Bridge va a dar un poco más de empuje, pero probablemente no lo suficiente para atravesar los tiempos más difíciles con un retraso mínimo. Si la carga en este esclavo es principalmente de solo escritura (es decir, no hay muchas lecturas), su CPU seguramente gastará su tiempo calculando posiciones para las inserciones / eliminaciones de btree. Esto debería reforzar mi punto anterior sobre la eliminación de índices no críticos: siempre puede volver a agregarlos más tarde. Desactivar hyperthreading no funcionará, más CPU no es tu enemigo. Una vez que supere los 32 GB de ram, digamos 64 GB, debe preocuparse por la distribución de ram, pero incluso entonces los síntomas son diferentes.
Finalmente, y lo más importante (no omita esta parte;)), supongo que ahora está ejecutando RBR (replicación basada en filas) porque mencionó un aumento de rendimiento no trivial al cambiarlo también. Sin embargo, puede haber una forma de obtener aún más rendimiento aquí. El error Mysql 53375 puede manifestarse si tiene tablas que se replican sin clave primaria. Básicamente, el esclavo no es lo suficientemente inteligente como para usar cualquier cosa que no sea una clave primaria, por lo que la ausencia de una fuerza obliga al hilo de replicación a hacer un escaneo completo de la tabla para cada actualización. Una solución es simplemente agregar una clave primaria benigna y sustituta de autoincremento. Solo haría esto si la tabla fuera grande (por ejemplo, varias decenas de miles de filas o más). Esto, por supuesto, tiene el costo de tener otro índice sobre la mesa, lo que eleva el precio que paga en la CPU. Tenga en cuenta que hay muy pocos argumentos teóricos en contra de esto, ya que InnoDB agrega uno detrás de escena si no lo hace. El único fantasma, sin embargo, no es una defensa útil contra 53375. tungsteno puede superar este problema también, pero que necesita para estar seguro cuando se usa tungsteno que tiene su codificación recta. La última vez que jugué con él, moriría horriblemente cuando cualquier cadena que no sea UTF8 necesitara replicarse. Ese es el momento en que me di por vencido.
