调研背景
TiDB 采用存算分离架构，存储层最佳实践方案采用本地单盘 Nvme 部署性能优势明显。但是在关键业务场景中，基于存储容灾可靠性以及存储成本考虑会考虑使用共享存储。共享存储技术方案中 S3 技术被广泛的实践落地验证，也获得大量用户认可。TiDB 在存储层 TiKV 支持共享存储的产品需求要被关注和评估。
在 TiDBv7.5 的时候，tiflash 支持 S3 正式 GA 了，相关文档： https://docs.pingcap.com/zh/tidb/dev/tiflash-disaggregated-and-s3 。Tiflash 支持 S3 之后，我们开始听到了小伙伴对 TiKV 支持共享存储的各种声音…
当前 TiDB Severless 支持存储层使用 S3，在云上采用共享存储方案技术成熟。在本地部署方案中，在一些非关键或者测试环境场景中，TiDB 在部署 TiKV 可以使用共享存储通过划分本地 LAN 存储方式来支撑使用，该存储方案的读写性能损耗严重，且极端场景存储数据丢失无法恢复等问题亟需解决。结合数据库市场中针对共享存储的数据库解决方案案例，TiDB 在内核层面会积极评估和权衡 TiDB 支持共享存储的方案需求。考虑评估使用共享存储，诸如 块存储、 OSS /S3、 NAS 等类别共享存储，所以开展本地调研来收集广大 TiDB 用户对共享存储使用需求以及场景情况。
参与调研
-
场景需求： 你当前的业务中是否遇到了需要使用 TiKV 支持共享存储的场景？你期望通过 TiKV 支持共享存储的满足你哪些要求/需求？希望使用那种共享存储来支撑该场景？你能否提供当前业务中数据读写比例以及负载情况、读写延迟情况，如果使用共享存储的场景、规模、架构方案等信息？
-
痛点描述： 在使用当前采用直通盘 Nvme SSD 存储解决方案时，你遇到了哪些问题？这些问题是否包括了性能损耗、数据丢失风险、硬件成本过高、架构技术调整困难或运维复杂性？这些问题是否对你的业务造成了影响，你期望通过 TiKV 支持共享存储来解决哪些痛点？
-
功能需求：你期望 TiKV 支持共享存储提供可以实现哪些功能？例如，支持指定共享存储类别（例如 S3、块存储、NAS 等），指定 TiKV 数据副本数量，副本同步依赖共享存储实现，TiKV 支持混合存储模式等等。
参与调研奖励：
按要求回复 3 个问题即可参与抽奖，本次调研将抽 3 名小伙伴获得最新款金属手机支架 & 奖励 100 积分 & 经验值。
没有按照要求回复将不参与奖励和抽奖。
最新款金属手机支架
后续计划
调研之后我们会与有强需求场景的小伙伴，随机抽取 3-5个小伙伴进行 1v1 深入沟通产品需求，如有迭代计划将在本贴第一时间更新计划。
MrSylar
( Mr.Sylar)
3
场景需求
目前业务有需求“同城双活”。TiDB 目前的解决方案是 DR-AUTOSYNC 或 Ticdc，但 corner case 其实这两个方案都不具备“真正双活”的能力，它不能 100% 保证两个中心的数据一致性。业界参考解决方案其中之一是使用“共享存储”，同城双中心的两套集群共享一份数据，理论上可以满足业务对数据库“双活的需求”
痛点描述
直通 ssd 目前有两个问题：1是可靠性待提高：单盘不具备硬件冗余性而双盘冗余，如果是“硬” raid 需要专门 raid 卡支持，如果是软 raid，可靠性和成本又会增加。 2是磁盘资源可能会浪费。共享存储可以避免这些问题
功能需求
1）希望支持华为的 Dorado
2）希望保证性能至少不大幅度降级
3）希望同城中心可以使用共享存储中的数据，RTO无限接近0 的接管故障中心的集群业务
5 个赞
场景需求
暂无。目前的tidb，多副本机制，已经能保证相当高水平的数据安全。
痛点描述
单盘可能存在一定的故障风险，会引发一定的数据库可用性。
功能需求
暂无。
迷途小书童
5
场景需求
暂无。 tidb多副本机制，已经能保证高可用、高性能等需求。
痛点描述
共享存储存在存储单点故障风险，如果共享存储出现问题，整个集群都会受到影响；
功能需求
如开发该功能，希望可以将存储设备分成不同的故障组，确保同一组内的磁盘不同时出现故障，降低数据丢失风险。通过配置镜像或条带化方式，确保数据在不同的故障组中有备份，从而提高可用性。在添加或移除磁盘时，会自动重新平衡数据，以保持性能和容量的最优配置。提供监控工具，帮助管理员识别和管理故障组的状态，及时处理潜在问题。在某个故障组发生故障时，可以自动转移数据访问到其他可用的故障组。
小龙虾爱大龙虾
(Minghao Ren)
6
场景需求
暂无
我觉得目前直通 ssd 挺好的，依靠 TiDB 的多副本就可以实现高可用
TiDB 数据库对写入能力要求比较高，高端存储比较贵，一般自带多副本，如果用共享存储的话，TiKV 还要用多副本吗？这种架构最终可以节省成本吗？
DBRE
8
1、数据归档场景，性能和qps要求不高，但存储量极大，
2、没遇到啥问题
3、支持指定共享存储类别、指定 TiKV 数据副本数量
清风明月
10
应该不需要，共享存储会有性能等相关的问题，如果基于备份的话，可以考虑支持云存储，比如s3，dbfs等。
小小橙兜
11
可以支持，毕竟不同的场景有着不同的客户需求！！！！
yytest
13
场景需求：暂时没有。
痛点描述：虽然 NVMe SSD 提供高性能，但仍需进行适当的性能调优，包括调整 TiDB 的配置参数，如 block-cache-size 和 write-buffer-size，以充分利用 NVMe 的高速读写能力。
功能需求：共享存储应当支持快速故障检测和数据的自动恢复，确保在任何单一节点失败的情况下，整个数据库系统的持续运行和数据的可用性。
场景需求：在做本地应用，对数据备份方面，需要支持NAS 和 云备份。
痛点描述：软件是基于 MySQL 开发，还没有做 TiDB 适配。
功能需求：同时支持 S3 OSS NAS 中的一个或几个，以及问题发生后的数据还原。
胡杨树旁
17
场景需求：
数据归档，而且归档数据还会不定时的查询，保存单副本即可，在需要查询数据的时候可以进行数据恢复
你期望通过 TiKV 支持共享存储减少归档数据的备份频次
希望使用NAS来支撑该场景
痛点描述：
当前采用直通盘 Nvme硬件成本较高、扩展能力有限
功能需求：
期望 TiKV 可以支持nas来支持保存但副本数据
templey
(templey)
18
场景需求
高可用,有点类似oracle的rac场景,管理磁盘组的方式
痛点描述
目前所用高可用场景大多是采用同步的方式,当然各有利弊,共享存储的方式不会导致数据有延迟或者不一致的情况
功能需求
支持集群高可用,可以多节点同时使用
场景需求
暂无。
痛点描述
tiup 操作机节点是不是可以用共享存储解决，拓扑在每个机器上都可以操作
功能需求
tiup 操作机节点是不是可以用共享存储解决，拓扑在每个机器上都可以操作
