USER()  and CURRENT_USER()  are automatically replicated using row-based replication when using MIXED  mode, and generate a warning in STATEMENT  mode. (See also Section 17.5.1.8, “Replication of CURRENT_USER()” .) This is also true for VERSION()  and RAND() . 

•For NOW() , the binary log includes the timestamp. This means that the value as returned by the call to this function on the source  is replicated to the replica. To avoid unexpected results when replicating between MySQL servers in different time zones, set the time zone on both source and replica. For more information, see Section 17.5.1.33, “Replication and Time Zones” . 

To explain the potential problems when replicating between servers which are in different time zones, suppose that the source is located in New York, the replica is located in Stockholm, and both servers are using local time. Suppose further that, on the source, you create a table mytable , perform an INSERT statement on this table, and then select from the table, as shown here: 

mysql> CREATE TABLE mytable (mycol TEXT); Query OK, 0 rows affected (0.06 sec) mysql> INSERT INTO mytable VALUES ( NOW() ); Query OK, 1 row affected (0.00 sec) mysql> SELECT * FROM mytable; +---------------------+ | mycol | +---------------------+ | 2009-09-01 12:00:00 | +---------------------+ 1 row in set (0.00 sec) 

Local time in Stockholm is 6 hours later than in New York; so, if you issue SELECT NOW()  on the replica at that exact same instant, the value 2009-09-01 18:00:00  is returned. For this reason, if you select from the replica’s copy of mytable  after the CREATE TABLE  and INSERT  statements just shown have been replicated, you might expect mycol  to contain the value 2009-09-01 18:00:00 . However, this is not the case; when you select from the replica’s copy of mytable , you obtain exactly the same result as on the source: 

mysql> SELECT * FROM mytable; +---------------------+ | mycol | +---------------------+ | 2009-09-01 12:00:00 | +---------------------+ 1 row in set (0.00 sec) 

Unlike NOW() , the SYSDATE()  function is not replication-safe because it is not affected by SET TIMESTAMP  statements in the binary log and is nondeterministic if statement-based logging is used. This is not a problem if row-based logging is used. 

An alternative is to use the --sysdate-is-now  option to cause SYSDATE()  to be an alias for NOW() . This must be done on the source and the replica to work correctly. In such cases, a warning is still issued by this function, but can safely be ignored as long as --sysdate-is-now  is used on both the source and the replica. 

SYSDATE()  is automatically replicated using row-based replication when using MIXED  mode, and generates a warning in STATEMENT  mode. 

See also Section 17.5.1.33, “Replication and Time Zones” . 

• The following restriction applies to statement-based replication only, not to row-based replication.  The GET_LOCK() , RELEASE_LOCK() , IS_FREE_LOCK() , and IS_USED_LOCK()  functions that handle 

