The Ultimate Guide to High Availability with MariaDB

I formati del Log Binario

Contents

  1. Formati
    1. Statement-based
    2. Row-based
    3. Mixed
  2. Impotare il formato del Log Binario
    1. Esempi
  3. Il database mysql

Formati

Il Log Binario ha tre formati - statement-based, row-based e mixed. Indipendentemente dal formato, i log sono sempre registrati in formato binario, non testuale, e pertanto non sono leggibili con un normale editor. Tuttavia MariaDB include mysqlbinlog, uno strumento da riga di comando per elaborare i file di log come testo.

Statement-based

E' il formato predefinito, il logging statement-based registra tutte le istruzioni SQL che apportano modifiche ai dati o alle strutture delle tabelle. Per abilitarlo: --binlog-format=STATEMENT.

In alcuni casi, un'istruzione può non essere deterministica, e quindi non essere sicura per la replica. Se MariaDB decide che è così, produce un warning Statement may not be safe to log in statement format. Si veda la sezione Mixed sotto, per una lista di casi in cui si applica questa regola.

Row-based

Registra gli eventi che coinvolgono le righe delle tabelle. Per abilitarlo: --binlog-format=ROW.

Mixed

Una combinazione del formato statement-based e quello row-based. Nel formato mixed, per default viene usato il logging statement-based, ma quando MariaDB determina che non è sicuro per la replica registrare una data istruzione in quel formato, utilizza il formato row-based. Per abilitarlo: --binlog-format=MIXED.

Il formato statement-based non è sicuro nei seguenti casi:

  • Istruzioni INSERT-DELAYED.
  • Quando una tabella con una colonna AUTO_INCREMENT viene aggiornata e vi è un trigger o si usa una Stored Function.
  • La funzione LOAD_FILE().
  • Vengono usate le funzioni ROW_COUNT() o FOUND_ROWS().
  • Vengono usate le funzioni USER() o CURRENT_USER().
  • Viene usata la funzione UUID().
  • Una delle tabelle usate nell'istruzione è un log che si trova nel database mysql.
  • Un'istruzione fa riferimento a una system variable (alcune costituiscono eccezione se usate solo nel contesto della sessione).
  • Viene usata una user-defined function.
  • Se si usa il formato row-based per un'istruzione, e la sessione che esegue quell'istruzione ha delle tabelle temporanee, il formato row-based verrà usato anche per le successive istruzioni, finché le tabelle temporanee non vengono eliminate. Questo perché le tabelle temporanee non possono usare il logging row-based , perciò se viene usato a causa di una delle condizioni sopra indicate, tutte le istruzioni seguenti su quella tabella non sono sicure. Il server gestisce questa situazione considerando tutte le istruzioni della sessione come non sicure per il logging statement-based finché non vengono eliminate le tabelle temporanee.

Anche uno Storage Engine può impostare o limitare il formato del logging, il che aiuta a ridurre gli errori quando si usa la replica tra diversi storage engines.

Impotare il formato del Log Binario

Il formato predefinito del Log Binario è statement-based. E' possibile cambiarlo con --binlog-format=formato, o modificando la variabile binlog_format a livello globale (se si ha il privilegio SUPER) o di sessione.

Occorre prestare attenzione al formato del Log Binario se si fa uso della replica. Il formato può essere impostato solo per il server stesso. Modificandolo sul master il cambiamento non si riflette sullo slave. Questo può far fallire la replica o dare risultati inattesi.

Raramente dovrebbe essere necessario modificare il formato del Log Binario, tuttavia può essere desiderabile nei casi seguenti:

  • Se una istruzione o poche istruzioni aggiornano molte righe, il formato statement-based è più efficiente. Siccome questa situazione è piuttosto comune, tale formato è quello predefinito.
  • Molte istruzioni che hanno un impatto limitato sulle righe delle tabelle potrebbero essere più efficienti con il logging row-based.
  • Un'istruzione potrebbe impiegare molto tempo, ma avere un impatto limitato sulle righe delle tabelle, pertanto la replica nel formato row-based sarebbe più efficiente.

Esempi

MariaDB [(none)]> SET GLOBAL binlog_format=ROW;

MariaDB [(none)]> SET SESSION binlog_format=MIXED;

MariaDB [(none)]> SET binlog_format=STATEMENT;

Il database mysql

Le istruzioni che coinvolgono il database mysql potrebbero essere registrate in un modo differente da come ci si aspetta.

Se il database mysql viene modificato direttamente, il logging viene eseguito come ci si aspetta, a seconda del formato_binlog. Tra le istruzioni che possono modificare direttamente il database mysql troviamo INSERT, UPDATE, DELETE, REPLACE, DO, LOAD DATA INFILE, SELECT e TRUNCATE TABLE.

Se il database mysql viene modificato indirettamente, viene eseguito il logging row-based senza tenere conto del formato_binlog. Tra le istruzioni che modificano indirettamente il database mysql troviamo GRANT, REVOKE, SET PASSWORD, RENAME USER, ALTER, DROP e CREATE (eccettuate le situazioni descritte sotto).

CREATE TABLE ... SELECT può causare una combinazione dei formati di log. La parte CREATE TABLE viene registrata nel formato statement-based, mentre la parte SELECT viene registrata secondo il valore di formato_binlog.

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.