Siempre habrá una compensación entre resistencia y rendimiento.
Con MySQL en ext4, el valor predeterminado de barreras = 1 en realidad causa una desaceleración, sin embargo, la primera acción no debe ser desactivar el registro en diario o activar data = writeback.
Primero, si la capacidad de recuperación es de gran importancia, un RAID respaldado por batería ciertamente vale la pena.
Las opciones de montaje que he elegido, especialmente en RAID sin batería son:
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
Esto intencionalmente no está utilizando data = writeback porque no quiero arriesgarme a la corrupción del sistema de archivos que resulte en "datos antiguos que aparecerán en los archivos después de un bloqueo y recuperación del diario" (la cita es de man mount).
La configuración ideal en my.cnf para una resistencia total en torno a las configuraciones relacionadas con E / S son:
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
He optado por la siguiente secuencia de compensaciones para aumentar el rendimiento:
sync_binlog = 0: esta es la primera configuración de MySQL que cambio de la resistencia total. La razón de esto es que proporciona una mejora significativa en el rendimiento, especialmente donde binlog_format=row(desafortunadamente se requiere para Jira). Estoy usando suficientes réplicas de MySQL en el clúster para que si el binlog se corrompe por un escenario de pérdida de energía, haría una copia binaria de otra réplica.innodb_flush_log_at_trx_commit = 2: Si bien se requiere un valor de 1 para el cumplimiento total de ACID, con un valor de 2 ", el búfer de registro se escribe en el archivo en cada confirmación, pero no se realiza la operación de vaciado al disco. Sin embargo, el vaciado en el el archivo de registro se realiza una vez por segundo también cuando el valor es 2. Tenga en cuenta que el vaciado de una vez por segundo no está 100% garantizado que ocurra cada segundo, debido a problemas de programación del proceso ". (cita de documentos de MySQL)- Actualice las opciones de montaje para usar
data=writeback. Tenga en cuenta que si este es su sistema de archivos raíz, también deberá pasar una opción de línea de comandos del núcleo. Puse algunos pasos sobre eso en coderwall .
- Prueba varios valores de
innodb_flush_method. Se muestra que O_DIRECT mejora el rendimiento en algunas cargas de trabajo, pero no es seguro que esto funcione en su entorno.
- Actualizar a los SSD, en cuyo caso usted también desea aumentar
innodb_io_capacity, y ajustar la configuración, tales como innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threads, y otras configuraciones posibles.