当binlog记录存储程序（存储过程，存储函数，触发器，事件）的时候，可能存在一下问题：
statement复制模式下：
1、一条语句在master和slave上会影响不同的记录。
2、Slave端的SQL线程在执行statement的时候，具有所有的权限（不做权限检查）
可能某个存储过程在master和slave端执行效果不一致：
比如：


delimiter $$
create FUNCTION magic()
return char(64)
SQL SECURITY INVOKER
BEGIN
DECLARE result char(6);
If @@server_id <> 1 Then
select what into result from secret.agents limit 1;
return result;
else
return 'I am magic!';
end if;
end$$


类似这种情况的，如果不改变复制模式，可以考虑使用SQL SECURITY DEFINNER关键字来加强下防线。
3、存储程序所修改的数据是不确定的，这种情况是不利于复制的，可能引擎master和slave的不一致。

如果我们采用row模式进行复制，就不会出现上述问题，它只会记录受变化的表的行记录信息。
像存储过程 call 语句是不会被记录的，存储函数所产生的结果会被记录而不是调用函数的语句。对于触发器也是记录它所做的行记录的改变。

下面的这些 规则只适用于存储函数，不适用于其他存储程序
1、为了能创建和修改一个存储函数，必须拥有super 、create routine、alter routine权限。
2、创建的存储函数必须明确指出它所做的修改是 deterministic 或者它不会修改数据。
声明的时候需要有一下几个关键字：DETERMINISTIC ，NO SQL，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)


下面这个是可以的：


CREATE FUNCTION f1(i INT)
RETURNS INT
DETERMINISTIC
READS SQL DATA
BEGIN
RETURN i;
END;


下面这个使用UUID函数，所以是 not deterministic


CREATE FUNCTION f2()
RETURNS CHAR(36) CHARACTER SET utf8
BEGIN
RETURN UUID();
END;

 

一个函数的本质评估是基于“诚信”的创造者,MySQL 对于 书写了 deterministic的语句但是产生不确定的情况是不做检查的。

如果我们不使用 deterministric的话，我们必须使用row复制模式或者是mixed模式来保证主从复制的一致性。

默认情况下，只有super权限来定义存储函数，设置变量：log-bin-trust-function-creators 选项来 允许其他用户定义自己的function。

以上的这些讨论，同样适用于trigger，但trigger并没有deterministic关键字。