Stored Program Binary Logging 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. Triggers are similar to stored functions, so the preceding remarks regarding functions also apply to triggers with the following exception:  CREATE TRIGGER  does not have an optional  DETERMINISTIC  characteristic, so triggers are assumed to be always deterministic. However, this assumption might be invalid in some cases. For example, the  UUID()  function is nondeterministic (and does not replicate). Be careful about using such functions in triggers. Triggers can update tables, so error messages similar to those for stored functions occur with  CREATE TRIGGER  if you do not have the required privileges. On the replica side, the replica uses the trigger DEFINER  attribute to determine which user is considered to be the creator of the trigger. The rest of this section provides additional detail about the logging implementation and its implications. You need not read it unless you are interested in the background on the rationale for the current logging- related conditions on stored routine use. This discussion applies only for statement-based logging, and not for row-based logging, with the exception of the first item:  CREATE  and  DROP  statements are logged as statements regardless of the logging mode. When the  SELECT  statement executes, the function  f1()  is invoked three times. Two of those invocations insert a row, and MySQL logs a  SELECT  statement for each of them. That is, MySQL writes the following statements to the binary log: The server also logs a  SELECT  statement for a stored function invocation when the function invokes a stored procedure that causes an error. In this case, the server writes the  SELECT  statement to the log 4757 •The server writes  CREATE EVENT ,  CREATE PROCEDURE ,  CREATE FUNCTION ,  ALTER EVENT ,  ALTER PROCEDURE ,  ALTER FUNCTION ,  DROP EVENT ,  DROP PROCEDURE , and  DROP FUNCTION  statements to the binary log. •A stored function invocation is logged as a  SELECT  statement if the function changes data and occurs within a statement that would not otherwise be logged. This prevents nonreplication of data changes that result from use of stored functions in nonlogged statements. For example,  SELECT  statements are not written to the binary log, but a  SELECT  might invoke a stored function that makes changes. To handle this, a  SELECT  func_name ()  statement is written to the binary log when the given function makes a change. Suppose that the following statements are executed on the source server: •For information about built-in functions that may be unsafe for replication (and thus cause stored functions that use them to be unsafe as well), see Section 17.5.1, “Replication Features and Issues” . CREATE FUNCTION f1(a INT) RETURNS INT BEGIN IF (a < 3) THEN INSERT INTO t2 VALUES (a); END IF; RETURN 0; END; CREATE TABLE t1 (a INT); INSERT INTO t1 VALUES (1),(2),(3); SELECT f1(a) FROM t1; SELECT f1(1); SELECT f1(2);