开发者社区> jeanron100> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

增量数据丢失的原因分析(三)

简介: 今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。 对于这类需求也算是轻门熟路,不光维护管理数据,补数据也在行。
+关注继续查看
今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。
对于这类需求也算是轻门熟路,不光维护管理数据,补数据也在行。看来今天又不可避免要修复数据了,不过还是得明白原因是什么。
首先查看了近几天的数据同步情况,时间范围是5月1日~5月6日,但是查看却唯独缺少了5月5日的数据,因为是计算前一天的数据变化情况,所以5月6日应该会同步5月5日的数据变化。
TRUNC(UPDATE_DATE)   COUNT(*)
------------------- ----------
2016-05-02 00:00:00       6724
2016-05-03 00:00:00       6198
2016-05-04 00:00:00       5772
2016-05-01 00:00:00       7268
至于数据为什么没有同步,确实有些奇怪,这个时候先来理一理数据同步的原理,其实这个库是一个OLAP的库,会从OLTP的库中抓取变化的数据情况更新到OLAP的统计库中。而同步的驱动方式是通过scheduler的方式来完成,每天凌晨会定时同步。
使用下面的方式来查看最近10天的scheduler job的运行情况,发现只有今天运行失败。
select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1   ;
LOG_DATE                            OWNER JOB_NAME             STATUS     
----------------------------------- -------------------------- -----------
27-APR-16 03.28.14.044366 AM +08:00 TEST  SYN_USERCENTER       SUCCEEDED
。。。
05-MAY-16 03.28.32.538013 AM +08:00 TEST  SYN_USERCENTER       SUCCEEDED
06-MAY-16 03.28.23.809575 AM +08:00 TEST  SYN_USERCENTER       FAILED
那么问题就看起来有了方向,是由于scheduler job失败导致的数据同步失败。
到底是什么原因导致的呢,可以查看一个视图来得到一些相关的信息。
select log_date,owner,job_name,status,ADDITIONAL_INFO from  DBA_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1   ;
得到的信息是一个ORA错误:ORA-12170: TNS:Connect timeout occurred
这个时候使用tnsping的方式来连接那个目标库,发现没有了响应,超时退出。
而这个问题明白了原因之后,依然很蹊跷,这个环境一直没有动过,也没有做过系统层面的网络变化,到底是什么原因导致的呢。
对于这个问题,从数据库层面,系统层面还真分析不出来什么特别之处。所以就求助网络组的同学。
目前是10.11.133.128的服务器去telnet 10.11.65.112的服务器,但是通过几次简单的测试,在65.112端看到133.128的ip却会有多种变化。有时候是10.11.133.128,有时候是10.11.134.129
# tcpdump -i eth0  host 10.11.133.128 and port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:49:57.314010 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [F.], seq 1003407519, ack 3632754879, win 49640, length 0
16:49:57.314095 IP 10.11.65.112.1528 > 10.11.133.128.51355: Flags [F.], seq 1, ack 1, win 115, length 0
16:49:57.316199 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [.], ack 2, win 49640, length 0
16:49:59.098833 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [S], seq 1012926596, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:49:59.098877 IP 10.11.65.112.1528 > 10.11.133.128.51382: Flags [S.], seq 233530546, ack 1012926597, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:49:59.101376 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [.], ack 1, win 49640, length 0

# tcpdump -i eth0 host 10.11.134.129 and  port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:41:25.055791 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [S], seq 778963631, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:41:25.055848 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.126448 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.211652 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [R], seq 778963632, win 49640, length 0
对于这种情况,查看了133.128的网卡配置情况,e1000g0存在一个漂移的IP,即10.11.133.128,而另外一个IP 10.11.134.129则来自一个新的网卡e1000g1
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.11.133.129 netmask ffffff00 broadcast 10.11.133.255
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.11.133.128 netmask ffffff00 broadcast 10.11.133.255
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.11.134.129 netmask ffffff00 broadcast 10.11.134.255
查看路由的信息,可以看到目前是存在两个默认路由,分别从133,134网段进行过滤。
$netstat -rn
Routing Table: IPv4
Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              10.11.133.254       UG        1      28179           
default              10.11.134.254       UG        1      28129           
10.11.133.0         10.11.133.128       U         1       7961 e1000g0:1
10.11.133.0         10.11.133.129       UG        1          0           
10.11.134.0         10.11.134.129       U         1       1308 e1000g1   
224.0.0.0            10.11.133.129       U         1          0 e1000g0  
而这个也是目前导致测试中发现源端的IP一会是133.128,一会又是134.129
当然还有更多的网络内容我也没接受得了。不过可以看出网络这块还是存在着一小窍门。
最终在65.112开通了这两个IP的防火墙之后,看起来问题是初步解决了,后续还需要更多的验证。
而留给我的就是修复数据,这个还是需要结合里面的业务来根据需求来补充那部分没有同步的数据。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
关于数据埋点的认识以及在流量分析系统中的实际使用
关于数据埋点的认识以及在流量分析系统中的实际使用
92 0
数据库设计的三范式以及实体分析
数据库设计的三范式以及实体分析
28 0
数据分析
什么是数据分析?数据分析的本质是什么?
758 0
数据分析
数据分析 提供了数据集合, 应该将他们分成两类, 一个是测试类, 一个是训练类 深度学习中最难的就是特征提取 并不是数据中的所有特征都有用的, 没有需要的使用DataFrame中的drop()去掉 one-hot: 将string值转为int值,方便运算 --> pd.
721 0
数据分析书单
     知识在于点滴积累
771 0
COCO 数据集的使用
Windows 10 编译 Pycocotools 踩坑记 COCO数据库简介 微软发布的COCO数据库, 除了图片以外还提供物体检测, 分割(segmentation)和对图像的语义文本描述信息.
7373 0
七周成为数据分析师!
这是一份七周的互联网数据分析能力养成提纲,入门到熟练的指南,并不包含数据挖掘等高阶内容。可也足够让产品和运营们获得进步。
24109 0
+关注
jeanron100
Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
1178
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载