È sicuro usare innodb_flush_log_at_trx_commit = 2

Mi voltai innodb_flush_log_at_trx_commit = 2e ottengo una velocità di scrittura molto elevata. Ma è sicuro da usare nel sito di produzione?

Puoi perdere fino a un secondo di transazioni. Il valore predefinito è 1, che aiuta a mantenere InnoDB ACID conforme .

Secondo la documentazione MySQL su innodb_flush_log_at_trx_commit

Se il valore di innodb_flush_log_at_trx_commit è 0, il buffer di registro viene scritto nel file di registro una volta al secondo e l'operazione di scaricamento su disco viene eseguita sul file di registro, ma nulla viene eseguito durante un commit della transazione. Quando il valore è 1 (impostazione predefinita), il buffer del registro viene scritto nel file di registro ad ogni commit della transazione e l'operazione di scaricamento su disco viene eseguita sul file di registro. Quando il valore è 2, il buffer di registro viene scritto nel file ad ogni commit, ma l'operazione di scaricamento su disco non viene eseguita su di esso. Tuttavia, il flushing sul file di registro ha luogo una volta al secondo anche quando il valore è 2. Notare che il flushing una volta al secondo non è garantito al 100% ogni secondo, a causa di problemi di pianificazione del processo.

Il valore predefinito 1 è richiesto per la piena conformità ACID. È possibile ottenere prestazioni migliori impostando un valore diverso da 1, ma in tal caso è possibile perdere fino a un secondo delle transazioni in caso di arresto anomalo. Con un valore pari a 0, qualsiasi arresto anomalo del processo mysqld può cancellare l'ultimo secondo delle transazioni. Con un valore di 2, solo un arresto anomalo del sistema operativo o un'interruzione dell'alimentazione possono cancellare l'ultimo secondo delle transazioni. Il recupero da crash di InnoDB funziona indipendentemente dal valore.

Per la massima durata e coerenza possibili in un'impostazione di replica utilizzando InnoDB con le transazioni, utilizzare innodb_flush_log_at_trx_commit = 1 e sync_binlog = 1 nel file my.cnf del server master.

Attenzione

Molti sistemi operativi e alcuni componenti hardware del disco ingannano l'operazione flush-to-disk. Potrebbero dire a mysqld che il flush ha avuto luogo, anche se non lo è stato. Quindi la durata delle transazioni non è garantita nemmeno con l'impostazione 1 e, nel peggiore dei casi, un'interruzione dell'alimentazione può persino danneggiare il database InnoDB. L'uso di una cache del disco con batteria tampone nel controller del disco SCSI o nel disco stesso accelera lo scaricamento dei file e rende l'operazione più sicura. Puoi anche provare a utilizzare il comando Unix hdparm per disabilitare la memorizzazione nella cache delle scritture su disco nelle cache dell'hardware o utilizzare altri comandi specifici per il fornitore dell'hardware.

Sulla base di ciò, valori diversi da 1 mettono InnoDB a rischio di perdere il valore delle transazioni di 1 secondo o il valore dei dati di un impegno di transazione.

La documentazione dice anche l'uso sync_binlog=1.

Secondo la documentazione MySQL su sync_binlog

Il valore 1 è la scelta più sicura perché in caso di crash si perde al massimo un'istruzione o transazione dal registro binario. Tuttavia, è anche la scelta più lenta (a meno che il disco non abbia una cache con batteria, il che rende la sincronizzazione molto veloce).

La tua scelta più sicura è

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Se non ti dispiace la possibile perdita di dati (fino a 1 secondo), puoi usare 0 o 2 a tuo rischio e pericolo se ne valgono le ricompense (maggiore velocità di scrittura).

Il innodb_flush_log_at_trx_commitviene utilizzato con lo scopo, come ..

Se il valore di innodb_flush_log_at_trx_commit è 0, il buffer di registro viene scritto nel file di registro una volta al secondo e l'operazione di scaricamento su disco viene eseguita sul file di registro, ma nulla viene eseguito durante un commit della transazione.

Quando il valore è 1 (impostazione predefinita), il buffer del registro viene scritto nel file di registro ad ogni commit della transazione e l'operazione di scarico su disco viene eseguita sul file di registro.

Quando il valore è 2, il buffer di registro viene scritto nel file ad ogni commit, ma l'operazione di scaricamento su disco non viene eseguita su di esso. Tuttavia, il flushing sul file di registro ha luogo una volta al secondo anche quando il valore è 2. Notare che il flushing una volta al secondo non è garantito al 100% ogni secondo, a causa di problemi di pianificazione del processo.

Il valore predefinito 1 è richiesto per la piena conformità ACID. È possibile ottenere prestazioni migliori impostando un valore diverso da 1, ma in tal caso è possibile perdere fino a un secondo delle transazioni in caso di arresto anomalo. Con un valore pari a 0, qualsiasi arresto anomalo del processo mysqld può cancellare l'ultimo secondo delle transazioni. Con un valore di 2, solo un arresto anomalo del sistema operativo o un'interruzione dell'alimentazione possono cancellare l'ultimo secondo delle transazioni. Il recupero da crash di InnoDB funziona indipendentemente dal valore.

Secondo me l'uso innodb_flush_log_at_trx_commitdi 2 non dovrebbe essere un problema, ma usare 1 è il più sicuro.

La mia opinione differisce dalle altre. innodb_flush_log_at_trx_commit = 0 if: è il mio computer di sviluppo o mini database di casa in cui non ci sono dati sensibili.

innodb_flush_log_at_trx_commit = 2 se: è blog / stats / e-commerce (con ~ 100x shop in day), ecc.

innodb_flush_log_at_trx_commit = 1 se: hai molti clienti o devi lavorare con transazioni di denaro come la banca. quindi questa volta dovresti dividere il flusso di dati tra più server per avere velocità e sicurezza.

Preferisco 2, perché ha una velocità di scrittura circa 75 volte più veloce e fallisce SOLO se l'hardware non funziona.

Ad ogni modo dovresti sapere di cosa hai bisogno molto più velocità di scrittura o informazioni fino a 1 secondo?

Sto cercando di rispondere, qual è lo scopo innodb_flush_log_at_trx_commit?

InnoDB esegue la maggior parte delle sue operazioni in memoria ( InnoDB Buffer Pool). Tutti i dati modificati vengono scritti InnoDB transaction log filee quindi scaricati (scritti) su una memoria durevole (disco rigido).

Per la sicurezza dei dati ( Durability from ACID), InnoDB deve archiviare i dati modificati di ogni transazione in una memoria permanente. Allo stesso tempo, impegnarsi su disco per ogni transazione è un processo costoso.

L'I / O su disco è un processo di blocco ed è molto lento, è un disco lento, inoltre ridurrà il numero di InnoDB transaction per seconds(throughput del disco).

InnoDB fornisce, innodb_flush_log_at_trx_commitvariabile per controllare la frequenza di questa operazione di lavaggio. In base al valore, l'operazione di flush di InnoDB si comporta diversamente.

(Già spiegato in altre risposte)

0 - Scrive sul file di registro e scarica su disco ogni secondo (i dati si trovano nel pool di buffer non scritti nel file di registro - per un miglioramento delle prestazioni). 1 - Svuota su disco al momento del commit di una transazione - impostazione predefinita (per la sicurezza dei dati - conformità ACID) 2 - scrive nel file di registro per ogni transazione e scarica su disco al secondo. (Per guadagno prestazionale)

Dipende dal requisito dell'applicazione ( Performance Vs data safety), è possibile impostare questa variabile. La differenza tra 0 e 2 - entrambi aumenteranno le prestazioni, il valore 2 memorizza i dati nel file di transazione e può essere recuperato, in caso di crash o fallimento, ma non in 0.

In molti casi, flush on disk è il mezzo, i dati vengono scritti da InnoDB buffer pool (memory) to Operating systems cachenon effettivamente scritti sul disco di archiviazione (memoria permanente). In caso di errore, nel peggiore dei casi, è possibile perdere i dati fino a un secondo)

Il guadagno in termini di prestazioni dipende dall'ambiente ed è possibile eseguire il benchmark e l'identificazione. In un ambiente di replica, per sicurezza e coerenza dei dati, impostare innodb_flush_log_trx_commit = 1e sync_binlog=1.

Se le prestazioni sono l'obiettivo principale dell'applicazione, InnoDB fornisce una variabile per controllare la frequenza di lavaggio del registro - innodb_flush_log_at_timeout- che consente di impostare la gamma di frequenza di lavaggio del registro da 1 to 2700 seconds, per impostazione predefinita è 1.

Tenere presente che quando si aumenta l'intervallo di risciacquo fino a N secondi, il guadagno in termini di prestazioni comporta un compromesso nella sicurezza dei dati fino a N secondi. Ad esempio, se si imposta il flushing ogni 5 secondi, il guadagno del throughput è molto elevato, ma in caso di mancanza di corrente o crash del sistema, si perderanno i dati per 5 secondi.

In questo articolo vengono descritte le operazioni di flushing di InnoDB e le operazioni di commit delle transazioni .

Puoi cambiare dopo aver eseguito la modalità 2 su aws rds:

Non modificabile in alcuni casi come se si dispone di replica multi az:

Se il tuo hardware non funziona, puoi perdere tutti i tuoi dati, quindi uso param = 2 senza preoccupazioni. Ad ogni modo puoi dividere i tuoi dati sensibili (ordine, denaro virtuale, ...) e regolari (statistiche, carrello, ...) tra server 2 db e tenerli sicuri e veloci. Per le transazioni tra database è possibile utilizzare http://dev.mysql.com/doc/refman/5.7/en/xa.html