前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >数据才是永恒的存在

数据才是永恒的存在

作者头像
腾讯技术工程官方号
发布2018-01-29 15:59:59
1K0
发布2018-01-29 15:59:59
举报
文章被收录于专栏:腾讯技术工程官方号的专栏
lesterzhang(张秀云)
lesterzhang(张秀云)

作者介绍:2012年进入腾讯,负责腾讯云数据库平台(CDB)和腾讯云分布式存储平台(CBS)的运维工作,对数据库高可用、数据库调优、分布式存储运维等领域有丰富的经验。

记CBS一次动人心魄的数据保卫战

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

备注:这是为了能保证异常的小标都能正常迁移,提升CBS数据安全的告警。这种问题优先级最高,因此运维第一时间介入分析,这个是前一天有一台cell的机器异常,系统自动将其剔除,此时正常的数据变成了2份(Cell2和Cell3),如下图所示:

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

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

备注:线上的dbtrasf(迁移模块)暂时不支持指定cell的IP来读取数据此时的线上CBS的数据分布变成了如下图:

此时风险非常高,只有一份数据是正常的,如果此时Cell3再有异常后果将不堪设想,于是紧急和研发的同学沟通迁移方案,经过讨论,我们确定了指定从Cell3读取数据的修复策略。定向读取,首战告捷确定好方案后,研发开始修改dbtrasf代码,30分钟研发修改代码+自测完成(确实很高效,点赞),运维侧拿到支持指定cell读取数据的包后,在测试环境和仿真环境进行反复迁移过程中的数据一致性校验,未发现异常。正式开始在线上迁移,事实证明,定向读取确实靠谱,成功迁移4个小表,还有1个小表迁移仍然报数据读取失败,继续跟进。多扇区异常,雾霾笼罩通过使用smatctl分析发现10.53.65.214有14个扇区异常,那个小表的数据刚好有分布在坏的扇区的数据,因此迁移也是读取数据异常导致迁移失败。而10.53.65.101有800多个扇区异常,此时基本可以确定三份数据都出现不同程度的损坏。此时部分数据的分布如下图所示:

吓死宝宝了,于是和研发的同学一起再次讨论紧急修复方案。备注:分布式存储1个小表的数据丢失可能是影响到整个set所有的盘的数据。

双cell数据merage,希望乍现

通过沟通,确定采用双cell数据merge的方式来修复数据,也就是通过从两个cell中分别读取可以读取的数据进行merge的操作,原理为:1、 先尝试从Cell3(10.53.65.214)读取2、 读取失败的数据再从Cell2(10.53.65.101)上读取看看两次读取的数据是否能完全修复那个小表的数据。这次只有少量的block读取失败,虽然没成功,但让人看到了希望:

三个cell数据merage,扭转乾坤

通过双cell的数据merage发现通过两个cell无法修复那个小表的数据,难道数据就真的修复不了了吗?到了这一步,研发的兄弟们还在疯狂的想办法,在pallysheng和yhwang的共同努力下,发现有异常的diskid的元数据在三个cell中是一致的,这说明这个数据在机器剔除后没有新的数据写入,因此可以通过读取被剔除机器的数据来恢复:

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

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

总结成败,稳定江山

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

监控上存在漏洞

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

Cell数据修复缺乏工具支持

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

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

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

收获

  1. 加深了研发和运维的合作
  2. 排查过程中充分体现了腾讯人专业、激情、责任
  3. 通过这次修复工作提升了CBS团队在应对3份数据异常修复技术,经验得到很好的沉淀
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-09-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯技术工程官方号 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 记CBS一次动人心魄的数据保卫战
  • 双cell数据merage,希望乍现
  • 三个cell数据merage,扭转乾坤
  • 总结成败,稳定江山
    • 监控上存在漏洞
      • Cell数据修复缺乏工具支持
        • 程序逻辑上可以进一步优化
          • 收获
          相关产品与服务
          数据库
          云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档