数据库时间戳不匹配

Question

在我们的数据库中有一个名为order的表，该表有一个名为created_at的列，它是一个时间戳列。 当客户创建订单时，我们按当前时间戳设置该字段。 所以问题是当我们通过mysqldump（直接从服务器）转储我们的SQL文件时，sql文件显示，在2017-01-01 10:27:35创建的头号订单，这是完全正确< /强>

SQL DUMPED QUERY：

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

但是当我们从我们的网络应用程序打开该订单时，它显示订单创建于2017年1月1日下午04:27（提前+6小时，这是错误的）。

此外，当我们创建MySQL查询时，它还会显示在2017年1月1日下午04:27（前面提前6小时，这是错误的）创建的订单。

此问题发生在24-04-2018，那天ubuntu将我们的MySQL服务器从5.7.21更新到5.7.22。在MySQL错误日志中，存在+6小时的不匹配。

  

第44行 - 缓冲池。 dump完成于180424 21:34:16（日志   在15:34:16输入，但在详细信息中，日志显示转储在180424完成   21:34:16这里延迟了6个小时。）

  

目前，当我们创建订单时，created_at字段会显示   完全在Web应用程序和mysql查询，但当我们转储SQL   数据显示延迟6小时创建。

注意：

1. 我们的申请时区设定为UTC + 6，亚洲/达卡
2. Mysql版本：服务器版本5.7.22-0ubuntu0.16.04.1
3. SQL Dumped againest - / *！40103 SET TIME_ZONE =＆＃39; +00：00＆＃39; * /
4. 有问题的字段 - 所有时间戳列
5. 我们的系统时间设置为UTC + 6和mysql global＆amp;会话时间设置为系统。
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

来自the MySQL documentation（强调我的）：

  

当前会话时区设置会影响区域敏感的时间值的显示和存储。这包括NOW()或CURTIME()等函数显示的值，以及TIMESTAMP列中存储和检索的值。 TIMESTAMP列的值从当前时区转换为UTC进行存储，从UTC转换为当前时区进行检索。

由于您说您的MySQL全局和会话时区变量设置为SYSTEM，并且系统时区为Asia/Dhaka（UTC + 6），因此它看起来一切正常。< / p>

请注意--tz-utc选项的mysqldump docs：

  

... mysqldump将其连接时区设置为UTC，并将SET TIME_ZONE='+00:00'添加到转储文件中。 ... --tz-utc默认启用。要禁用它，请使用--skip-tz-utc。

由于您说转储文件的输出具有正确的时间，因此除非您传递--skip-tz-utc标志，否则您的数据是以UTC的形式插入的（即，会话时区设置为{插入期间{1}}。

然后，由于您的应用程序看到时间提前了6个小时，您的应用程序可能没有设置会话时区，因此+00:00占优势。

有两种选择：

• 在插入语句之前调用SYSTEM（或找出你设置SET TIME_ZONE='SYSTEM'的位置并停止这样做）这将根据系统时区生成数据库中的项目。

• 在您的应用程序中调用+00:00，以便您以UTC而不是提前6小时查询值。这使得数据库中的项目基于UTC（这是首选）。