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觸發程式啟動。