V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mhycy  ›  全部回复第 41 页 / 共 188 页
回复总数  3753
1 ... 37  38  39  40  41  42  43  44  45  46 ... 188  
2018-08-08 13:39:41 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@johnjiang85
疑问一与现实有出入,建议参考 zfs 原理

疑问二暴露出的问题就不多说了

疑问三在实际架构流程公布前无法得到正确答案
2018-08-08 13:36:41 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@xud6 显然这就是问题
2018-08-08 13:11:58 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@xud6 不会,具体可以查看各个处理器的 hash 性能,限制集群规模的瓶颈就在这
@pinews 只是这违规操作的原因。。不敢细想
2018-08-08 12:29:25 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@swulling 这就是第二次复盘暴露出来的问题,没敢把猜测写出来
2018-08-08 12:19:54 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@johnjiang85
正因为了解,才产生疑问
2018-08-08 12:18:48 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@nullornull #6
参考 ZFS 的实现,块存储集群的一般而言实现类似于 ZFS,读校验绕不开
对不上 hash 就需要三副本读取修复,除非出现 hash 碰撞,那么需要等到巡检才能发现了
2018-08-08 12:14:42 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@johnjiang85
所以...什么情况下关闭校验可以提速呢?
https://www.v2ex.com/t/477885

看起来有更深层的问题
人祸只是让问题暴露出来了而已
2018-08-08 12:00:43 +08:00
回复了 mhycy 创建的主题 云计算 关于“腾讯云用户数据丢失故障”最新公告的一些细节的疑问
@lyl35023
一开始也是这么想的
但涉及到大量快照后增量数据同步的问题
而且...既然仓库 1 数据搬迁到仓库 2 的时候是错的,为什么业务能读取到正确数据?
2018-08-08 10:07:27 +08:00
回复了 mhycy 创建的主题 程序员 关于腾讯云事件“前沿数控技术生产数据完全丢失”的看法
@nullornull
这样的运维都能进腾讯。。。唉
2018-08-07 13:47:06 +08:00
回复了 mhycy 创建的主题 程序员 关于腾讯云事件“前沿数控技术生产数据完全丢失”的看法
@iConnect
所以确实没想通。。。

倒是因为这个事件围观各个帖子涨了不少存储领域的见识也算是有所收获
@ryd994
感谢科普!
@ryd994
能做块级存储集群的软件方案,不考虑读取写入校验是基本不可能存在的。
注意,要做到块级存储集群只可能是软件方案而不是硬件的 RAID 整列
能在各个计算节点互相飘的方案也只有走网络的 iSCSI 方案
(如果有别的方案希望给我科普一下,我实施过的只有 iSCSI )

RAID 保证 uptime 不保证数据这点没错,但考虑到上层软件冗余与纠错... 这锅还是甩不掉啊...
而且 RAID6 的情况下本来就自带有错误发现的能力(读取过程中两个结果互相对比)
于是... 锅还是甩不掉...
@void1900
然而架构合理的情况下公告太不靠谱了...
所以...腾讯云依旧存在问题...

作为经历过各类云服务长毛事件的一代人(例如当年的 QQ 中转站)
我就没相信过任何云服务会可靠,数据在手才是自己的
提到的各种可靠性数字是一个字都不信的(没有单位,没有标准,作为广告都能算是虚假宣传)
云服务本身是否可靠,能否作为主业务节点,需要实际情况实际分析...
例如现在的各种负面...

另: 我关于是否选择云服务的看法可以看看这帖子的回复(#47 )
https://www.v2ex.com/t/476956
@void1900
搞不懂你是在杠还是在讨论问题
本来我觉得你在贴头说的话还挺有理的
然后在回复这个帖子前重新看了回复对了下 id
现在我都不知道该怎么和你聊下去了

理性讨论问题是基本的礼貌与对别人的尊重且对双方的技术提升都能有所帮助,希望你懂这个道理。
@void1900
按照准则这个故障原因是日常不是异常
@void1900
给个场景?
@void1900
硬件 RAID 最基础最基础的低成本高可靠选项是 RAID6,不是 RAID5

RAID1 的存储成本过高
RAID5 存在两个磁盘损坏无法修复的可能性
RAID10 存在特定两个磁盘损坏后无法修复的问题(除非其中的 1 不止一个磁盘)
RAID50 存在特定两个磁盘损坏后无法修复的问题
RAID60 存在特定三块磁盘损坏后无法修复的问题

假设现在情况真的是磁盘回报异常,那么算是静默错误,当成磁盘写入全 0 好了
且故障真的是固件 BUG 引发,那么非同固件且非同批次磁盘构建阵列这个准则是否已经违反?

所以说在正确构建阵列的情况下这是概率极低的事件
除非。。。阵列卡出 BUG 了
@void1900
重新阅读回复,你会知道为什么同时损坏理应概率极低
1 ... 37  38  39  40  41  42  43  44  45  46 ... 188  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5935 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 02:04 · PVG 10:04 · LAX 18:04 · JFK 21:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.