背景
在做数据清洗工作,需要将线上的一份数据按时间 dump 到本地,再做分析。 通过 mysqldump 将数据导出下载后, 发现导出的数据与线上的数据条目数不一致。开始猜测是清洗的脚本处理逻辑出了点问题, 经过一下午的调研和排查,最后发现根本原因是在导出 MySQL 备份数据时, 系统时区和备份数据的时区不一致。
<!--more-->
问题分析
打开 mysqldump 保存下来的 binlog 文件, 在文件头可以发现以下两行配置:
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
简单来说, 就是在备份数据的时候, 首先会将 time_zone 设置为 +00:00
但查看线上的数据库的默认配置, 会发现 time_zone 使用系统默认时区:
mysql> show variables like '%time_zone%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| system_time_zone | CST |
| time_zone | SYSTEM |
+--------------------------+------------+
rows in set (0.00 sec)
查看系统的默认时区:
# date -R
Sun, 16 Jan 2019 17:10:54 +0800
解决方法
- 添加
-w
参数, 将时间进行转换, 确保两边时区保持一致, 比如原来start_at > 2019-01-16 00:00:00
, 更新为start_at > 2019-01-15 16:00:00
, 提前8小时 - 先在数据库更新时区配置为0时区:
set time_zone='+00:00';
, 备份完成后恢复时区配置:set time_zone='SYSTEM';
总结
一旦发现 dump 下来的 数据与原来数据库数据不同时, 先确认时间戳是否一致, 如果不一致, 有概率是时区设置有问题。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。