Oracle 5.0 Reference Manual page 1731

• A stored function invocation is logged as a
within a statement that would not otherwise be logged. This corrects the problem of nonreplication
of data changes that result from use of stored functions in nonlogged statements. For example,
statements are not written to the binary log, but a
SELECT
that makes changes. To handle this, a
the given function makes a change. Suppose that the following statements are executed on the
master:
CREATE FUNCTION f1(a INT) RETURNS INT
BEGIN
IF (a < 3) THEN
INSERT INTO t2 VALUES (a);
END IF;
RETURN 0;
END;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);
SELECT f1(a) FROM t1;
When the statement executes, the function
SELECT
invocations insert a row, and MySQL logs a
the following statements to the binary log:
DO f1(1);
DO f1(2);
The server also logs a
stored procedure that causes an error. In this case, the server writes the
along with the expected error code. On the slave, if the same error occurs, that is the expected result
and replication continues. Otherwise, replication stops.
Note: See later in this section for changes made in MySQL 5.0.19: These logged
statements are logged as
• Stored procedure calls are logged at the statement level rather than at the
server does not log the
execute. As a result, the same changes that occur on the master will be observed on slave servers.
This eliminates the problems that could result from a procedure having different execution paths on
different machines. For example, the
procedure does not occur and the routine is no longer replication-unsafe because it has the same
effect on master and slave servers.
In general, statements executed within a stored procedure are written to the binary log using the
same rules that would apply were the statements to be executed in standalone fashion. Some
special care is taken when logging procedure statements because statement execution within
procedures is not quite the same as in nonprocedure context:
• A statement to be logged might contain references to local procedure variables. These variables
do not exist outside of stored procedure context, so a statement that refers to such a variable
cannot be logged literally. Instead, each reference to a local variable is replaced by this construct
for logging purposes:
NAME_CONST(var_name, var_value)
is the local variable name, and
var_name
variable has at the time the statement is logged.
and a "name" of var_name. Thus, if you invoke this function directly, you get a result like this:
mysql> SELECT NAME_CONST('myname', 14);
+--------+
| myname |
+--------+
Binary Logging of Stored Programs
DO
DO func_name()
DO
statement for a stored function invocation when the function invokes a
DO
SELECT func_name()
statement, it logs those statements within the procedure that actually
CALL
DROP DATABASE
var_value
1711
statement if the function changes data and occurs
might invoke a stored function
SELECT
statement is written to the binary log when
is invoked three times. Two of those
f1()
statement for each of them. That is, MySQL writes
statements instead.
problem shown earlier for the
is a constant indicating the value that the
[967]
NAME_CONST()
statement to the log
DO
DO func_name()
level. That is, the
CALL
unsafe_sp()
has a value of var_value,