Oracle 5.0 Reference Manual page 1726

However, there are certain binary logging issues that apply with respect to stored programs (stored
procedures and functions, and triggers):
• Logging occurs at the statement level. In some cases, it is possible that a statement will affect
different sets of rows on a master and a slave.
• Replicated 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, so a 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.
• If a stored program that modifies data is nondeterministic, it is not repeatable. This can result in
different data on a master and slave, or cause restored data to differ from the original data.
This section describes how MySQL 5.0 handles binary logging for stored programs. The discussion first
states the current conditions that the implementation places on the use of stored programs, and what
you can do to avoid problems. Then it summarizes the changes that have taken place in the logging
implementation. Finally, implementation details are given that provide information about when and why
various changes were made. These details show how several aspects of the current logging behavior
were implemented in response to shortcomings identified in earlier versions of MySQL.
In general, the issues described here occur due to the fact that binary logging occurs at the SQL
statement level. MySQL 5.1 implements row-level binary logging, which solves or alleviates these
issues because the log contains changes made to individual rows as a result of executing SQL
statements.
Unless noted otherwise, the remarks here assume that you have enabled binary logging by starting the
server with the
--log-bin
enabled, replication is not possible, nor is the binary log available for data recovery.
The current conditions on the use of stored functions in MySQL 5.0 can be summarized as follows.
These conditions do not apply to stored procedures and they do not apply unless binary logging is
enabled.
• To create or alter a stored function, you must have the
[576]
CREATE ROUTINE
the value in the function definition,
DEFINER
binary logging is enabled. See
Syntax".)
• When you create a stored function, you must declare either that it is deterministic or that it does not
modify data. Otherwise, it may be unsafe for data recovery or replication.
By default, for a
CREATE FUNCTION
SQL, or
READS SQL DATA
ERROR 1418 (HY000): This function 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_function_creators
variable)
This function is deterministic (and does not modify data), so it is safe:
CREATE FUNCTION f1(i INT)
RETURNS INT
DETERMINISTIC
READS SQL DATA
BEGIN
RETURN i;
END;
This function uses
UUID()
and is not safe:
Binary Logging of Stored Programs
[1467] option. (See Section 5.2.3, "The Binary
or [576]
ALTER ROUTINE
SUPER
Section 13.1.9, "CREATE PROCEDURE
statement to be accepted, at least one of DETERMINISTIC,
must be specified explicitly. Otherwise an error occurs:
[967], which is not deterministic, so the function also is not deterministic
1706
Log".) If the binary log is not
[578] privilege, in addition to the
SUPER
privilege that is normally required. (Depending on
[578] might be required regardless of whether
and
CREATE FUNCTION
NO