La base de replicación es que el maestro envía los eventos contenidos en su log binario a sus esclavos, que ejecuta estos eventos para hacer los mismos cambios de datos que se hacen en el maestro. Consulte Sección 6.2, “Panorámica de la implementación de la replicación”.

Ciertas operaciones de recuperación de datos necesitan usar el log binario. Tras hacer una restauración de un fichero de copia de seguridad, los eventos en el log binario que se guardaron tras hacer la copia de seguridad se re-ejecutan. Estos eventos actualizan la base de datos desde el punto de la copia de seguridad. Consulte Sección 5.8.2.2, “Usar copias de seguridad para una recuperación”.

Los comandos CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, y ALTER FUNCTION se escriben en el log binario, como lo son CALL, DROP PROCEDURE, y DROP FUNCTION.

Sin embargo, hay implicaciones de seguridad para replicación: para crear una rutina, un usuario debe tener el permiso CREATE ROUTINE , pero un usuario que tenga este permiso puede escribir una rutina para realizar cualquier acción en un servidor esclavo ya que el flujo SQL en el esclavo corre con todos los permisos. Por ejemplo, si el maestro y el esclavo tienen valores de ID del servidor de 1 y 2 respectivamente, un usuario en el maestro puede crear e invocar procedimientos como sigue:

mysql> delimiter //
mysql> CREATE PROCEDURE mysp ()
    -> BEGIN
    ->   IF @@server_id=2 THEN DROP DATABASE accounting; END IF;
    -> END;
    -> //
mysql> delimiter ;
mysql> CALL mysp();

Los comandos CREATE PROCEDURE y CALL se escriben en el log binario, así que los ejecutará el esclavo. Ya que el flujo SQL del esclavo tiene todos los permisos, borra la base de datos accounting .

Para evitar este peligro en servidores con logueo binario activado, MySQL 5.0.6 introduce el requerimiento que los creadores de procedimientos almacenados y funciones deben tener el permiso SUPER , además del permiso CREATE ROUTINE requerido. Similarmente, para usar ALTER PROCEDURE o ALTER FUNCTION, debe tener el permiso SUPER además del permiso ALTER ROUTINE . Sin el permiso SUPER ocurre un error:

ERROR 1419 (HY000): You do not have the SUPER privilege and
binary logging is enabled (you *might* want to use the less safe
log_bin_trust_routine_creators variable)

Puede no querer forzar el requerimiento en los creadores de rutinas que deben tener el permiso SUPER. Por ejemplo, todos los usuarios con el permiso CREATE ROUTINE en su sistema pueden ser desarrolladores de aplicaciones con experiencia. Para desactivar el requerimiento de SUPER, cambie la variable de sistema global log_bin_trust_routine_creators a 1. Por defecto, esta variable vale 0, pero puede cambiarla así:

mysql> SET GLOBAL log_bin_trust_routine_creators = 1;

Puede activar esta variable usando la opción --log-bin-trust-routine-creators al arrancar el servidor.

Si el logueo binario no está activado, log_bin_trust_routine_creators no se aplica y no se ncesita el permiso SUPER para creación de rutinas.

Una rutina no-determinista que realiza actualizaciones no es repetible, que puede tener dos efectos no deseables:

Para tratar estos problemas, MySQL fuerza los siguientes requerimientos: En un servidor maestro, la creación y alteración de una rutina se rehúsa a no ser que la rutina se declare como determinista o que no modifique datos. Esto significa que cuando crea una rutina, debe declarar que es determinista o que no cambia datos. Dos conjuntos de características de rutinas se aplica aquí:

Por defecto, para que un comando CREATE PROCEDURE o CREATE FUNCTION sea aceptado, DETERMINISTIC o NO SQL y READS SQL DATA deben especificarse explícitamente. De otro modo ocurre un error:

ERROR 1418 (HY000): This routine has none of DETERMINISTIC, NO SQL,
or READS SQL DATA in its declaration and binary logging is enabled
(you *might* want to use the less safe log_bin_trust_routine_creators
variable)

Si asigna a log_bin_trust_routine_creators 1, el requerimiento que la rutina sea determinista o que no modifique datos se elimina.

Tenga en cuenta que la naturaleza de una rutina se basa en la “honestidad” del creador: MySQL no comprueba que una rutina declarada DETERMINISTIC no contenga comandos que produzcan productos no deterministas.

Un comando CALL se escribe en el log binario si la rutina no retorna error, pero no en otro caso. Cuando una rutina que modifica datos falla, obtiene esta advertencia:

ERROR 1417 (HY000): A routine failed and has neither NO SQL nor
READS SQL DATA in its declaration and binary logging is enabled; if
non-transactional tables were updated, the binary log will miss their
changes

Este logueo del comportamiento tiene un potencial para causar problemas. Si una rutina modifica parcialmente una tabla no transaccional (tal como una tabla MyISAM ) y retorna un error, el log binario no refleja estos cambios. Para protegerse de esto, debe usar trablas transaccionales en la rutina y modificar las tablas dentro de transacciones.

Si usa la palabra clave IGNORE con INSERT, DELETE, o UPDATE para ignorar errores dentro de una rutina, una actualización parcial puede ocurrir sin producir error. Tales comandos se loguean y se replican normalmente.

Si una función almacenada se invoca dentro de un comando tal como SELECT que no modifica datos, la ejecución de la función no se escribe en el log binario, incluso si la función misma modifica datos. Este comportamiento de logueo tiene potencial para causar problemas. Suponga que una función myfunc() se define así:

CREATE FUNCTION myfunc () RETURNS INT
BEGIN
  INSERT INTO t (i) VALUES(1);
  RETURN 0;
END;

Dada esta definición, el comando siguiente modifica la tabla t porque myfunc() modifica t, pero el comando no se escribe en el log binario porque es un SELECT:

SELECT myfunc();

Una solución de este problema es invocar funciones que actualizan dentro de comandos que hacen actualizaciones. Tenga en cuenta que aunque el comando DO a veces se ejecuta como efecto colateral de evaluar una expresión, DO no es una solución aquí porque no está escrito en el log binario.

Los comandos ejecutados dentro de una rutina no se escriben en el log binario. Suponga que ejectua los siguientes comandos:

CREATE PROCEDURE mysp INSERT INTO t VALUES(1);
CALL mysp;

Para este ejemplo, los comandos CREATE PROCEDURE y CALL aparecerán en el log binario. El comando INSERT no aparecerá. Esto arregla el problema que ocurre antes de MySQL 5.0.6 en que los comandos CREATE PROCEDURE y CALL no se loguearon y INSERT se logueó.

En servidores esclavos, la siguiente limitación se aplica cuando se determina qué eventos del maestro se replican: reglas --replicate-*-table no se aplican a comandos CALL o a comandos dentro de rutinas: Las reglas en estos casos siempre retornan “replica!”