MySQL 8.0 FAQ: Triggers MySQL records each DML event that occurs in a stored procedure and replicates those individual actions to a replica. The actual calls made to execute stored procedures are not replicated. Stored functions that change data are logged as function invocations, not as the DML events that occur inside each function. Yes. Because a replica has authority to execute any statement read from a source’s binary log, special security constraints exist for using stored functions with replication. If replication or binary logging in general (for the purpose of point-in-time recovery) is active, then MySQL DBAs have two security options open to them: Nondeterministic (random) or time-based actions embedded in stored procedures may not replicate properly. By their very nature, randomly produced results are not predictable and cannot be exactly reproduced; therefore, random actions replicated to a replica do not mirror those performed on a source. Declaring stored functions to be  DETERMINISTIC  or setting the log_bin_trust_function_creators  system variable to 0 keeps random operations producing random values from being invoked. In addition, time-based actions cannot be reproduced on a replica because the timing of such actions in a stored procedure is not reproducible through the binary log used for replication. It records only DML events and does not factor in timing constraints. Finally, nontransactional tables for which errors occur during large DML actions (such as bulk inserts) may experience replication issues in that a source may be partially updated from DML activity, but no updates are done to the replica because of the errors that occurred. A workaround is for a function’s DML actions to be carried out with the  IGNORE  keyword so that updates on the source that cause errors are ignored and updates that do not cause errors are replicated to the replica. The same limitations that affect replication do affect point-in-time recovery. You can choose either statement-based replication or row-based replication. The original replication implementation is based on statement-based binary logging. Row-based binary logging resolves the limitations mentioned earlier. Mixed  replication is also available (by starting the server with  --binlog-format=mixed ). This hybrid form of replication “knows”  whether statement-level replication can safely be used, or row- level replication is required. For additional information, see Section 17.2.1, “Replication Formats” . A.5.1 Where can I find the documentation for MySQL 8.0 triggers? ................................................. 5239 A.5 MySQL 8.0 FAQ: Triggers A.4.25. Are there special security requirements for using stored procedures and functions together with replication? 1. Any user wishing to create stored functions must be granted the  SUPER  privilege. 2. Alternatively, a DBA can set the  log_bin_trust_function_creators  system variable to 1, which enables anyone with the standard  CREATE ROUTINE  privilege to create stored functions. 5238 A.4.26. What limitations exist for replicating stored procedure and function actions? A.4.27. Do the preceding limitations affect the ability of MySQL to do point-in-time recovery? A.4.28. What is being done to correct the aforementioned limitations?