博客
关于我
mysqldump备份失败案例
阅读量：398 次
发布时间：2019-03-05

本文共 7978 字，大约阅读时间需要 26 分钟。

mysqldump备份失败案例

一、问题描述

  在一次备份过程中使用mysqldump以单表时间数据类型进行过滤备份，到恢复数据时发现mysqldump备份出来的sql文件中并没有数据。

二、问题复现与排查

2.1 问题复现

  为了更好的问题排查，在表中建立了timestamp和datetime两列进行对比验证，表结构和数据如下：

mysql> show create table t1;+-------+-------------------------------------------------------------------------------------------+| Table | Create Table                                           +-------+-------------------------------------------------------------------------------------------+| t1    | CREATE TABLE `t1` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,  `time2` datetime NOT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=21 DEFAULT CHARSET=utf8 |+-------+-------------------------------------------------------------------------------------------+1 row in set (0.00 sec)mysql> select * from t1;+----+---------------------+---------------------+| id | time1               | time2               |+----+---------------------+---------------------+|  1 | 2019-07-08 13:10:13 | 2019-07-08 13:10:13 ||  2 | 2019-07-08 13:10:14 | 2019-07-08 13:10:14 ||  3 | 2019-07-08 13:10:15 | 2019-07-08 13:10:15 ||  4 | 2019-07-08 13:10:15 | 2019-07-08 13:10:15 ||  5 | 2019-07-08 13:10:15 | 2019-07-08 13:10:15 ||  6 | 2019-07-08 13:10:16 | 2019-07-08 13:10:16 ||  7 | 2019-07-08 13:10:16 | 2019-07-08 13:10:16 ||  8 | 2019-07-08 13:10:18 | 2019-07-08 13:10:18 ||  9 | 2019-07-08 13:12:48 | 2019-07-08 13:12:48 || 10 | 2019-07-08 13:12:49 | 2019-07-08 13:12:49 || 11 | 2019-07-08 13:12:49 | 2019-07-08 13:12:49 || 12 | 2019-07-08 13:12:54 | 2019-07-08 13:12:54 || 13 | 2019-07-08 13:13:13 | 2019-07-08 13:13:13 || 14 | 2019-07-08 13:13:16 | 2019-07-08 13:13:16 || 15 | 2019-07-08 13:13:17 | 2019-07-08 13:13:17 || 16 | 2019-07-08 13:13:19 | 2019-07-08 13:13:19 || 17 | 2019-07-08 13:13:21 | 2019-07-08 13:13:21 || 18 | 2019-07-08 13:13:22 | 2019-07-08 13:13:22 || 19 | 2019-07-08 13:13:23 | 2019-07-08 13:13:23 || 20 | 2019-07-08 13:13:25 | 2019-07-08 13:13:25 |+----+---------------------+---------------------+20 rows in set (0.00 sec)

  使用mysqldump对timestamp和datetime两种数据类型进行过滤备份，备份语句和备份结果如下：

  使用timestamp列作为过滤条件的备份语句：

mysqldump -uroot -p -S /usr/local/mysql/data/sock/mysql.sock --default-character-set=utf8 -q --master-data=2 --single-transaction --triggers --routines --events --databases boke --tables t1 --where "time1>'2019-07-08 13:12:48'">t1_time1.sql

  使用datetime列作为过滤条件的备份语句：

mysqldump -uroot -p -S /usr/local/mysql/data/sock/mysql.sock --default-character-set=utf8 -q --master-data=2 --single-transaction --triggers --routines --events --databases boke --tables t1 --where "time2>'2019-07-08 13:12:48'">t1_time2.sql

  使用timestamp列作为过滤条件的备份结果：

···/*!40103 SET TIME_ZONE='+00:00' */;···DROP TABLE IF EXISTS `t1`;/*!40101 SET @saved_cs_client     = @@character_set_client */;/*!40101 SET character_set_client = utf8 */;CREATE TABLE `t1` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,  `time2` datetime NOT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=21 DEFAULT CHARSET=utf8;/*!40101 SET character_set_client = @saved_cs_client */;---- Dumping data for table `t1`---- WHERE:  time1>'2019-07-08 13:12:48'LOCK TABLES `t1` WRITE;/*!40000 ALTER TABLE `t1` DISABLE KEYS */;/*!40000 ALTER TABLE `t1` ENABLE KEYS */;UNLOCK TABLES;

  使用datetime列作为过滤条件的备份结果：

···/*!40103 SET TIME_ZONE='+00:00' */;···DROP TABLE IF EXISTS `t1`;/*!40101 SET @saved_cs_client     = @@character_set_client */;/*!40101 SET character_set_client = utf8 */;CREATE TABLE `t1` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,  `time2` datetime NOT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=21 DEFAULT CHARSET=utf8;/*!40101 SET character_set_client = @saved_cs_client */;---- Dumping data for table `t1`---- WHERE:  time2>'2019-07-08 13:12:48'LOCK TABLES `t1` WRITE;/*!40000 ALTER TABLE `t1` DISABLE KEYS */;INSERT INTO `t1` VALUES (10,'2019-07-08 05:12:49','2019-07-08 13:12:49'),(11,'2019-07-08 05:12:49','2019-07-08 13:12:49'),(12,'2019-07-08 05:12:54','2019-07-08 13:12:54'),(13,'2019-07-08 05:13:13','2019-07-08 13:13:13'),(14,'2019-07-08 05:13:16','2019-07-08 13:13:16'),(15,'2019-07-08 05:13:17','2019-07-08 13:13:17'),(16,'2019-07-08 05:13:19','2019-07-08 13:13:19'),(17,'2019-07-08 05:13:21','2019-07-08 13:13:21'),(18,'2019-07-08 05:13:22','2019-07-08 13:13:22'),(19,'2019-07-08 05:13:23','2019-07-08 13:13:23'),(20,'2019-07-08 05:13:25','2019-07-08 13:13:25');/*!40000 ALTER TABLE `t1` ENABLE KEYS */;UNLOCK TABLES;

  进行数据恢复：

mysql -S /usr/local/mysql/data/sock/mysql.sock boke

2.2 问题分析

  由上文的备份结果可知，在相同条件下，使用timestamp列作为过滤条件进行备份时，备份文件中并没有备份数据；在使用datetime列作为过滤条件进行备份的情况下，可以发现虽然是有数据的，但是’time1’和’time2’两列的时间不一致。

  看到上面这个现象，这个时候我们应该就明白了，问题出在这两个时间数据类型上面。对于timestamp这种数据类型，会把客户端插入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回。而对于datetime这种数据类型，不会做任何改变，就是原样输入和输出。也就是说timestamp数据类型的记录导出会以utc时间格式导出，导入库中自动由UTC格式转为系统默认时区，所以看到导出文件timestamp内容和实际存储的不相符。同时也可以明白为什么使用time1列作为过滤条件为什么备份文件中没有数据。因为timestamp数据类型在数据库中是以utc时间格式存储，也就是将时间回退八个小时，但是过滤条件依旧是原来的时间。这就会导致备份时过滤出的结果并不是原本需要的，导致备份“失败”。

三、解决办法

  在使用mysqldump备份时，加入参数–skip-tz-utc用于禁止timestamp时区转换。

mysqldump -S /usr/local/mysql/data/sock/mysql.sock --default-character-set=utf8 -q --master-data=2 --single-transaction --triggers --routines --events --skip-tz-utc --databases boke --tables t1 --where "time1>'2019-07-08 13:12:48'">t1_time1_2.sql
DROP TABLE IF EXISTS `t1`;/*!40101 SET @saved_cs_client     = @@character_set_client */; SET character_set_client = utf8mb4 ;CREATE TABLE `t1` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `time1` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,  `time2` datetime NOT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=21 DEFAULT CHARSET=utf8;/*!40101 SET character_set_client = @saved_cs_client */;---- Dumping data for table `t1`---- WHERE:  time1>'2019-07-08 13:12:48'LOCK TABLES `t1` WRITE;/*!40000 ALTER TABLE `t1` DISABLE KEYS */;INSERT INTO `t1` VALUES (10,'2019-07-08 13:12:49','2019-07-08 13:12:49'),(11,'2019-07-08 13:12:49','2019-07-08 13:12:49'),(12,'2019-07-08 13:12:54','2019-07-08 13:12:54'),(13,'2019-07-08 13:13:13','2019-07-08 13:13:13'),(14,'2019-07-08 13:13:16','2019-07-08 13:13:16'),(15,'2019-07-08 13:13:17','2019-07-08 13:13:17'),(16,'2019-07-08 13:13:19','2019-07-08 13:13:19'),(17,'2019-07-08 13:13:21','2019-07-08 13:13:21'),(18,'2019-07-08 13:13:22','2019-07-08 13:13:22'),(19,'2019-07-08 13:13:23','2019-07-08 13:13:23'),(20,'2019-07-08 13:13:25','2019-07-08 13:13:25');/*!40000 ALTER TABLE `t1` ENABLE KEYS */;UNLOCK TABLES;
mysql -S /usr/local/mysql/data/sock/mysql.sock -e "drop table boke.t1;" mysql -S /usr/local/mysql/data/sock/mysql.sock -e "select * from  boke.t1;" ERROR 1146 (42S02) at line 1: Table 'boke.t1' doesn't exist mysql -S /usr/local/mysql/data/sock/mysql.sock boke< t1_time1_2.sql  mysql -S /usr/local/mysql/data/sock/mysql.sock -e "select * from  boke.t1;"+----+---------------------+---------------------+| id | time1               | time2               |+----+---------------------+---------------------+| 10 | 2019-07-08 13:12:49 | 2019-07-08 13:12:49 || 11 | 2019-07-08 13:12:49 | 2019-07-08 13:12:49 || 12 | 2019-07-08 13:12:54 | 2019-07-08 13:12:54 || 13 | 2019-07-08 13:13:13 | 2019-07-08 13:13:13 || 14 | 2019-07-08 13:13:16 | 2019-07-08 13:13:16 || 15 | 2019-07-08 13:13:17 | 2019-07-08 13:13:17 || 16 | 2019-07-08 13:13:19 | 2019-07-08 13:13:19 || 17 | 2019-07-08 13:13:21 | 2019-07-08 13:13:21 || 18 | 2019-07-08 13:13:22 | 2019-07-08 13:13:22 || 19 | 2019-07-08 13:13:23 | 2019-07-08 13:13:23 || 20 | 2019-07-08 13:13:25 | 2019-07-08 13:13:25 |+----+---------------------+---------------------+

  备份恢复成功！这个时候一定会有人问恢复时不会多加八个小时么？因为使用–skip-tz-utc选项后，导出文件中开头不会设置的/*!40103 SET TIME_ZONE=’+00:00’ */。

四、总结

  在使用mysqldump备份且过滤条件为timestamp数据类型时，需要指定–skip-tz-utc选项，否则可能会导致备份数据异常。

  备份后一定要验证备份文件的有效性！

转载地址：http://nkrwz.baihongyu.com/

你可能感兴趣的文章
NIFI分页获取Mysql数据_导入到Hbase中_并可通过phoenix客户端查询_含金量很高的一篇_搞了好久_实际操作05---大数据之Nifi工作笔记0045
查看>>
NIFI分页获取Postgresql数据到Hbase中_实际操作---大数据之Nifi工作笔记0049
查看>>
NIFI同步MySql数据_到SqlServer_错误_驱动程序无法通过使用安全套接字层(SSL)加密与SQL Server_Navicat连接SqlServer---大数据之Nifi工作笔记0047
查看>>
NIFI同步MySql数据源数据_到原始库hbase_同时对数据进行实时分析处理_同步到清洗库_实际操作06---大数据之Nifi工作笔记0046
查看>>
Nifi同步过程中报错create_time字段找不到_实际目标表和源表中没有这个字段---大数据之Nifi工作笔记0066
查看>>
NIFI大数据进阶_FlowFile拓扑_对FlowFile内容和属性的修改删除添加_介绍和描述_以及实际操作---大数据之Nifi工作笔记0023
查看>>
NIFI大数据进阶_FlowFile生成器_GenerateFlowFile处理器_ReplaceText处理器_处理器介绍_处理过程说明---大数据之Nifi工作笔记0019
查看>>
NIFI大数据进阶_FlowFile生成器_GenerateFlowFile处理器_ReplaceText处理器_实际操作---大数据之Nifi工作笔记0020
查看>>
NIFI大数据进阶_Json内容转换为Hive支持的文本格式_操作方法说明_01_EvaluteJsonPath处理器---大数据之Nifi工作笔记0031
查看>>
NIFI大数据进阶_Kafka使用相关说明_实际操作Kafka消费者处理器_来消费kafka数据---大数据之Nifi工作笔记0037
查看>>
NIFI大数据进阶_Kafka使用相关说明_实际操作Kafka生产者---大数据之Nifi工作笔记0036
查看>>
NIFI大数据进阶_NIFI的模板和组的使用-介绍和实际操作_创建组_嵌套组_模板创建下载_导入---大数据之Nifi工作笔记0022
查看>>
NIFI大数据进阶_NIFI监控功能实际操作_Summary查看系统和处理器运行情况_viewDataProvenance查看_---大数据之Nifi工作笔记0026
查看>>
NIFI大数据进阶_NIFI监控的强大功能介绍_处理器面板_进程组面板_summary监控_data_provenance事件源---大数据之Nifi工作笔记0025
查看>>
NIFI大数据进阶_NIFI集群知识点_认识NIFI集群以及集群的组成部分---大数据之Nifi工作笔记0014
查看>>
NIFI大数据进阶_NIFI集群知识点_集群的断开_重连_退役_卸载_总结---大数据之Nifi工作笔记0018
查看>>
NIFI大数据进阶_内嵌ZK模式集群1_搭建过程说明---大数据之Nifi工作笔记0015
查看>>
NIFI大数据进阶_外部ZK模式集群1_实际操作搭建NIFI外部ZK模式集群---大数据之Nifi工作笔记0017
查看>>
NIFI大数据进阶_实时同步MySql的数据到Hive中去_可增量同步_实时监控MySql数据库变化_操作方法说明_01---大数据之Nifi工作笔记0033
查看>>
NIFI大数据进阶_离线同步MySql数据到HDFS_01_实际操作---大数据之Nifi工作笔记0029
查看>>
喝酒易醉，品茶养心，人生如梦，品茶悟道，何以解忧？唯有杜康！-- 愿君每日到此一游！
当前时间: 2025-12-18 04:24:58   当前IP: 10.1.238.133   联系邮箱:javaeecc@qq.com     Copyright © 2020 - 2025 baihongyu.com 京ICP备2021015314号-2