Функции USER(), CURRENT_USER() (или CURRENT_USER), UUID(), VERSION() и LOAD_FILE() реплицируются без изменений и, следовательно, не работают надёжно на реплике, если не включена репликация на основе строк. (См. Раздел 16.2.1, «Форматы репликации».)

USER() и CURRENT_USER() автоматически реплицируются с помощью репликации на основе строк при использовании режима MIXED и генерируют предупреждение в режиме STATEMENT. (См. также Раздел 16.4.1.8, «Репликация CURRENT_USER()».) Это также верно для VERSION() и RAND().

Для NOW() бинарный лог включает метку времени. Это означает, что значение возвращаемое вызовом этой функции на источнике реплицируется на реплику. Чтобы избежать неожиданных результатов при репликации между серверами MySQL в разных часовых поясах, настройте часовой пояс на обоих источнике и реплике. Дополнительную информацию см. в Разделе 16.4.1.31, «Репликация и часовые пояса».

Чтобы пояснить возможные проблемы при репликации между серверами, находящимися в разных часовых поясах, предположим, что источник расположен в Нью-Йорке, реплика — в Стокгольме, и оба сервера используют местное время. Дополнительно предположим, что на источнике вы создаёте таблицу mytable, выполняете оператор INSERT для этой таблицы, а затем выполняете выбор из таблицы, как показано здесь:

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)

Местное время в Стокгольме на 6 часов опережает время в Нью-Йорке; поэтому, если вы выполните оператор SELECT NOW() на реплике в тот же самый момент, будет возвращено значение 2009-09-01 18:00:00. По этой причине, если вы выберите данные из копии таблицы mytable на реплике после того, как CREATE TABLE и INSERT были реплицированы, вы, возможно, ожидаете, что mycol будет содержать значение 2009-09-01 18:00:00. Однако это не так; при выборе данных из копии таблицы mytable на реплике вы получите точно такой же результат, как на источнике:

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

В отличие от NOW(), функция SYSDATE() не является безопасной для репликации, так как она не зависит от операторов SET TIMESTAMP в бинарном логе и является недетерминированной, если используется журнализация на основе операторов. Это не проблема, если используется журнализация на основе строк.

Альтернативой является использование параметра --sysdate-is-now, чтобы функция SYSDATE() стала алиасом для NOW(). Это должно быть сделано на источнике и на реплике, чтобы это работало правильно. В таких случаях функция все равно выдает предупреждение, но его можно безопасно игнорировать, если параметр --sysdate-is-now используется как на источнике, так и на реплике.

SYSDATE() автоматически реплицируется с помощью репликации на основе строк при использовании режима MIXED и генерирует предупреждение в режиме STATEMENT.

См. также Раздел 16.4.1.31, «Репликация и часовые пояса».

Следующее ограничение относится только к репликации на основе операторов, а не к репликации на основе строк. Функции GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK() и IS_USED_LOCK(), которые обрабатывают блокировки на уровне пользователя, реплицируются без знания репликой контекста параллельности на источнике. Поэтому эти функции не следует использовать для вставки в исходную таблицу, так как содержимое на реплике будет отличаться. Например, не следует использовать оператор, такой как INSERT INTO mytable VALUES(GET_LOCK(...)).

Эти функции автоматически реплицируются с помощью репликации на основе строк при использовании режима MIXED и генерируют предупреждение в режиме STATEMENT.