Le Group Commit del binlog e innodb_flush_log_at_trx_commit
Note: This page describes features in an unreleased version of MariaDB.
Unreleased means there are no official packages or binaries available for download which contain the features. If you want to try out any of the new features described here you will need to get and compile the code yourself.
MariaDB starting with 10.0
MariaDB 10.0 introduce un miglioramento delle prestazioni dei group commit delle transazioni InnoDB/XtraDB quando il log binario è abilitato.
Quando sia --innodb-flush-log-at-trx-commit=1 (predefinito) sia il binlog sono abilitati, InnoDB esegue un sync su disco in meno durante il commit (un gruppo di transazioni condivide 2 sync invece di 3).
La persistenza dei commit non ne risente — questo perché, anche se il server va in crash prima che InnoDB scriva su disco il commit, questo verrà recuperato dal binlog al prossimo avvio del server (ed è garantito il fatto che venga eseguito il sync di tutte le informazioni necessarie perché il recupeto sia possibile in tutti i casi).
Il vecchio comportamento, con 3 sync sul disco per ogni (group) commit (che comportano performance inferiori), può essere selezionato tramite il nuovo valore --innodb-flush-log-at-trx-commit=3. Normalmente nessun beneficio deriva da questa scelta, tuttavia è bene essere consapevoli di un paio di casi limite:
- Se si usano
--flush-log-at-trx-commit=1e--log-binma--sync-binlog=0, non è garantita la persistenza dei commit in InnoDB/XtraDB dopo il commit. Il motivo è che gli eventi potrebbero sparire dal binlog a causa di un crash, quando--sync-binlog=0. In tal caso si può utilizzare--innodb-flush-log-at-trx-commit=3per rendere persistenti i commit in InnoDB/XtraDB. Tuttavia occorre ricordarsi che un crash potrebbe comunque causare la perdita dei commit nel binlog, creando un'incoerenza tra il log e InnoDB. Pertanto si raccomanda--sync-binlog=1. In MariaDB 5.3 e superiori, esso provoca un rallentamento molto meno accentuato rispetto alle vecchie versioni di MariaDB e MySQL. - XtraBackup vede solo i commit che sono stati inviati al redo log, perciò con la nuova ottimizzazione potrebbe esserci un piccolo ritardo (normalmente al massimo 1 secondo) tra il momento in cui avviene il commit e quello in cui il commit viene incluso in un XtraBackup. Si noti che XtraDB backup potrà ancora essere completamente coerente con se stesso e con il log binario. Normalmente questo ritardo non è un problema, perché un backup di solito impiega parecchi secondi e comprende tutte le transazioni che sono state inviate alla fine del backup: perciò quali commit siano inclusi o meno nel backup è abbastanza casuale. Viene menzionato qui solo per completezza.
