Il Logging Binario delle Stored Routine

Il log binario può essere row-based, statement-based o una combinazione dei due. Si veda I formati del Log Binario per ulteriori dettagli su questi formati. Se il logging è statement-based, è possibile che un'istruzione abbia effetti diversi sul master e sullo slave.

Le Stored Routine sono particolarmente soggette a questo problema, principalmente per due ragioni:

• Le Stored Routine possono essere non-deterministiche, quindi non ripetibili, e pertanto potrebbero avere risultati differenti ad ogni esecuzione.
• Il thread slave, eseguendo la Stored Routine sullo slave, ha tutti i privilegi possibili, mentre sul master potrebbe non essere così.

I problemi con la replica si verificano solo con il logging statement-based. Se si utilizza il formato row-based, siccome i cambiamenti rispecchiano quelli avvenuti nel master, non c'è possibilità che lo slave e il master si sfasino.

Come MariaDB gestisce il log binario statement-based delle Routine

Quanto segue si applica solo se si utilizza il formato statement-based e il Log Binario è abilitato. Se il Binary Log non è abilitato, o il formato è row-based o mixed, queste limitazioni non si applicano.

• Se il Log Binario è abilitato, quando si crea una Stored Function, occorre dichiararla come DETERMINISTIC, NO SQL o READS SQL DATA, altrimenti si avrà un errore.
• MariaDB cannot check whether a function is deterministic, and relies on the correct definition being used.
• Per creare o modificare una Stored Function, l'utente ha bisogno del prigilegio SUPER oltre ai normali diritti. Si veda I privilegi delle Stored Routine per ulteriori dettagli.
• Le condizioni sopra citate non sono necessarie se la variabile server log_bin_trust_function_creators è impostata a 1 - il valore predefinito è 0.
• I Trigger funzionano allo stesso modo, tranne per il fatto che sono sempre considerati deterministici per quanto riguarda il logging, anche quando non è così, per esempio perché usano la funzione UUID.
• I Trigger possono anche modificare i dati. Lo slave utilizza l'attributo DEFINER per determinare quale utente deve essere considerato il creatore del Trigger.
• Si noti che le limitazioni sopra elencate non si applicano alle Stored Procedures] e agli [[https:kb.askmonty.org/it/eventi/|Eventi.

Esempi

Questa è una funzione deterministica:

    CREATE FUNCTION fidati_di_me(x INT)
    RETURNS INT
    DETERMINISTIC
    READS SQL DATA
    BEGIN
      RETURN x;
    END;

Questa è una funzione non-deterministica, perché utilizza la funzione UUID_SHORT:

    CREATE FUNCTION non_fidarti_di_me()
    RETURNS INT
    BEGIN
      RETURN UUID_SHORT();
    END;