Oracle 5.0 Reference Manual page 1728

be unsafe for data recovery or replication. To handle this, measures are implemented to enable
identification of safe routines and to prevent creation of unsafe routines except by users with
sufficient privileges.
• MySQL 5.0.12: For stored functions, when a function invocation that changes data occurs within
a nonlogged statement such as SELECT, the server logs a
invokes the function so that the function gets executed during data recovery or replication to slave
servers. For stored procedures, the server does not log
statements within a procedure that are executed as a result of a CALL. This eliminates problems that
may occur when a procedure would follow a different execution path on a slave than on the master.
• MySQL 5.0.16: The procedure logging changes made in 5.0.12 enable the conditions on unsafe
routines to be relaxed for stored procedures. Consequently, the user interface for controlling these
conditions is revised to apply only to functions. Procedure creators are no longer bound by them.
• MySQL 5.0.17: Logging of stored functions as
in 5.0.12) are logged as
checking.
Routine logging before MySQL 5.0.6: Statements that create and use stored routines are not written
to the binary log, but statements invoked within stored routines are logged. Suppose that you issue the
following statements:
CREATE PROCEDURE mysp INSERT INTO t VALUES(1);
CALL mysp();
For this example, only the
statements do not appear. The absence of routine-related statements in the binary log means
CALL
that stored routines are not replicated correctly. It also means that for a data recovery operation, re-
executing events in the binary log does not recover stored routines.
Routine logging changes in MySQL 5.0.6: To address the absence of logging for stored routine
creation and statements (and the consequent replication and data recovery concerns), the
CALL
characteristics of binary logging for stored routines were changed as described here. (Some of the
items in the following list point out issues that are dealt with in later versions.)
• The server writes
CREATE
PROCEDURE, and
FUNCTION, DROP
logs statements, not the statements executed within procedures. Suppose that you issue the
CALL
following statements:
CREATE PROCEDURE mysp INSERT INTO t VALUES(1);
CALL mysp();
For this example, the
statement does not appear. This corrects the problem that occurred before MySQL 5.0.6
INSERT
such that only the
INSERT
• Logging statements has a security implication for replication, which arises from two factors:
CALL
• Statements executed on a slave are processed by the slave SQL thread which has full privileges.
• It is possible for a procedure to follow different execution paths on master and slave servers.
The implication is that although a user must have the
routine, the user can write a routine containing a dangerous statement that will execute only on the
slave where it is processed by a thread that has full privileges. For example, if the master and slave
servers have server ID values of 1 and 2, respectively, a user on the master server could create and
invoke an unsafe procedure
mysql> delimiter //
mysql> CREATE PROCEDURE unsafe_sp ()
Binary Logging of Stored Programs
SELECT func_name()
statement appears in the binary log. The
INSERT
PROCEDURE, CREATE
DROP FUNCTION
and
CREATE PROCEDURE
was logged.
unsafe_sp()
1708
DO func_name()
statements. Instead, it logs individual
CALL
statements (per the changes made
DO func_name()
statements instead for better control over error
FUNCTION, ALTER
statements to the binary log. Also, the server
statements appear in the binary log, but the
CALL
CREATE ROUTINE
as follows:
statement that
CREATE PROCEDURE
PROCEDURE, ALTER
[576] privilege to create a
and