当前位置:首页 > 短网址资讯

纳尼,mysqldump导出的数据居然少了40万?

www.ft12.com9年前 (2017-07-22)短网址资讯1141

0、导读

用mysqldump备份数据时,加上 -w 条件选项过滤部分数据,发现导出结果比实际少了40万,什么情况?

本文约1500字,阅读时间约5分钟。

1、问题

我的朋友小文前几天遇到一个怪事,他用mysqldump备份数据时,加上了 -w 选项过滤部分数据,发现导出的数据比实际上少了40万。

要进行备份表DDL见下:

CREATE TABLE `oldbiao` (

  `aaaid` int(11) NOT NULL,

  `bbbid` int(11) NOT NULL,

  `cccid` int(11) NOT NULL,

  `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

  `dddid` int(11) DEFAULT NULL,

  KEY `index01` (`ccccid`),

  KEY `index02` (`dddid`,`time`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

顺便吐槽下,这个表DDL设计的真是low啊。没主键,允许NULL。

mysqldump备份指令增加的 -w/--where 选项是:

-w "time>‘2016-08-01 00:00:00'"

加上这个参数的作用是:只备份 2016-8-1 之后的所有数据,相当于执行了下面这样的SQL命令:

SELECT SQL_NO_CACHE * FROM t WHERE time>‘2016-08-01 00:00:00'

然后把导出的SQL文件恢复后,再随机抽查下数据看看是否有遗漏的。不查不知道,一查吓一跳,发现 2016-12-12 下午的数据是缺失的。经过仔细核查,发现比原数据大概少了40万条记录。

百思不得其解的小文请我帮忙排查问题。

2、排查

既然是少了一部分数据,那就要先定位到底是丢失了的是哪部分数据。

那么,如何定位呢?

搞数据库的人,应该都知道折半查找法,这是计算机科学里比较基础的概念之一。我们就利用这种方法来快速定位。

经过排查,发现是缺少的数据有个特点,根据时间排序,发现最早的数据是 2016-8-1 8点的,而我们上面设定的条件则是 2016-8-1 0点开始的所有数据,整整差了8个小时。

看到8小时这个特点,我想你应该大概想到什么原因了吧。对,没错,就是因为时区的因素导致的。

经过排查,发现是因为原先写数据时,是以 0时区 时间写入的,但执行mysqldump备份时则使用的是本地 东8区 的时间,所以就有了8小时的差距。

2、解决

知道了问题所在,方法就简单了。有两个方法:

1、修改mysqldump中的where条件时间值,减去8个小时。建议采用该方法。

mysqldump ... -w "time>‘2016-07-31 16:00:00'"

2、修改MySQL全局时区,从 0时区 改成 东8区,并且mysqldump加上 --skip-tz-utc 选项。这种方法需要修改MySQL的全局时区,可能会导致更多的业务问题,因此强烈不建议使用

mysqldump ... --skip-tz-utc -w "time>‘2016-08-01 08:00:00'"

问题暂且按下,我们先来看下时区因素怎么影响查询结果的。

先看下系统本地时间:

[yejr@imsyql]$ date -R

Wed, 21 Dec 2016 14:04:51 +0800


测试表DDL:

CREATE TABLE `t1` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

...

  `c1` timestamp NULL DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB;


查看MySQL的时区设置:
图1

然后写入一条数据:
图2


第一次备份,用本地时间条件去过滤:

mysqldump -w "dt >= '2016-12-21 14:00:00'"

这种情况下,显然是没有结果的。
图3


第二次备份,用本地时间减去8小时再去过滤:

mysqldump -w "dt >= '2016-12-21 06:00:00'"

这种就可以备份出数据了。
图4


此外,我们注意到mysqldump的 --tz-utc 选项,它是和时区设定有关系的:

--tz-utc


SET TIME_ZONE='+00:00' at top of dump to allow dumping of TIMESTAMP data when a server has data in different time zones or data is being moved between servers with different time zones.

(Defaults to on; use --skip-tz-utc to disable.)

这个选项的作用,就是以 0时区  备份数据,把所有时间都转换成 0时区 的数据。比如本来是在 东8区(+08:00) 的时间 14:00:00,转换成 0时区 后,会变成 06:00:00,原来是 西8区(-08:00) 的时间14:00:00,则转换成 22:00:00。这个选项是默认启用的。

在上面第一次备份时没有数据,就是因为MySQL里本身存储的就是 0时区 的数据,mysqldump也设定了转换成 0时区,我们传递进去的参数却是 东8区 的时间,因此没有数据。

3、总结

本来只想简单写一下的,结果啰里啰嗦写了好多。

其实我们只需要注意一点,服务器在哪里,就是用哪里的时区,也就是 SYSTEM 时区,在做SQL查询以及mysqldump备份数据时,也使用服务器上的时间,而不使用我们本地时间。
图5

扫描二维码推送至手机访问。

版权声明:本文由短链接发布,如需转载请注明出处。

本文链接:https://www.ft12.com/article_319.html

分享给朋友:

相关文章

FT12短网址教你如何利用大数据算法定位网站性能瓶颈(BOSS)

FT12短网址教你如何利用大数据算法定位网站性能瓶颈(BOSS)

FT12短网址资讯:架构师非常关注性能问题,上篇文章中我们介绍了京东的自动化压测体系 ForceBot,这篇文章来自 LinkedIn 的技术博客,介绍如何通过大数据算法来分析调用数据,自动定位性能瓶颈。本文由高可用架构翻译。背景我们 FT…

高并发秒杀系统架构设计 · 抢购、微信红包、短网址、一元夺宝

高并发秒杀系统架构设计 · 抢购、微信红包、短网址、一元夺宝

秒杀业务与难点秒杀业务在各业务中已然非常流行,这里我将互联网行业中的秒杀定义为:在非常短的时间内,将一件商品分成多份进行购买的行为。微信抢红包、短网址、一元夺宝、双11大促抢购等业务本质上都可视作秒杀业务。而最近大热的抢红包的难度在于这是和…

原创保护之后自媒体们该何去何从?

原创保护之后自媒体们该何去何从?

摘要:近期,互联网大佬均纷纷启动原创内容保护机制,对于原创内容创作者来说无疑是一大利好,然而对于抄袭者来说无疑是一大噩耗。虽然中国互联网不缺乏原创内容创作者,但是内容抄袭者多如牛毛,依然成为盛行之风气。伴随着各大自媒体平台纷纷加入原创内容保…

闫东论百度大脑的谋和断---2017

闫东论百度大脑的谋和断---2017

[ ft12短网址导读 ] 国之谋断,家之谋断咱们做生态化,城市之谋断咱们做城镇化,咱们称之为一基地四中心。聚集当地生态,完成当地智能化生态的改造。家事国务天下事,离不开大数据的有备无患,也离不开人工智能的抓住时机。将来智能和工业…

【官方说法】网站流量异常,如何正确反馈?

【官方说法】网站流量异常,如何正确反馈?

网站流量异常一直是站长们最头疼的问题,而每次在反馈中心提交问题,经常得到回复请详细描述您的问题,怎么详细描述问题呢?为此,学院君特邀反馈中心值班员,来给大家详解如何正确提交反馈。在反馈中心后台,值班员最常看到的反馈往往是:“我的网站流量下降…

摩拜单车发布“摩拜+”战略 过半新用户来自微信小程序

5月19日消息,摩拜单车在北京举行发布会,正式宣布“摩拜+”开放平台战略,全面布局“生活圈”、“大数据”和“物联网”三大开放平台。中国联通(微博)、招商银行、中国银联、百度地图等8大品牌成为摩拜“生活圈”的首批战略合作伙伴。 此外,摩拜单…

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。