Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册

从网络管理员到DBA的奋斗之路feihong.blog.chinaunix.net

博客已经转移到博客园:http://www.cnblogs.com/feihongwuhen/

  • 博客访问: 5665656
  • 博文数量: 393
  • 博客积分: 9600
  • 博客等级: 上校
  • 技术积分: 18814
  • 用 户 组: 普通用户
  • 注册时间: 2009-01-01 00:00
个人简介

2007年开始从事运维方面的工作,经历过网络管理员、linux运维工程师、DBA、分布式存储运维等多个IT职位。对linux运维、mysql数据库、分布式存储有丰富的经验。2012年加盟腾讯,目前在腾讯负责腾讯云数据库平台和分布式存储运维平台的运维规划工作。 微信:feihongwuhen

文章分类

全部博文(393)

文章存档

2017年(9)

2016年(19)

2015年(3)

2014年(8)

2013年(8)

2012年(92)

2011年(67)

2010年(141)

2009年(46)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: 服务器与存储

接触分布式存储已经有一年多的时间了,首次遇到存储侧三份数据都有异常的情况,三份数据异常意味着客户数据的丢失,这个对云存储来讲是致命的打击。为了保证数据的安全,CBS运维和开发的同学进行了持续两天一夜的数据保卫战,最终做到数据0丢失,那么CBS运维和开发的同学是如何通过紧密合作来扭转乾坤的?且听我慢慢道来:

告警来袭,5个小表自动迁移异常

运维侧收到一个数据迁移失败的告警,告警内容如下:

[基础架构部][CBS3.0_广州_set_快照_bonding_set4][10.182.24.13][cbs_web][check_storage_tablet][2016-09-07 11:11:19] [error] [重要] CBS3.0_广州_set_快照_bonding_set4 51dead小表,没空闲小表迁移或者没有正常迁移,请检查!     

备注:这是为了能保证异常的小标都能正常迁移,提升CBS数据安全的告警。

这种问题优先级最高,因此运维第一时间介入分析,这个是前一天有一台cell的机器异常,系统自动将其剔除,此时正常的数据变成了2份(Cell2Cell3),如下图所示:

剔除后会自动发起容灾迁移,成功迁移后就能恢复三份数据正常的状态。查看迁移日志,发现是由于读取cell数据异常引起


根据以往的经验,一般是对应的cell机器对应的盘有异常,使用dmesg查看,发现迁移失败的盘所在的disk确实有异常:


备注:线上的dbtrasf(迁移模块)暂时不支持指定cellIP来读取数据

此时的线上CBS的数据分布变成了如下图:


此时风险非常高,只有一份数据是正常的,如果此时Cell3再有异常后果将不堪设想,于是紧急和研发的同学沟通迁移方案,经过讨论,我们确定了指定从Cell3读取数据的修复策略。

定向读取,首战告捷

确定好方案后,研发开始修改dbtrasf代码,30分钟研发修改代码+自测完成(确实很高效,点赞),运维侧拿到支持指定cell读取数据的包后,在测试环境和仿真环境进行反复迁移过程中的数据一致性校验,未发现异常。正式开始在线上迁移,事实证明,定向读取确实靠谱,成功迁移4个小表,还有1个小表迁移仍然报数据读取失败,继续跟进。

多扇区异常,雾霾笼罩

通过使用smatctl分析发现10.53.65.21414个扇区异常,那个小表的数据刚好有分布在坏的扇区的数据,因此迁移也是读取数据异常导致迁移失败。而10.53.65.101800多个扇区异常,此时基本可以确定三份数据都出现不同程度的损坏。此时部分数据的分布如下图所示:

吓死宝宝了,于是和研发的同学一起再次讨论紧急修复方案。

备注:分布式存储1个小表的数据丢失可能是影响到整个set所有的盘的数据。

cell数据merage,希望乍现

通过沟通,确定采用双cell数据merge的方式来修复数据,也就是通过从两个cell中分别读取可以读取的数据进行merge的操作,原理为:

1、 先尝试从Cell3(10.53.65.214)读取

2、 读取失败的数据再从Cell2(10.53.65.101)上读取

看看两次读取的数据是否能完全修复那个小表的数据。这次只有少量的block读取失败,虽然没成功,但让人看到了希望:

read from the first[diskid=290763668122043122, lba=1069470973952, sid=1]
[2016-09-09 16:13:38] read from the second[diskid=290763668122043122, lba=1069470973952, sid=1]

三个cell数据merage,扭转乾坤

通过双cell的数据merage发现通过两个cell无法修复那个小表的数据,难道数据就真的修复不了了吗?

到了这一步,研发的兄弟们还在疯狂的想办法,在pallyshengyhwang的共同努力下,发现有异常的diskid的元数据在三个cell中是一致的,这说明这个数据在机器剔除后没有新的数据写入,因此可以通过读取被剔除机器的数据来恢复:


有了这个脑洞打开的设想,yhwang开始修改工具逻辑,在测试环境做完测试后,继续开始迁移,迁移的时候大家都紧盯着日志屏幕,直到看到最后打印迁移成功的日志,大家都松了一口气,数据从新恢复成3份副本了:


至此持续21夜的腾讯云数据保卫战完美收官,腾讯云的数据安全离不开每一个运维和研发同学的努力。

总结成败,稳定江山

经历了这次惊心动魄的数据修复保卫战后,运维开发进行了深入的反思,这次数据能修复很大程度上是我们的运气好,但是做存储如果将数据安全寄托在运气上,那么和耍流氓没什么区别。因此最紧要的是如何从这次问题中总结出经验和教训,做到类似的问题不再发生,确保我们数据安全更上一层楼,这次问题的反思如下:

存在的问题:

1、 监控上存在漏洞

过去只针对IO错误的监控,在针对某个盘只有少量扇区坏掉,并且数据比较少访问的情况下,通过IO错误监控是失效的(比率太低),需要专门增加磁盘粒度的监控。

2、 Cell数据修复缺乏工具支持

将这次线上修复的case进行发散思考,沉淀出来CBS这边数据修复的相关解决方案和工具

3、 程序逻辑上可以进一步优化

目前IO读取如果出现异常,会进行重试,但是没有向不通cell重试的逻辑,这个在后续的程序中也会添加对应的优化。

收获:

1、 加深了研发和运维的合作

2、 排查过程中充分体现了腾讯人专业、激情、责任

3、 通过这次修复工作提升了CBS团队在应对3份数据异常修复技术,经验得到很好的沉淀


阅读(14555) | 评论(1) | 转发(1) |
给主人留下些什么吧!~~

cuipig2017-01-08 20:54:18

提出问题,解决问题,总结问题,思路清晰,并且提出了建设性的见解,大牛!

评论热议
请登录后评论。

登录 注册