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觸發程序激活。
