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

接触分布式存储已经有一年多的时间了，首次遇到存储侧三份数据都有异常的情况，三份数据异常意味着客户数据的丢失，这个对云存储来讲是致命的打击。为了保证数据的安全，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 有5个1份dead小表，没空闲小表迁移或者没有正常迁移，请检查!

备注：这是为了能保证异常的小标都能正常迁移，提升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读取失败，虽然没成功，但让人看到了希望：

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无法修复那个小表的数据，难道数据就真的修复不了了吗？

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

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

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

总结成败，稳定江山

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

存在的问题：

1、 监控上存在漏洞

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

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

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

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

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

收获：

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

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

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