É seguro usar innodb_flush_log_at_trx_commit = 2

Você pode perder até um segundo de transações. O valor padrão é 1, o que ajuda a manter o InnoDB ACID Compliant .

De acordo com a documentação do MySQL em innodb_flush_log_at_trx_commit

Se o valor de innodb_flush_log_at_trx_commit for 0, o buffer de log será gravado no arquivo de log uma vez por segundo e a operação de liberação para disco será executada no arquivo de log, mas nada será feito em uma confirmação de transação. Quando o valor é 1 (o padrão), o buffer de log é gravado no arquivo de log em cada confirmação de transação e a operação de liberação para disco é executada no arquivo de log. Quando o valor é 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 arquivo de log ocorre uma vez por segundo também quando o valor é 2. Observe que a liberação uma vez por segundo não é 100% garantida para ocorrer a cada segundo, devido a problemas de agendamento do processo.

O valor padrão de 1 é necessário para total conformidade com ACID. Você pode obter um desempenho melhor definindo o valor diferente de 1, mas pode perder até um segundo de transações em uma falha. Com um valor de 0, qualquer falha do processo mysqld pode apagar o último segundo das transações. Com um valor de 2, apenas uma falha do sistema operacional ou uma queda de energia pode apagar o último segundo das transações. A recuperação de falhas do InnoDB funciona independentemente do valor.

Para maior durabilidade e consistência possíveis em uma configuração de replicação usando InnoDB com transações, use innodb_flush_log_at_trx_commit=1 e sync_binlog=1 em seu arquivo my.cnf do servidor mestre.

Cuidado

Muitos sistemas operacionais e alguns hardwares de disco enganam a operação de liberação para disco. Eles podem dizer ao mysqld que o flush ocorreu, mesmo que não. Então a durabilidade das transações não é garantida mesmo com a configuração 1, e na pior das hipóteses uma queda de energia pode até corromper o banco de dados InnoDB. O uso de um cache de disco alimentado por bateria no controlador de disco SCSI ou no próprio disco acelera a liberação de arquivos e torna a operação mais segura. Você também pode tentar usar o comando hdparm do Unix para desabilitar o cache de gravações de disco em caches de hardware ou usar algum outro comando específico para o fornecedor de hardware.

Com base nisso, valores diferentes de 1 colocam o InnoDB em risco de perder o valor de 1 segundo de transações ou o valor de dados de um commit de transação.

A documentação também diz usar sync_binlog=1.

De acordo com a documentação do MySQL em sync_binlog

Um valor de 1 é a escolha mais segura porque, no caso de uma falha, você perde no máximo uma instrução ou transação do log binário. No entanto, também é a opção mais lenta (a menos que o disco tenha um cache com bateria, o que torna a sincronização muito rápida).

Sua escolha mais segura é

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Se você não se importa com a possível perda de dados (até 1 segundo), então você pode usar 0 ou 2 por sua conta e risco se as recompensas (velocidade de gravação mais rápida) valerem a pena.

Minha opinião difere da outra resposta.

Eu uso innodb_flush_log_at_trx_commit = 0apenas no meu computador de desenvolvimento ou mini banco de dados doméstico onde não há dados confidenciais.

Eu uso innodb_flush_log_at_trx_commit = 2se for banco de dados de blog/stats/e-commerce (com ~ 100x loja no dia), etc.

Eu uso innodb_flush_log_at_trx_commit = 1se você tem muitos clientes ou precisa trabalhar com transações de dinheiro como um banco. Então desta vez você deve dividir seu fluxo de dados entre vários servidores para ter velocidade e segurança.

Eu prefiro 2, porque tem uma velocidade de gravação muito mais rápida e falha APENAS se o hardware falhar.

Só pode decidir se você precisa de gravações rápidas ou consistência, integridade e durabilidade de dados garantidas.

O innodb_flush_log_at_trx_commité usado com o propósito de ..

Se o valor de innodb_flush_log_at_trx_commit for 0, o buffer de log é gravado no arquivo de log uma vez por segundo e a operação de liberação para disco é executada no arquivo de log, mas nada é feito em uma confirmação de transação.

Quando o valor é 1 (o padrão), o buffer de log é gravado no arquivo de log em cada confirmação de transação e a operação de liberação para disco é executada no arquivo de log.

Quando o valor é 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 arquivo de log ocorre uma vez por segundo também quando o valor é 2. Observe que a liberação uma vez por segundo não é 100% garantida para ocorrer a cada segundo, devido a problemas de agendamento do processo.

O valor padrão de 1 é necessário para total conformidade com ACID. Você pode obter um desempenho melhor definindo o valor diferente de 1, mas pode perder até um segundo de transações em uma falha. Com um valor de 0, qualquer falha do processo mysqld pode apagar o último segundo das transações. Com um valor de 2, apenas uma falha do sistema operacional ou uma queda de energia pode apagar o último segundo das transações. A recuperação de falhas do InnoDB funciona independentemente do valor.

Na minha opinião, usar innodb_flush_log_at_trx_commit2 não deve ser um problema. Mas usar 1 é o mais seguro.

Estou tentando responder, qual é o objetivo de innodb_flush_log_at_trx_commit?

O InnoDB executa a maioria de suas operações na memória ( InnoDB Buffer Pool). Todos os dados modificados são gravados InnoDB transaction log filee depois liberados (gravados) no armazenamento durável (disco rígido).

Para segurança dos dados ( Durability from ACID), o InnoDB precisa armazenar os dados modificados de cada transação em um armazenamento permanente. Ao mesmo tempo, confirmar no disco para cada transação é um processo caro.

A E/S do disco é um processo de bloqueio e é muito lento, se o disco estiver lento, reduzirá ainda mais o número de InnoDB transaction per seconds(taxa de transferência do disco).

O InnoDB fornece a innodb_flush_log_at_trx_commitvariável para controlar a frequência dessa operação de limpeza. Com base no valor, a operação de liberação do InnoDB se comporta de maneira diferente.

(Já explicado em outras respostas)

0 - Gravar no arquivo de log e liberar no disco a cada segundo (os dados estão no conjunto de buffers não gravados no arquivo de log - para ganho de desempenho). 1 - Liberar para o disco quando uma transação é confirmada - padrão (para segurança de dados - conformidade com ACID) 2 - gravar no arquivo de log para todas as transações e liberar para o disco a cada segundo. (Para ganho de desempenho)

Dependendo do requisito do aplicativo ( Performance Vs data safety), você pode definir essa variável. A diferença entre 0 e 2 - ambos aumentarão o desempenho, o valor 2 armazena os dados em arquivo de transação e pode ser recuperado, em caso de travamento ou falha, mas não em 0.

Em muitos casos, liberar para o disco significa que os dados são gravados do InnoDB buffer pool (memory) to Operating systems cache, não realmente gravados no disco de armazenamento (armazenamento permanente). Em caso de falha, na pior das hipóteses, você pode perder dados em até um segundo)

O ganho de desempenho depende do seu ambiente e você pode comparar e identificar. Em um ambiente de replicação, para segurança e consistência dos dados, defina innodb_flush_log_trx_commit = 1e sync_binlog=1.

Se o desempenho é o objetivo principal do aplicativo, o InnoDB fornece uma variável para controlar a frequência de liberação de log - innodb_flush_log_at_timeout- que permite definir a faixa de frequência de liberação de log de 1 to 2700 seconds, por padrão é 1.

Esteja ciente de que, quando você aumenta o intervalo de limpeza em até N segundos, o ganho de desempenho vem com o comprometimento da segurança dos dados em até N segundos. Por exemplo - se você definir que a descarga ocorre a cada 5 segundos - o ganho de taxa de transferência é muito alto, mas em caso de falha de energia ou falha do sistema, você perderá dados no valor de 5 segundos .

Este artigo discute sobre as operações de liberação e confirmação de transação do InnoDB .

Você pode alterar depois de fazer o modo 2 no aws rds:

Não modificável em alguns casos, como se você tiver replicação multi az:

Se o seu hardware falhar, você pode perder todos os seus dados, então eu uso param = 2 sem nenhuma preocupação. De qualquer forma, você pode dividir seus dados confidenciais (pedidos, dinheiro virtual,...) e regulares (estatísticas, carrinho,...) entre servidores de 2 db e mantê-los seguros e rápidos. Para transações entre bancos de dados, você pode usar http://dev.mysql.com/doc/refman/5.7/en/xa.html