É seguro usar innodb_flush_log_at_trx_commit = 2

Virei innodb_flush_log_at_trx_commit = 2e obtive uma velocidade de gravação muito rápida. Mas é seguro ser usado no site de produção?

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

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 em 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 transação confirmada 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 de uma vez por segundo não é 100% garantida para acontecer a cada segundo, devido a problemas de agendamento do processo.

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

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

Cuidado

Muitos sistemas operacionais e alguns hardwares de disco enganam a operação de liberação em disco. Eles podem dizer ao mysqld que o flush ocorreu, mesmo que não tenha ocorrido. Portanto, 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é danificar o banco de dados do InnoDB. O uso de um cache de disco com 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 Unix hdparm para desativar o armazenamento em cache de gravações de disco em caches de hardware ou usar algum outro comando específico para o fornecedor do hardware.

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

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

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

O valor 1 é a opção mais segura, pois, 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 (no valor de até 1 segundo), pode usar 0 ou 2 por sua conta e risco, se as recompensas (velocidade de gravação mais rápida) valerem a pena.

O innodb_flush_log_at_trx_commité usado com o objetivo de ..

Se o valor 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 transação confirmada 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 de uma vez por segundo não é 100% garantida para acontecer a cada segundo, devido a problemas de agendamento do processo.

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

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

Minha opinião difere de outra. innodb_flush_log_at_trx_commit = 0 se: é o meu computador de desenvolvimento ou o mini banco de dados doméstico, onde não há dados confidenciais.

innodb_flush_log_at_trx_commit = 2 se: for blog / stats / e-commerce (com ~ 100x lojas por dia), etc.

innodb_flush_log_at_trx_commit = 1 se: você tem muitos clientes ou precisa trabalhar com transações em dinheiro, como banco. dessa 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 ~ 75x mais rápida e falha apenas se o hardware falhar.

De qualquer forma, você deve saber o que precisa com muito mais velocidade de gravação ou informações de até 1 segundo?

Estou tentando responder, qual é o propósito 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 liberados (gravados) para armazenamento durável (disco rígido).

Para segurança dos dados ( Durability from ACID), o InnoDB precisa armazenar dados modificados de cada transação em um armazenamento permanente. Ao mesmo tempo, comprometer-se com o disco para cada transação é um processo dispendioso.

A E / S de disco é um processo de bloqueio e é muito lento, é um disco lento e reduz o número de InnoDB transaction per seconds(taxa de transferência de disco).

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

(Já explicado em outras respostas)

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

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

Em muitos casos, liberar no disco significa que os dados são gravados e InnoDB buffer pool (memory) to Operating systems cachenão 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 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 principal objetivo da aplicação, o InnoDB fornece uma variável para controlar a frequência da descarga de logs - innodb_flush_log_at_timeout- o que permite definir a faixa de frequência de descarga de logs 1 to 2700 seconds, por padrão é 1.

Esteja ciente de que, quando você aumenta o intervalo de liberação para até N segundos, o ganho de desempenho vem comprometendo a segurança dos dados em até N segundos. Por exemplo - se você definir a descarga a cada 5 segundos - o ganho da taxa de transferência será muito alto, mas em caso de falha de energia ou falha no 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 do modo 2 no aws rds:

Não modificável em alguns casos, como se você tiver replicação múltipla:

Se o seu hardware falhar, você poderá perder todos os seus dados, então eu uso o parâmetro = 2 sem preocupações. 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