Stored Program Binary Logging along with the expected error code. On the replica, if the same error occurs, that is the expected result and replication continues. Otherwise, replication stops. The implication is that although a user must have the  CREATE ROUTINE  privilege to create a function, the user can write a function containing a dangerous statement that executes only on the replica where it is processed by a thread that has full privileges. For example, if the source and replica servers have server ID values of 1 and 2, respectively, a user on the source server could create and invoke an unsafe function  unsafe_func()  as follows: The  CREATE FUNCTION  and  INSERT  statements are written to the binary log, so the replica executes them. Because the replica’s applier thread has full privileges, it executes the dangerous statement. Thus, the function invocation has different effects on the source and replica and is not replication-safe. To guard against this danger for servers that have binary logging enabled, stored function creators must have the  SUPER  privilege, in addition to the usual  CREATE ROUTINE  privilege that is required. Similarly, to use  ALTER FUNCTION , you must have the  SUPER  privilege in addition to the  ALTER ROUTINE privilege. Without the  SUPER  privilege, an error occurs: If you do not want to require function creators to have the  SUPER  privilege (for example, if all users with the  CREATE ROUTINE  privilege on your system are experienced application developers), set the global log_bin_trust_function_creators  system variable to 1. You can also set this variable at server startup. If binary logging is not enabled,  log_bin_trust_function_creators  does not apply. SUPER  is not required for function creation unless, as described previously, the  DEFINER  value in the function definition requires it. 4758 •Restored data does not match the original data. •It causes a replica to differ from the source. •If a function that performs updates is nondeterministic, it is not repeatable. This can have two undesirable effects: •The use of replication privilege checks where available (from MySQL 8.0.18) is recommended whatever choice you make about privileges for function creators. Replication privilege checks can be set up to ensure that only expected and relevant operations are authorized for the replication channel. For instructions to do this, see Section 17.3.3, “Replication Privilege Checks” . ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) mysql>  delimiter // mysql>  CREATE FUNCTION unsafe_func () RETURNS INT ->  BEGIN -> IF @@server_id=2 THEN  dangerous_statement ; END IF; -> RETURN 1; ->  END; ->  // mysql>  delimiter ; mysql>  INSERT INTO t VALUES(unsafe_func()); •Statements executed on a replica are processed by the replica’s applier thread. Unless you implement replication privilege checks, which are available from MySQL 8.0.18 (see Section 17.3.3, “Replication Privilege Checks” ), the applier thread has full privileges. •It is possible for a function to follow different execution paths on source and replica servers. •Logging stored function invocations rather than the statements executed by a function has a security implication for replication, which arises from two factors: