Sempre haverá uma troca entre resiliência e desempenho.
Com o MySQL no ext4, o padrão barreiras = 1 realmente causa uma lentidão, no entanto, a primeira ação não deve ser desativar o registro no diário ou ativar data = write-back.
Primeiro, se a resiliência é de grande importância, um RAID suportado por bateria certamente vale a pena.
As opções de montagem que escolhi, especialmente em RAID sem bateria, são:
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
Isso intencionalmente não está usando data = write-back, porque não quero arriscar a corrupção do sistema de arquivos, resultando em "dados antigos apareçam nos arquivos após uma falha e recuperação do diário" (a citação é de man mount).
A configuração ideal no my.cnf para resiliência total em torno das configurações relacionadas à E / S é:
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
Optei pela seguinte sequência de trade-offs para aumentar o desempenho:
sync_binlog = 0: esta é a primeira configuração do MySQL que mudo da resiliência total. A razão para isso é que ele fornece uma melhoria significativa no desempenho, especialmente onde binlog_format=row(infelizmente é necessário para o Jira). Estou usando réplicas MySQL suficientes no cluster para que, se o binlog fosse corrompido por um cenário de perda de energia, eu fizesse uma cópia binária de outra réplica.innodb_flush_log_at_trx_commit = 2: Embora seja necessário um valor 1 para conformidade total com ACID, com um valor de 2 ", o buffer de log é gravado no arquivo a cada confirmação, mas a operação de liberação para disco não é executada nele. No entanto, a liberação no o arquivo de log ocorre uma vez por segundo também quando o valor é 2. Observe que a liberação de uma vez por segundo não é 100% garantida para acontecer a cada segundo, devido a problemas de agendamento do processo. " (citação de documentos do MySQL)- Atualize as opções de montagem para usar
data=writeback. Observe que, se esse for o seu sistema de arquivos raiz, você também precisará passar uma opção de linha de comando do kernel. Eu dei alguns passos nisso na coderwall .
- Teste vários valores de
innodb_flush_method. É mostrado que O_DIRECT melhora o desempenho em algumas cargas de trabalho, mas não é certo que isso funcione em seu ambiente.
- Melhore para SSDs, caso em que você também vai querer aumentar
innodb_io_capacity, e ajustar configurações, como innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threads, e outras configurações possíveis.