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

mysqldump,导出,数据,居然 · 浏览次数 : 0

小编点评

## 问题分析 小文发现导出mysqldump数据比实际少了40万条记录,且发现缺失了2016-12-12 下午的数据。经过排查,发现是由于时区的因素导致的。 **问题所在:** 1. 原先写数据时,以 0时区 时间写入的,但执行mysqldump备份时则使用的是本地 东8区 的时间,所以就有了8小时的差距。 2. 由于mysqldump的 --tz-utc 选项默认启用的作用,导致备份数据时被视为 East8区时间,导致数据偏移了8小时。 ## 解决方法 1. **修改mysqldump中的where条件时间值,减去8个小时** ```sql mysqldump ... -w \"time>‘2016-07-31 16:00:00'\" ``` 2. **修改MySQL全局时区,从 0时区 改成 东8区,并且mysqldump加上 --skip-tz-utc 选项** ```sql mysqldump ... --skip-tz-utc -w \"time>‘2016-08-01 08:00:00'\" ``` ## 其他建议 1. 了解系统本地时间:`[yejr@imsyql]$ date -R` 2. 测试数据库的全局时区设置:图1 3. 设置 --tz-utc 选项,以避免数据偏移:`--tz-utc` 4. 如果只是为了简单写数据,可以尝试修改where条件时间值,减去8个小时。

正文

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



老叶茶馆镇店之宝,扫码识别或访问 http://yejinrong.com 直达

            </div><div><div></div></div>
    </div>
    
</article>

与【转帖】纳尼,mysqldump导出的数据居然少了40万?相似的内容:

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

0、导读 用mysqldump备份数据时,加上 -w 条件选项过滤部分数据,发现导出结果比实际少了40万,什么情况? 本文约1500字,阅读时间约5分钟。 1、问题 我的朋友小文前几天遇到一个怪事,他用mysqldump备份数据时,加上了 -w 选项过滤部分数据,发现导出的数据比实际上少了40万。

[转帖]理解开源安全中的林纳斯定律

https://linux.cn/article-15344-1.html 林纳斯定律Linus's Law即“只要有足够多的眼睛关注,任何漏洞都无处隐藏given enough eyeballs, all bugs are shallow”。那么林纳斯定律是如何应用于开源软件安全的呢? 这篇文章讨

[转帖]VMWare ESXi中,不同的虚拟网卡性能竟然能相差三倍!

https://zhuanlan.zhihu.com/p/525656364 正文共:1024 字 11 图,预估阅读时间:1 分钟 在上个实验中(VPP使用DPDK纳管主机网卡),我们已经初步实现了通过DPDK纳管主机网卡。 不知道大家注意到没有,我们在查看主机网卡的主线信息时,后面的描述信息是不

[转帖]

Linux ubuntu20.04 网络配置(图文教程) 因为我是刚装好的最小系统,所以很多东西都没有,在开始配置之前需要做下准备 环境准备 系统:ubuntu20.04网卡:双网卡 网卡一:供连接互联网使用网卡二:供连接内网使用(看情况,如果一张网卡足够,没必要做第二张网卡) 工具: net-to

[转帖]

https://cloud.tencent.com/developer/article/2168105?areaSource=104001.13&traceId=zcVNsKTUApF9rNJSkcCbB 前言 Redis作为高性能的内存数据库,在大数据量的情况下也会遇到性能瓶颈,日常开发中只有时刻

[转帖]ISV 、OSV、 SIG 概念

ISV 、OSV、 SIG 概念 2022-10-14 12:29530原创大杂烩 本文链接:https://www.cndba.cn/dave/article/108699 1. ISV: Independent Software Vendors “独立软件开发商”,特指专门从事软件的开发、生产、

[转帖]Redis 7 参数 修改 说明

2022-06-16 14:491800原创Redis 本文链接:https://www.cndba.cn/dave/article/108066 在之前的博客我们介绍了Redis 7 的安装和配置,如下: Linux 7.8 平台 Redis 7 安装并配置开机自启动 操作手册https://ww

[转帖]HTTPS中间人攻击原理

https://www.zhihu.com/people/bei-ji-85/posts 背景 前一段时间,公司北京地区上线了一个HTTPS防火墙,用来监听HTTPS流量。防火墙上线之前,邮件通知给管理层,我从我老大那里听说这个事情的时候,说这个有风险,然后意外地发现,很多人原来都不知道HTTPS防

[转帖]关于字节序(大小端)的一点想法

https://www.zhihu.com/people/bei-ji-85/posts 今天在一个技术群里有人问起来了,当时有一些讨论(不完全都是我个人的观点),整理一下: 为什么网络字节序(多数情况下)是大端? 早年设备的缓存很小,先接收高字节能快速的判断报文信息:包长度(需要准备多大缓存)、地

[转帖]awk提取某一行某一列的数据

https://www.jianshu.com/p/dbcb7fe2da56 1、提取文件中第1列数据 awk '{print $1}' filename > out.txt 2、提取前2列的文件 awk `{print $1,$2}' filename > out.txt 3、打印完第一列,然后打