Ci sarà sempre un compromesso tra resilienza e prestazioni.
Con MySQL su ext4 le barriere = 1 di default causano effettivamente un rallentamento, tuttavia la prima azione non dovrebbe essere quella di disabilitare il journaling o attivare data = writeback.
In primo luogo, se la resilienza è di grande importanza, vale sicuramente la pena un RAID con batteria.
Le opzioni di montaggio che ho scelto, in particolare su RAID senza batteria, sono:
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
Questo non sta usando intenzionalmente data = writeback perché non voglio rischiare la corruzione del filesystem con conseguente "visualizzazione di vecchi dati nei file dopo un arresto anomalo e il ripristino del journal" (la citazione proviene da man mount).
La configurazione ideale in my.cnf per la piena resilienza attorno alle impostazioni relative agli I / O sono:
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
Ho optato per la seguente sequenza di compromessi per aumentare le prestazioni:
sync_binlog = 0: questa è la prima configurazione di MySQL che cambio lontano dalla piena resilienza. La ragione di ciò è che offre un significativo miglioramento delle prestazioni, soprattutto dove binlog_format=row(purtroppo richiesto per Jira). Sto usando abbastanza repliche MySQL nel cluster che se il binlog venisse danneggiato da uno scenario di perdita di potenza, farei una copia binaria da un'altra replica.innodb_flush_log_at_trx_commit = 2: Mentre è richiesto un valore 1 per la piena conformità ACID, con un valore di 2 "il buffer del registro viene scritto nel file ad ogni commit, ma l'operazione flush to disk non viene eseguita su di esso. Tuttavia, il flushing sul il 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. " (citazione dai documenti MySQL)- Aggiorna le opzioni di montaggio da utilizzare
data=writeback. Nota che se questo è il tuo filesystem di root dovrai anche passare un'opzione della riga di comando del kernel. Ho messo insieme alcuni passaggi su quello al coderwall .
- Prova vari valori di
innodb_flush_method. O_DIRECT ha dimostrato di migliorare le prestazioni in alcuni carichi di lavoro, ma non è un dato di fatto che funzionerà nel tuo ambiente.
- L'aggiornamento a SSD, nel qual caso si potrà anche aumentare
innodb_io_capacity, e regolare le impostazioni, come innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threads, e altre impostazioni possibili.