mysql备份要注意哪些_mysqldump备份数据需要注意的细节

本文讲述了在使用mysqldump进行MySQL数据备份时,由于时区差异导致备份数据缺失的问题。通过折半查找法定位到问题是由0时区和本地时区8小时差引起。解决方案包括修改mysqldump的where条件时间值或调整MySQL全局时区,但后者可能引发更多业务问题。建议在备份时使用服务器时区。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

导读

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

问题

我的朋友小文前几天遇到一个怪事,他用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万条记录。

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

排查

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

那么,如何定位呢?

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

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

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

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

解决

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

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的时区设置:

d7bfdfb3e032334cf8c44b7c6bff6ed0.png

图1

然后写入一条数据:

e19ed7f4338202e8dfea8158c32bd590.png

图2

第一次备份,用本地时间条件去过滤:mysqldump -w “dt >= ‘2016-12-21 14:00:00′”

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

fd19ad312404394ecbce08fcce887a83.png

图3

第二次备份,用本地时间减去8小时再去过滤:mysqldump -w “dt >= ‘2016-12-21 06:00:00′”

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

9dab84db60f7da62729bd3b480f8ffab.png

图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区 的时间,因此没有数据。

总结

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

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

679214f20b04b28fe7bd40ba61be0b15.png

图5

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值