Oracle 5.0 Reference Manual page 1730

If you set
log_bin_trust_routine_creators
deterministic or not modify data is dropped.
• A statement is written to the binary log if the routine returns no error, but not otherwise. When
CALL
a routine that modifies data fails, you get this warning:
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
This logging behavior has the potential to cause problems. If a routine partly modifies a
nontransactional table (such as a
these changes. To protect against this, you should use transactional tables in the routine and modify
the tables within transactions.
If you use the
IGNORE
a partial update might occur but no error will result. Such statements are logged and they replicate
normally.
• Although statements normally are not written to the binary log if they are rolled back,
statements are logged even when they occur within a rolled-back transaction. This can result in a
being rolled back on the master but executed on slaves.
CALL
• If a stored function is invoked within a statement such as
execution of the function is not written to the binary log, even if the function itself modifies data. This
logging behavior has the potential to cause problems. Suppose that a function
as follows:
CREATE FUNCTION myfunc () RETURNS INT DETERMINISTIC
BEGIN
INSERT INTO t (i) VALUES(1);
RETURN 0;
END;
Given that definition, the following statement is not written to the binary log because it is a SELECT.
Nevertheless, it modifies the table
SELECT myfunc();
A workaround for this problem is to invoke functions that do updates only within statements that do
updates (and which therefore are written to the binary log). Note that although the
sometimes is executed for the side effect of evaluating an expression,
because it is not written to the binary log.
• On slave servers,
--replicate-*-table
within stored routines. These statements are always replicated. If such statements contain
references to tables that do not exist on the slave, they could have undesirable effects when
executed on the slave.
Routine logging changes in MySQL 5.0.12: The changes in 5.0.12 address several problems that
were present in earlier versions:
• Stored function invocations in nonlogged statements such as
when a function itself changed data.
• Stored procedure logging at the
procedure took different execution paths on the two machines.
• statements were logged even when they occurred within a rolled-back transaction.
CALL
To deal with these issues, MySQL 5.0.12 implements the following changes to procedure and function
logging:
Binary Logging of Stored Programs
table) and returns an error, the binary log will not reflect
MyISAM
keyword with INSERT, DELETE, or
because
t
rules do not apply to
level could cause different effects on a master and slave if a
CALL
1710
to 1, the requirement that routines be
to ignore errors within a routine,
UPDATE
that does not modify data,
SELECT
modifies t:
myfunc()
CALL
SELECT
CALL
is defined
myfunc()
statement
DO
is not a workaround here
DO
statements or to statements
were not being logged, even