作者介绍:2012年进入腾讯,负责腾讯云数据库平台(CDB)和腾讯云分布式存储平台(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数据merge的方式来修复数据,也就是通过从两个cell中分别读取可以读取的数据进行merge的操作,原理为:1、 先尝试从Cell3(10.53.65.214)读取2、 读取失败的数据再从Cell2(10.53.65.101)上读取看看两次读取的数据是否能完全修复那个小表的数据。这次只有少量的block读取失败,虽然没成功,但让人看到了希望:
通过双cell的数据merage发现通过两个cell无法修复那个小表的数据,难道数据就真的修复不了了吗?到了这一步,研发的兄弟们还在疯狂的想办法,在pallysheng和yhwang的共同努力下,发现有异常的diskid的元数据在三个cell中是一致的,这说明这个数据在机器剔除后没有新的数据写入,因此可以通过读取被剔除机器的数据来恢复:
有了这个脑洞打开的设想,yhwang开始修改工具逻辑,在测试环境做完测试后,继续开始迁移,迁移的时候大家都紧盯着日志屏幕,直到看到最后打印迁移成功的日志,大家都松了一口气,数据从新恢复成3份副本了:
至此持续2天1夜的腾讯云数据保卫战完美收官,腾讯云的数据安全离不开每一个运维和研发同学的努力。
经历了这次惊心动魄的数据修复保卫战后,运维开发进行了深入的反思,这次数据能修复很大程度上是我们的运气好,但是做存储如果将数据安全寄托在运气上,那么和耍流氓没什么区别。因此最紧要的是如何从这次问题中总结出经验和教训,做到类似的问题不再发生,确保我们数据安全更上一层楼,这次问题的反思如下:
过去只针对IO错误的监控,在针对某个盘只有少量扇区坏掉,并且数据比较少访问的情况下,通过IO错误监控是失效的(比率太低),需要专门增加磁盘粒度的监控。
将这次线上修复的case进行发散思考,沉淀出来CBS这边数据修复的相关解决方案和工具。
目前IO读取如果出现异常,会进行重试,但是没有向不通cell重试的逻辑,这个在后续的程序中也会添加对应的优化。