The Ultimate Guide to High Availability with MariaDB

Il Group Commit di InnoDB e il Log Binario

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

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:

  • If using --flush-log-at-trx-commit=1 and --log-bin but --sync-binlog=0, then commits are not guaranteed durable inside InnoDB/XtraDB after commit. This is because events can be lost from the binlog in the event of a crash when --sync-binlog=0. In this case --innodb-flush-log-at-trx-commit=3 can be used to get durable commits in InnoDB/XtraDB. However, one should be aware that a crash is nevertheless likely to cause commits to be lost in the binlog, leaving the binlog and InnoDB inconsistent with each other. Thus --sync-binlog=1 is recommended. It has much less penalty in MariaDB 5.3 and later compared to older versions of MariaDB and MySQL.
  • XtraBackup only sees commits that have been flushed to the redo log, so with the new optimization there may be a small delay (normally at most 1 second) between when a commit happens and when the commit will be included in an XtraBackup. Note that the XtraDB backup will still be fully consistent with itself and the binlog. This is normally not an issue, as a backup usually takes many seconds, and includes all transactions committed up to the end of the backup, so it will be rather random anyway exactly which commit is or is not included in the backup. It is just mentioned here for completeness.

Commenti

Sto caricando i commenti......
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.