MySQL 5.6 主从复制如何处理触发器,函数,存储过程,调度事件_MySQL

截图来自MySQL5.6的pdf版文档。

说明：

1）基于语句的复制时，trigger会在slave上执行，所以slave上也需要有trigger的定义，不然会导致主从数据不一致的；

2）基于行的复制时，trigger不会在slave上执行。因为复制的数据，不是sql语句。

截图来自MySQL5.6的pdf版文档。

说明：

基于行的复制时，存储过程，函数，触发器都只在master上执行，然后将执行之后的数据传给 slave 。不会将它们的sql语句发给slave. slave上看到的只有修改的行数据，不会有 存储过程、函数、触发器的调用语句。

截图来自MySQL5.6的pdf版文档。

说明：

说的基本和第一幅截图一样。

基于语句的复制，trigger会在master和slave上都执行。

基于行的复制，trigger只会在master上执行，然后将数据行传给slave. 因为如果基于行的复制，salve上也执行trigger的话，会导致执行两次，导致主从数据不一致。

截图来自MySQL5.6的pdf版文档。

说明：

1）对于存储过程，如果不是 确定性的，或者该存储过程不对数据进行修改，那么它就会导致在复制时，主从数据的不一致。这里指基于statement的复制。对于基于row的复制，不会导致主从不一致。

2. trigger 的局限：

carete trigger 语法：

Syntax:
CREATE
[DEFINER = { user | CURRENT_USER }]
TRIGGER trigger_name
trigger_time trigger_event
ON tbl_name FOR EACH ROW
trigger_body

trigger_time: { BEFORE | AFTER }

trigger_event: { INSERT | UPDATE | DELETE }

1）trigger 只能在表中的数据进行： insert, update, delete 时进行某种处理，也就是说他不能对表上的 DDL 语句进行某种处理！！！！

2）MySQL triggers activate only for changes made to tables by SQL statements. They do not activate for changes in views, nor by changes to tables made by APIs that do not transmit SQL statements to the MySQL Server. 通过视图修改和通过API修改的表的数据时，不会触发trigger

---------------------------------------- 分割线 ------------------------------------------------

下面的内容转自：http://www.linuxidc.com/Linux/2012-06/63141.htm

MySQL5.5 主从复制 （触发器,函数,存储引擎,事件处理）说明

mysql5.5 对触发器,函数,存储引擎,事件进行主从复制情况.

一、MySQL主从复制有三种模式.

1.binlog_format = row : 日志中会记录成每一行数据被修改的形式(记录页面)，然后在 slave 端再对相同的数据进行修改。

2.binlog_format = statement : 每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。

3.binlog_format = mixed : 这个模式是在5.1.8版本之后, 才有的. mixed是row和statement的混合模式.

二、触发器的主从复制.

A .当binlog_format = statement 或 binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况

1. 主从复制的时候,主从触发器都受到definer从句的约束.只有主从上都有这个用户才能正常运行这个触发器.

2. 主服务器上SQL语句传到从服务器上,从服务器再执行SQL语句去触发从服务器的触发器(这里要说明是:主服务器不会把触发后的SQL传递给从服务器).

这里可以看到,传递是原始的SQL语句.

B .当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况

1. 主服务器把被修改的页面复制给从服务器,并且这个修改的页面的值是触发后的改变值.

2. 因为这个页面的值是触发后改变的值, 所以在从服务器上可以不需要这个触发器.

3. 删除从服务器上的触发器.一样的可以得到跟主服务器一样的值.

三、存储过程的主从复制

1. 主服务器上的存储过程同样收到definer从句的约束.但是,在复制的时候,从服务上不需要有存储过程

A. 当binlog_format = statement 或binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况

可以看到通过系统函数转换后的值复制给从服务器，不需要在从服务器上建立。(注：其实这里是错误的！和文档中的明显不一致，参见最后的总结。)

B .当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况(传的都是数据)

四、函数主从复制

A . 当binlog_format = statement 或binlog_format = mixed (使用混合模式用的是statement 方式) 这种模式下复制情况

1. 主从复制的时候,主从触发器都受到definer从句的约束.只有主从上都有这个用户才能正常运行这个函数

2. 主服务器上SQL语句复制从服务器上,从服务器再执行SQL语句再去调用从服务器的函数（主服务器不会把函数的返回值传给从服务器的）

B. 当binlog_format = row 或 binlog_format = mixed(使用混合模式用的是row方式) 这种模式下复制情况(传的都是数据)

1.主服务器会直接把修改过的页面复制给从服务器,从服务器不需要有对应的函数

五、事件主从复制

当事件有用函数,触发器,存储过程时.跟上面的操作情况是一样的.

但有一点不同的是.

在主服务器上建立一个event,当然,在从服务器上也会创建一个event..（默认情况下主event复制到从服务器的event是关闭着的)

1.主服务器上的event

2.从服务器上的event

如果在从服务器,开启事件.不仅主服务器复制过来的SQL语句执行一遍,从服务器上的EVENT也会执行.

===============分割线=============

总结：

MySQL5.6文档的说明和上面转帖的博文，说的是不太相符的。不相符的地方在 存储过程的说明上。我们还是应该以文档为准。博文毕竟良莠不齐。

在基于row的复制时：

不管是 存储过程，函数，还是触发器，都是将 执行之后的数据行，传给slave。slave上看到的都是数据，不会有它们的调用语句。slave上可以没有它们的定义。

在基于statement 的复制时：

1）存储过程、函数、触发器 都会在slave上执行。所以基于statement复制时，slave也必须有它们的定义。而且存储过程、函数必须是确定性的或者它们不修改表的数据。不然就会导致基于statement的复制，主从数据不一致。

2）存储过程和函数在定义时，有 确定性函数和非确定性函数的分别；比如 uuid(),md5()这些函数肯定都是非确定性函数，因为它们每次执行的值是不确定的。所以在master和slave上分别执行会导致数据不一致。所以在基于语句复制的环境中，函数都必须是 确定性的(DETERMINISTIC)。不然就只能采用row复制格式了。

3）在基于statement复制时，trigger中定义的sql语句在执行时，不会传给slave，而仅仅传调用trigger的语句本身。所以不会导致定义在trigger中的sql执行两次。也就是说不会既将调用trigger的语句传给slave，又将在trigger执行时，在trigger中运行的那些sql语句传给slave. 因为这样会导致那些 sql 执行两次。

4）上面存储过程、函数、触发器在复制时的区别，也说明了，基于row格式的复制要优于基于statement格式的复制，基于row的复制明显要健壮很多。

同时也说明：触发器、存储过程能不用最好就不要用了。

5）最后，虽然有文档的说明，实际使用时最好先通过自己的测试，来确认一下，到底 存储过程、函数、触发器是在基于statement的复制中是如何处理的。

基于row的复制，很定是没有问题的。最好是采用基于row的复制，最好不用触发器，存储过程，非确定性函数。