“计算和存储解耦” 和现在的架构的核心区别是什么,现在不也是计算节点和存储节点分离吗?
VMware 装 TiDB ,硬件性能会不会有点儿过于弱?
问题 1 TiDB 集群故障时,我最希望 TEM AI 智能运维能帮助解决这些具体问题:
1)自动根因定位:不用人工翻日志、查监控,直接告诉我是 PD / TiKV / TiDB Server 哪一层出问题,是网络、磁盘、锁冲突、热点还是资源瓶颈。
2)故障自动止损:例如自动切流量、隔离异常节点、自动重启异常组件,避免业务雪崩。
3)恢复建议:给出可执行的恢复步骤
4)跨组件关联分析:把监控、日志、慢查询、调用链自动关联,自动画出故障传播链。
5)减少误告警:AI 自动过滤噪音告警,只报真正影响业务的问题。
问题 2 慢查询方面,我希望 TEM AI 提供具体分析 + 优化能力:
…
明显还是用 tidb-lightning 比 source 更好。产品设计上,source 是兼容 mysql 数据库,tidb-lightning 用于导入 dumpling 生成的文件
恢复时没有校验集群是否存在库的步骤,但是元数据库(mysql)是否会有影响可能得验证一下
你现在用 TiDB 时,最卡业务、最费人力的问题是什么?
故障诊断,某些性能问题如22点数据库响应延时增加10ms,定位问题根因,故障问题如会话链接异常存在10天,定位问题根因等等,还是抓耳挠腮
如果加一个新功能就能少加班、少踩坑、少花钱,你最希望是什么?
全链路跟踪与诊断
什么功能一旦上线,会让你更愿意升级 / 付费企业版?
全链路跟踪与诊断
没有这样的接口暴露出来。把 pd 部署到有 etcd 的机器上有可行性吗?
tidb_enable_lazy_cursor_fetch = on 就是数据库侧的流式吧?不过当前是实验特性
performance_schema.session_connect_attrs 记录有没有帮助?
单纯做实验,tiup playground 比 docker 更方便、更自由
据说 9 版本向量能力会进一步释放,预计 3-4 月份

携手奔赴下一个十年!
你是从哪个数据库迁移到 TiDB 的? 迁移 TiDB 都用啥工具?偏爱 TiDB 原生的 DM、Lightning、TiCDC,还是习惯用 DataX、Flink 这些第三方,或者自己自研工具?
源主要是 Oracle、兼容MYSQL协议数据库 ,使用的工具包括两种:DSG 以及 DM
不用 TiDB 原生迁移工具的小伙伴,是因为技术栈适配难、性能不够,还是觉得易用性一般?大家最希望 TiDB 迁移工具加啥实用功能?
TiDB 自己的迁移工具 TMS 产品能力略弱于 DSG,DM 对于非原生 MySQL binlog 格式的数据库不支持,所以需要原生外的工具
实操 TiD…
您当前使用的云资源部署在哪个地域(城市),会考虑单一城市部署还是多城市容灾?在哪朵云上?
私有。目前跨城基建当前正在建设中
目前运行着多少套 TiDB 集群,合计节点数 / 核心数(core)为多少?您当前 TiDB 相关资源的年度总费用是多少? 云提供的具体折扣力度(如折扣率 / 优惠方式)是什么?
已经上百套
若迁移至 TiDB 全托管服务,您期望获得的服务等级协议(SLA)标准是什么(如可用性、故障恢复时间等)?
暂时不会考虑全托管,主要是安全要求