Reduce la durabilidad en MySQL para el rendimiento

Question

Mi sitio ocasionalmente tiene ráfagas de tráfico bastante predecibles que aumentan el rendimiento en 100 veces más de lo normal. Por ejemplo, vamos a aparecer en un programa de televisión, y espero que en la hora posterior al programa, reciba más de 100 veces más tráfico de lo normal.

Mi entendimiento es que MySQL (InnoDB) generalmente mantiene mis datos en un montón de lugares diferentes:

• RAM Buffers
• commitlog
• registro binario
• tablas reales
• Todos los lugares anteriores en mi DB esclavo

Esto es demasiada "durabilidad" dado que estoy en un nodo EC2 y la mayoría de las cosas pasa por el mismo conducto de red (los sistemas de archivos están conectados a la red). Además, las unidades son lentas. Los datos no son de alto valor y prefiero tener una pequeña posibilidad de perder unos pocos minutos en lugar de tener una alta probabilidad de interrupción cuando llega la multitud.

Durante estas ráfagas de tráfico me gustaría hacer toda esa E/S solo si puedo pagarla. Me gustaría simplemente mantener tanto en la memoria RAM como sea posible (tengo una buena cantidad de RAM en comparación con el tamaño de los datos que se tocarán durante una hora). Si los almacenamientos intermedios escasean o el canal de E/S no está demasiado sobrecargado, entonces seguro, me gustaría que las cosas vayan al registro de acciones o al registro binario para enviarlo al esclavo. Si, y solo si, el canal de E/S no está sobrecargado, me gustaría volver a escribir en las tablas reales.

En otras palabras, me gustaría MySQL/InnoDB a utilizar un algoritmo de "escribir de nuevo" caché en lugar de un "escribir a través de" caché algoritmo. ¿Puedo convencerlo de hacer eso?

Si esto no es posible, estoy interesado en los consejos de optimización generales de escritura en el rendimiento de MySQL. La mayoría de los documentos tratan sobre la optimización del rendimiento de lectura, pero cuando obtengo una gran cantidad de usuarios, estoy creando cuentas para todos ellos, por lo que es una carga de trabajo que requiere mucha escritura.

Answer 1

Por una parte, InnoDB ya lo hace.

Cuando confirma los datos, está escrito en el archivo de registro para fines de recuperación, pero a la modificación de tablas (datos) sólo se realiza después como un proceso de fondo ('punto de control').

Puede especificar el número de IOPS (http://en.wikipedia.org/wiki/IOPS) que desea dedicar a ese proceso en segundo plano en los comunicados de InnoDB más nuevos (innodb_io_capacity), y siempre que se establece su innodb_log_file_size lo suficientemente grande como InnoDB simplemente se quedará atrás por un tiempo y coger una copia de seguridad luego.

Si InnoDB cae muy por detrás en el trabajo de fondo que puede crear caídas bruscas en el rendimiento cuando se llegue al final de los archivos de registro, y tienen que volver a través del ciclo.Vea la línea 'ninguno' en estos puntos de referencia: http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/

Answer 2

Si puede vivir con un riesgo adicional, estos dos cambios aumentarán en gran medida su rendimiento de escritura.

Conjunto innodb_flush_log_at_trx_commit = 0
Conjunto sync_binlog = 0

Además, el tamaño del búfer de la piscina debe estar alrededor de 70-80% de la memoria del servidor. Aumentar el tamaño del archivo de registro y el tamaño del búfer de registro también puede ayudar hasta cierto punto.