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

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

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

Чтобы объяснить возможные проблемы при репликации между серверами в разных часовых поясах, предположим, что источник расположен в Нью-Йорке, реплика — в Стокгольме, и оба сервера используют местное время. Предположим также, что на источнике вы создали таблицу 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.

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

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

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