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中是一致的，这说明这个数据在机器剔除后没有新的数据写入，因此可以通过读取被剔除机器的数据来恢复：