匿名通过本文主要向大家介绍了Mysql等相关知识,希望本文的分享对您有所帮助
MySQL 5.1存储程序和函数对复制起作用吗？
是的，在存储程序和函数中被执行标准行为被从主MySQL服务器复制到从服务器。有少数限制，它们在20.4节，“存储子程序和 触发程序二进制日志功能”中详述。
在主服务器上创建的存储程序和函数可以被复制到从服务器上么？
是的，通过一般DDL语句执行的存储程序和函数，其在主服务器上的创建被复制到从服务器，所以目标将存在两个服务器上。对存储程序和函数的ALTER 和DROP语句也被复制。
行为如何在已复制的存储程序和函数里发生？
MySQL纪录每个发生在存储程序和函数里的DML事件，并复制这些单独的行为到从服务器。执行存储程序和函数的切实调用不被复制。
对一起使用存储程序，函数和复制有什么特别的安全要求么？
是的，因为一个从服务器有权限来执行任何读自主服务器的二进制日志的语句，指定的安全约束因与复制一起使用的存储程序和函数而存在。如果复制或二进制日志大体上是激活的（为point-in-time恢复的目的），那么MySQL DBA 有两个安全选项可选：
任何想创建存储程序的用户必须被赋予SUPER权限。
作为选择，一个DBA可以设置log_bin_trust_routine_creators系统变量为1，它将会允许有标准CREATE ROUTINE权限的人来创建一个存储程序和函数。
对复制存储程序和函数的行为有什么限制？
嵌入到存储程序中的不确定（随机）或时基行不能适当地复制。随机产生的结果，仅因其本性，是你可预测的和不能被确实克隆的。因此，复制到从服务器的随机行为将不会镜像那些产生在主服务器上的。注意， 声明存储程序或函数为DETERMINISTIC或者在log_bin_trust_routine_creators中设置系统变量为0 将会允许随即值操作被调用。
此外，时基行为不能在从服务器上重新产生，因为在存储程序中通过对复制使用的二进制日志来计时这样的时基行为是不可重新产生的，因为该二进制日志仅纪录DML事件且不包括计时约束。
最后，在大型DML行为（如大批插入）中非交互表发生错误，该非交互表可能经历复制，在复制版的非交互表中主服务器可以被部分地从DML行为更新。但是因为发生的那个错误，对从服务器没有更新。 对函数的DML行为，工作区将被用IGNORE关键词来执行，以便于在主服务器上导致错误的更新被忽略，并且不会导致错误的更新被复制到从服务器。
上述的限制会影响MySQL作 point-in-time恢复的能力吗？
影响复制的同一限制会影响point-in-time恢复。
MySQL要做什么来改正前述的限制呢？
将来发行的MySQL预期有一个功能去选择复制该如何被处理：
基于语句的复制（当前实现）。
行级别复制（它将解决所有早先描述的限制）。
触发程序对复制起作用么？
MySQL 5.1中的触发程序和复制象在大多数其它数据库引擎中一样工作，在那些引擎中，通过触发程序在主服务器上执行的行为不被复制到从服务器。取而代之的是，位于主MySQL服务器的表中的 触发程序需要在那些存在于任何MySQL从服务器上的表内被创建，以便于触发程序可以也可以在从服务器上被激活。
一个行为如何通过从主服务器上复制到从服务器上的触发程序来执行呢？
首先，主服务器上的触发程序必须在从服务器上重建。一旦重建了，复制流程就象其它参与到复制中的标准DML语句一样工作。例如：考虑一个已经插入触发程序AFTER的EMP表，它位于主MySQL服务器上。同样的EMP表和AFTER插入 触发程序也存在于从服务器上。复制流程可能是：
1. 对EMP做一个INSERT语句。
2. EMP上的AFTER触发程序激活。
3. INSERT语句被写进二进制日志。
4. 从服务器上的复制拾起INSERT语句给EMP表，并在从服务器上执行它。
5. 位于从服务器EMP上的AFTER触发程序激活。
是的，在存储程序和函数中被执行标准行为被从主MySQL服务器复制到从服务器。有少数限制，它们在20.4节，“存储子程序和 触发程序二进制日志功能”中详述。
在主服务器上创建的存储程序和函数可以被复制到从服务器上么？
是的，通过一般DDL语句执行的存储程序和函数，其在主服务器上的创建被复制到从服务器，所以目标将存在两个服务器上。对存储程序和函数的ALTER 和DROP语句也被复制。
行为如何在已复制的存储程序和函数里发生？
MySQL纪录每个发生在存储程序和函数里的DML事件，并复制这些单独的行为到从服务器。执行存储程序和函数的切实调用不被复制。
对一起使用存储程序，函数和复制有什么特别的安全要求么？
是的，因为一个从服务器有权限来执行任何读自主服务器的二进制日志的语句，指定的安全约束因与复制一起使用的存储程序和函数而存在。如果复制或二进制日志大体上是激活的（为point-in-time恢复的目的），那么MySQL DBA 有两个安全选项可选：
任何想创建存储程序的用户必须被赋予SUPER权限。
作为选择，一个DBA可以设置log_bin_trust_routine_creators系统变量为1，它将会允许有标准CREATE ROUTINE权限的人来创建一个存储程序和函数。
对复制存储程序和函数的行为有什么限制？
嵌入到存储程序中的不确定（随机）或时基行不能适当地复制。随机产生的结果，仅因其本性，是你可预测的和不能被确实克隆的。因此，复制到从服务器的随机行为将不会镜像那些产生在主服务器上的。注意， 声明存储程序或函数为DETERMINISTIC或者在log_bin_trust_routine_creators中设置系统变量为0 将会允许随即值操作被调用。
此外，时基行为不能在从服务器上重新产生，因为在存储程序中通过对复制使用的二进制日志来计时这样的时基行为是不可重新产生的，因为该二进制日志仅纪录DML事件且不包括计时约束。
最后，在大型DML行为（如大批插入）中非交互表发生错误，该非交互表可能经历复制，在复制版的非交互表中主服务器可以被部分地从DML行为更新。但是因为发生的那个错误，对从服务器没有更新。 对函数的DML行为，工作区将被用IGNORE关键词来执行，以便于在主服务器上导致错误的更新被忽略，并且不会导致错误的更新被复制到从服务器。
上述的限制会影响MySQL作 point-in-time恢复的能力吗？
影响复制的同一限制会影响point-in-time恢复。
MySQL要做什么来改正前述的限制呢？
将来发行的MySQL预期有一个功能去选择复制该如何被处理：
基于语句的复制（当前实现）。
行级别复制（它将解决所有早先描述的限制）。
触发程序对复制起作用么？
MySQL 5.1中的触发程序和复制象在大多数其它数据库引擎中一样工作，在那些引擎中，通过触发程序在主服务器上执行的行为不被复制到从服务器。取而代之的是，位于主MySQL服务器的表中的 触发程序需要在那些存在于任何MySQL从服务器上的表内被创建，以便于触发程序可以也可以在从服务器上被激活。
一个行为如何通过从主服务器上复制到从服务器上的触发程序来执行呢？
首先，主服务器上的触发程序必须在从服务器上重建。一旦重建了，复制流程就象其它参与到复制中的标准DML语句一样工作。例如：考虑一个已经插入触发程序AFTER的EMP表，它位于主MySQL服务器上。同样的EMP表和AFTER插入 触发程序也存在于从服务器上。复制流程可能是：
1. 对EMP做一个INSERT语句。
2. EMP上的AFTER触发程序激活。
3. INSERT语句被写进二进制日志。
4. 从服务器上的复制拾起INSERT语句给EMP表，并在从服务器上执行它。
5. 位于从服务器EMP上的AFTER触发程序激活。