Il Logging Binario delle Stored Routine

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

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.

  • If binary logging is enabled, when a stored function is created, it must be declared as either DETERMINISTIC, NO SQL or READS SQL DATA, or else an error will occur.
  • MariaDB cannot check whether a function is deterministic, and relies on the correct definition being used.
  • To create or modify a stored function, a user requires the SUPER privilege as well as the regular privileges. See Stored Routine Privileges for these details.
  • The above conditions are not required if the server variable log_bin_trust_function_creators is set to 1 - by default it is set to 0.
  • Triggers work in the same way, except that they are always assumed to be deterministic for logging purposes, even if this is obviously not the case, such as when they use the UUID function.
  • Triggers can also update data. The slave uses the DEFINER attribute to determine which user is taken to have created the trigger.
  • Note that the above limitations do no apply to stored procedures or to events.

Examples

A deterministic function:

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

A non-deterministic function, since it uses the UUID_SHORT function:

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

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.