海量数据迁移之一个误操作的问题总结(r3笔记第21天)

在生产环境中的数据迁移还是很惊心动魄的,毕竟生产的数据不容许有任何潜在的问题,很小的问题也可能导致业务的终端,这个时候dba的角色是很重要的,如果dba犯了一个很细小的问题,在海量数据迁移中可能会导致灾难性的结果,所以今天和大家讨论一下关于由vi误操作导致的问题及总结。 结合今天早上的例子来说明。 目前生产环境已经有大量的用户数据了,需要从老系统迁移一批用户数据过来,一切都在安装好计划进行准备和操作。我是采用了外部表的方式,把一个很大的表分为了几十上百个外部表,采用insert方式加载的。 数据的准备工作很快就完成了,一切都在等待最后的客户确认就准备开始运行脚本做数据批量加载了。结果当时查看系统资源,觉得可以把原本的10个并发进程该为12个。就简单的改了一下脚本。 这个时候就用vi很快的改完了,但是在数据加载的时候报了很多的错误,最开始以为是数据的问题,就发给数据迁移组去检查了。自己也在同时做一些检查,我采用了错误日志的方式来忽略主键冲突,唯一性冲突的数据。 关于错误日志的部分,可以参考数据紧急修复之启用错误日志 http://blog.itpub.net/23718752/viewspace-1192887/ 但是奇怪的是,一共有5个表有数据问题,结果检查了3个,最后都是0 rows inserted.我就怀疑是什么地方出现问题了,数据已经加载进去了。应该是在加载第二次的时候全都失败了。 我就开始检查脚本的执行历史,没有发现问题,最后在一个小细节上发现了问题。 在使用ls -l查看文件的时候,有一个很特别的文件引起了我的注意。根据我的印象,这个文件时在用vi编辑的时候,本来退出vi应该为:q ,结果打错了,达成了;q 然后一不留神生成了一个;q的文件。 -rw-r--r-- 1 produser dba 201 Oct 9 23:44 par7_tab_parall.lst -rw-r--r-- 1 produser dba 208 Oct 9 23:44 par8_tab_parall.lst -rw-r--r-- 1 produser dba 198 Oct 9 23:44 par9_tab_parall.lst -rw-r--r-- 1 produser dba 341 Oct 9 23:46 ;q -rw-r--r-- 1 produser dba 135337 Oct 10 00:34 split_par_10_appendata.log -rw-r--r-- 1 produser dba 116826 Oct 10 00:26 split_par_11_appendata.log -rw-r--r-- 1 produser dba 113885 Oct 10 00:56 split_par_12_appendata.log -rw-r--r-- 1 produser dba 169947 Oct 10 00:39 split_par_1_appendata.log -rw-r--r-- 1 produser dba 143857 Oct 10 00:09 split_par_2_appendata.log -rw-r--r-- 1 produser dba 124105 Oct 9 23:59 split_par_3_appendata.log -rw-r--r-- 1 produser dba 114643 Oct 10 00:49 split_par_4_appendata.log -rw-r--r-- 1 produser dba 143102 Oct 10 00:18 split_par_5_appendata.log -rw-r--r-- 1 produser dba 141416 Oct 10 00:32 split_par_6_appendata.log 最后在不经意中查看这个文件的时候却运行了文件的内容。 查看命令历史的时候发现这个命令触发了两次。 281 nohup ksh tmp_split_par_6_appendata.sh > split_par_6_appendata.log & 282 nohup ksh tmp_split_par_7_appendata.sh > split_par_7_appendata.log & 283 ksh check.sh|grep process ... 295 ksh check.sh|grep process 296 nohup ksh tmp_split_par_7_appendata.sh > split_par_7_appendata.log & 297 ksh check.sh|grep process 298 ksh check.sh|grep process 找到问题的来源了,就可以确定问题的影响范围了,通过错误日志对数据进一步进行了检查,发现数据没有问题了。 对于这个问题的总结由以下几点: 首先尽量不要在生产环境进行脚本的修改,不要在生产环境中随意测试脚本,以免不必要的麻烦。这个需要准备工作要更加的充分。 对于数据的导入中,个人建议还是保留主键和唯一性约束,这样可以避免很多数据的误操作带来的大问题。如果数据导入出现问题,要么是约束无法enable,要么主键无法创建,而且越是大的表在创建索引的时候也是需要一定的时间的,如果涉及的表有上百个,不能保证你的操作完全没有问题。可能几个表出现问题就需要花费较多的时间来修复。 对于日志的记录还是建议能够尽量的全面和完整,有些系统升级甚至有截屏之类的,都可以参考,在发生问题之后,能够很快的定位和总结,避免之后再犯。 在数据的迁移之前,对数据的条数进行一个完整的统计,在数据迁移完成之后再进行一个统计,保证没有数据条数不一致的情况。 不管怎么样,误操作是系统升级成败的关键,在发生误操作之后需要冷静,认真的分析问题的原因。可能有些问题还真不是问题,尽量不要着急开始做决定,以免问题雪上加霜。 最后经过确认,这个问题没有造成影响,数据的条数都是完全匹配的。下次注意。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-10-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏R语言___生物信息

Anaconda安装使用

Anaconda是一个用于科学计算的Python发行版,支持 Linux, Mac, Windows系统,提供了包管理与环境管理的功能,可以很方便地解决多版本p...

5767
来自专栏Jerry的SAP技术分享

C4C Product Price List的模型中和有效期相关的两个字段

SAP C4C的price list实例可以在工作中心Products,视图Price Lists里看到。

1567
来自专栏IT技术精选文摘

微服务部署策略的选择

动机 部署单体应用程序意味着运行多个通常是单个大型应用程序的相同副本。您通常会提供N个服务器(物理或虚拟)并在每个服务器上运行M个应用程序的实例。部署单体应用程...

2337
来自专栏CSDN技术头条

运用Kubernetes进行分布式负载测试

本文为CSDN原创编译文章,禁止转载。 负载测试是开发后台基础架构的重要一环,它不但能够演示系统在真实需求面前的性能表现,还可以通过模拟用户与设备行为,在应用程...

2146
来自专栏aCloudDeveloper

Kubernetes 笔记 02 demo 初体验

从前面的文章我们知道,Kubernetes 脱胎于 Google 的 Borg,Borg 在 Kubernetes 诞生之初已经在 Google 内部身经百战 ...

1624
来自专栏程序人生 阅读快乐

自建DNS服务器

不晓得为撒,用网上的一些公共DNS服务的时候,总是莫名其妙的有些网站无法解析,有时候114能解析,阿里DNS不行或者腾讯DNS不行,导致总是来回切换DNS,很是...

1K2
来自专栏醉程序

一个校园类微信公众平台

1313
来自专栏Debian社区

Ubuntu Server自18.04 LTS开始不再提供32位镜像

2016年6月份Canonical公司在社区公布的草案,明确自Ubuntu 16.10开始逐步放弃32位支持,并在Ubuntu 18.10中彻底移除对32位架构...

1304
来自专栏大魏分享(微信公众号:david-share)

Openshift3.9高可用部署考虑点1

一个典型的OCP高可用架构是:master至少应为三个,且为奇数个(上面有etcd);

2794
来自专栏云计算教程系列

5 种 Docker 日志最佳实践

微服务和容器很好地结合了,但是它们的结合让日志记录也变成了一个难题。作者在本文描述了一些因素,在设置监控的时候是需要考虑的。

8920

扫码关注云+社区

领取腾讯云代金券