关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问

PP

2018-08-08 14:40:02 +08:00

感谢楼主及评论部分中各位 V 友的讨论，非常务实，非常有帮助。

腾讯云给出了复盘声明，我想接下来社会力量要做的应该是设计和进行复现实验，只有通过复现来完全还原前沿数控和腾讯各自描述的关键细节，那么腾讯的复盘声明才是可信的，除此以外别无他法。

前沿数控蒙受了重大损失，后续处理也比较慌乱，特别是将技术诉求和商业诉求混为一谈，甚至没有考虑采取法律手段。尽管前沿数控在这一事件中存在一系列的业余和教训，但是具体涉及商业和法律的事务还是由前沿数控自己处理比较好，看客帮不上忙。

腾讯云对事故进行的调查，从时间上看是不及时并且不主动的，这同腾讯云的业务稳定性和长期商业利益相悖。复盘结论在被社会力量充分浮现之前只能作为腾讯云一家之言，对事故受害方前沿数控进行善后是腾讯云的当前责任，如何提升业务稳定性并且逐渐恢复市场信心会是腾讯云今后很长一段时间内的常规工作重心。

技术人员在这一事件中应该大有收获。质疑和讨论是正题，掐架和捉贼是失焦。很高兴通过许多 V 友的评论和讨论学习到了新的知识和思考方法，这里一并致谢！同时，非常期待这次事故的实验复现。

johnjiang85

2018-08-08 14:41:49 +08:00

@firefox12 写入会计算校验信息并写入，但是不进行校验是我了解的原理，工程实现怎么做的细节不清除。

老副本的问题还是去看下公告的第二个违规操作吧，数据立马会收掉了，仓库 1 还一直有非常多的客户再写入的。也就是楼主的疑问 2.

mhycy

2018-08-08 14:42:38 +08:00

@johnjiang85
前提不存在，校验计算是接收到写入请求后在内存中进行计算
为了避免计算结果错误建议是使用 ECC 内存（应该没哪家是 DIY PC 做存储服务器吧？）
三副本的存储架构原则上根本不允许外部请求直接访问指定的节点，一切都是随机化
因为外部请求到达存储节点后几乎不可能有持续读取的可能
既然都是随机请求那么也没有把请求压到特定某个存储节点的必要了

这暴露出来的问题...

johnjiang85

2018-08-08 14:43:07 +08:00

@firefox12 我的意思是写入的时候不校验计算出来的块校验信息，3 副本之间的校验信息对比肯定要做的。

johnjiang85

2018-08-08 14:45:18 +08:00

@mhycy 实际的用户访问业务系统确实是你说的，随机（ hash 或者 range 或者 hash+range ）打散的，但是数据迁移据我了解没去做随机打散访问请求，就是指定的其中一个副本去访问的，这里的流程是有问题的。

PP

2018-08-08 14:46:34 +08:00

更正：
“复盘结论在被社会力量充分浮现之前只能作为腾讯云一家之言”
应为
“复盘结论在被社会力量充分复现之前只能作为腾讯云一家之言”

johnjiang85

2018-08-08 14:47:16 +08:00

@mhycy 当然一个副本也是随机散列到不同磁盘上的，所以这里其实并不是数据完全丢失，其实是丢失了一部分数据，主要是部分系统元数据从这块磁盘上读的错误，影响了更多的实际数据。

xud6

2018-08-08 14:48:48 +08:00

@mhycy #36
随机访问和持续读写的速度有很大差距，机械盘更加明显。计算资源与存储规模匹配是按照正常工作负载进行的。对虚拟化系统存储，随机访问是正常的工作负载而持续读写只有在少数情况下才会出现。至于造成性能瓶颈，可以看 zfs 的 sha256。
RAIN 工作和 RAID 类似，正常工作中同一个 IO 操作只会访问一份数据，除非出错（或校验失败），本质上就是以某个数据源作为数据拷贝源，只是粒度更细。

firefox12

2018-08-08 14:51:40 +08:00

@johnjiang85 写入不校验块校验信息是不存在的，如果是这么设计的话，那么比现在掉了一个用户的信息还糟糕。tx 存储我还是认识人的，他们没这么弱。

仓库 1 没空间删除数据可以接受，仓库 2 3 复制出错误数据也可以解释。那么仓库 2 3 的上一个副本去哪里了呢？难道仓库 2 3 也没空间，老副本赶紧都删除了？还是说错误的新副本把老副本给覆盖了？

johnjiang85

2018-08-08 14:53:26 +08:00

@mhycy #43
我#45 #47 的回答想了下确实是有问题的，因为我也不了解细节，我了解到的信息也只是公开的故障复盘报告。所以应该还是去随机访问的，但是正好访问到了出问题的这个副本的这个磁盘，导致读取到了错误的数据，并且没有进行校验。

mhycy

2018-08-08 14:53:49 +08:00

@johnjiang85
随机 -> 等效随机，不是实际随机
块与校验数据是一体的，写入的时候三副本并行写入必然三副本都会存在理论上一致的块，不做回读校验可以理解
但从你的回复中似乎理解错了这个校验数据的位置

另外，数据迁移如果请求源位于存储的主控节点，由集群的主控集群对外提供块存储访问请求支持的话
对于一个有着正常业务的三副本存储集群最底层的存储节点就根本不可能获得真正的顺序读取请求，一切都是随机
对于这类集群缓存是极其重要的，除非为纯固态集群。

既然要做缓存，那么直接访问指定节点的可能性就不存在了
毕竟涉及到一个很重要的问题：数据副本同步

这也是疑问 3 没想通的
既然是迁移，既然是同步，自然需要尽可能少量数据进行快照后的增量数据同步

正常说迁移一个镜像：
快照，同步数据，同步快照后增量，剩余数据到某个阈值
最高优先级断流同步，再重新服务，这是理想的无停机迁移
（也可以让集群 2 作为代理访问集群一的原始数据的同时同步到集群 2，但读延迟会增加）
对于业务来说近乎无感（实际上至少有百毫秒级的 IO 断流或者延迟）

为何是到 8 点多的一刀切切换？难道是停机迁移？

johnjiang85

2018-08-08 14:58:15 +08:00

@firefox12 只有仓库 I 和仓库 II，仓库 II 中的 3 副本数据因为读取就是没校验的错误数据，写入的全错；仓库 I 中 3 副本 1 份错误的，2 份正确的，正常的操作都不会有问题，也可以自动修复。但是把客户的操作切到仓库 II 之后，仓库 I 的数据回收就会把 3 个副本全部删除掉了，然后其他客户的写入又会把这 3 个副本原本的数据空间覆盖掉。

mhycy

2018-08-08 15:02:19 +08:00

@xud6 #48
所以缓存很重要，ZFS 的原理和性能瓶颈是知道的，块存储集群其实也是为了解决这类问题
所以 CPU 资源配备理应足够，但感觉更大的瓶颈在内存上面，毕竟运算是需要数据来回搬的
具体没见到实现也不好说什么，只是。。。看起来。。。。计算资源是没配够了。

> RAIN 工作和 RAID 类似，正常工作中同一个 IO 操作只会访问一份数据，除非出错（或校验失败），本质上就是以某个数据源作为数据拷贝源，只是粒度更细。

关于这个，只能说别忘了这是 3 副本，不是 RAID-Z/Z2/Z3, 是 RAID1....

johnjiang85

2018-08-08 15:02:22 +08:00

@mhycy 嗯对，就是写入的时候是没有回读校验的，毕竟我也只是半把刀，有些名词不提就想不起来。

缓存是有的，但是迁移没有通过缓存。

具体的迁移流程细节就完全不清除了，理论上应该是这个流程，镜像加快照流水。

xud6

2018-08-08 15:03:47 +08:00

@mhycy
理想的情况下当然是按单个云盘切换存储系统，但这样的开销太大可能性很低。在单个云盘之上，存储系统之下应该还会有管理单位。

mhycy

2018-08-08 15:07:05 +08:00

@xud6 #55
这个不知道腾讯云的具体实现我就不好说什么了
只是现在看起来....坑是越来越大了....

johnjiang85

2018-08-08 15:11:24 +08:00

理论、协议和工程实现有时候差距还是不小的，尤其涉及到具体管理的时候，也不能说一定就是坑吧，当然具体实现我也不了解。

mhycy

2018-08-08 15:14:29 +08:00

@johnjiang85 #54
迁移不过缓存直接把请求压到最后的根节点是基本不可能的
对整个集群的性能是一个严重的拖累（假定为机械硬盘）

mhycy

2018-08-08 15:15:24 +08:00

@johnjiang85 #57
期待技术细节分享

johnjiang85

2018-08-08 15:19:25 +08:00

@mhycy #58 我找人问了下，确认是 SSD

关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问

前言

正文

疑问 1

疑问 2

疑问 3