Несоответствие метки времени базы данных

Question

В нашей базе данных есть таблица с именем order, в этой таблице есть столбец с именем create_at, который является столбцом отметки времени. когда клиент создает заказ, мы устанавливаем это поле на текущую метку времени. поэтому проблема в том, что когда мы выгружаем наш файл SQL с помощью mysqldump (напрямую с сервера), файл sql показывает, что порядок номер один создан в - 2017-01-01 10:27:35, что точно правильно .

SQL DUMPED QUERY:

INSERT INTO `orders` VALUES (1,'2017-01-01 10:27:35'');

Но когда мы открываем этот заказ из нашего веб-приложения, это показывает, что заказ был создан в 04:27 вечера, 01 января 2017 года (+6 часов вперед, что неправильно).

Также, когда мы создаем запрос MySQL, он также показывает, что заказ создан в - 04:27 PM, 01 января 2017 (+6 часов вперед, что неправильно).

Эта проблема возникает 24-04-2018, в этот день Ubuntu обновляет наш сервер MySQL с 5.7.21 до 5.7.22. В журнале ошибок MySQL наблюдается несовпадение +6 часов.

в строке 44 - Буферный пул (и). дамп завершен в 180424 21:34:16 (журнал запись в 15:34:16, но в детальном журнале показывается дамп, завершенный в 180424 21:34:16 где задержка 6 часов).

---

В настоящее время, когда мы создаем заказ, поля create_at показывают отлично на веб-приложения и MySQL запрос, но когда мы дамп SQL данные, это показывает созданный с 6-часовой задержкой .

Примечание:

1. наш часовой пояс установлен в UTC + 6, Азия / Дакка
2. Mysql Версия: версия сервера 5.7.22-0ubuntu0.16.04.1
3. SQL сброшен снова - / *! 40103 SET TIME_ZONE = '+ 00:00' * /;
4. проблемное поле - все отметки времени, столбец
5. наше системное время установлено как UTC + 6, а mysql global & session time установлено как системное.
6. systemctl status systemd-timesyncd.service

Выход:

$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Tue 2018-02-06 16:53:59 +06; 2 months 18 days ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 11383 (systemd-timesyn)
   Status: "Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com)."
    Tasks: 2
   Memory: 564.0K
      CPU: 4.272s
   CGroup: /system.slice/systemd-timesyncd.service
           └─11383 /lib/systemd/systemd-timesyncd

Answer 1

С документация MySQL (выделено мое):

Текущая настройка часового пояса сеанса влияет на отображение и хранение значений времени, которые зависят от зоны. Сюда входят значения, отображаемые такими функциями, как NOW() или CURTIME(), а также значения, хранящиеся в столбцах TIMESTAMP и извлекаемые из них. Значения для столбцов TIMESTAMP преобразуются из текущего часового пояса в UTC для хранения и из UTC в текущий часовой пояс для извлечения.

Поскольку вы сказали, что глобальные переменные MySQL и переменные часового пояса сеанса установлены на SYSTEM, а системный часовой пояс равен Asia/Dhaka (UTC + 6), то, похоже, все работает так, как задумано.

Обратите внимание, что согласно документам mysqldump для опции --tz-utc:

... mysqldump устанавливает часовой пояс своего соединения в UTC и добавляет SET TIME_ZONE='+00:00' в файл дампа. ... --tz-utc включено по умолчанию. Чтобы отключить его, используйте --skip-tz-utc.

Поскольку вы сказали, что вывод из файла дампа имеет правильное время, то, если вы не передаете флаг --skip-tz-utc, ваши данные были вставлены в терминах UTC (т. Е. С часовым поясом сеанса, установленным на +00:00 во время вставки).

Затем, поскольку ваше приложение видит сдвиг времени на 6 часов вперед, ваше приложение, вероятно, не устанавливает часовой пояс сеанса, и поэтому SYSTEM преобладает.

Есть два варианта:

• Позвоните SET TIME_ZONE='SYSTEM' перед оператором вставки (или выясните, где вы устанавливаете +00:00 и прекратите это делать). Это сделает элементы в базе данных основанными на часовом поясе системы.

• Вызовите SET TIME_ZONE='+00:00' в вашем приложении, чтобы вы запрашивали значения в UTC, а не на 6 часов раньше. Это делает элементы в базе данных UTC на основе (что является предпочтительным).