当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关键字。
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1071546，如需转载请自行联系原作者
