是否需要手动把该节点上的leader切换到其他节点，
原则上是不需要的，tikv 会自动 transfer leader, pd 会一样
启动指定节点时，是否会对已经处于启动状态的其他组件和节点有影响
tiup cluster start -N a,b 的意思是（在当前集群组件的状态下）启动 a，b，如果 a，b 已经是 UP 状态，该命令不会重新启动 a，b
另外图片对应的启动命令操作后会把其他节点停掉，只启动这两个节点还是说已经启动的不影响，会额外启动这两个节点
tiup 做的就是命令行指定的节点操作，不会“额外”对别的节点操作
18 天前
基本替代了 google ，碰到问题的首要依赖工具，包括代码书写、故障处理、问题解决思路等等
1 个月前
1.v5.1、v5.3、v6.5、v6.5
2.v6.5 引入的 tidb_ddl_enable_fast_reorg 大多数情况能加速索引的创建，但个别情况下也能无效、甚至可能更慢
3.灵活性与稳定性的取舍，从我企业的角度看反对该变更。稳定性是首要需求。从个人角度看，建议是否可以做一个开关，业务需求不同时，通过开关控制是否允许 session 级修改。
4.痛点1）如果 ddl 出问题，比如hang住，排错方式和手段目前不够优秀
痛点2）tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 可以加速ddl的执行，但是效果不是可预期…
2 个月前
目前处理的核心的思想第一步是缩小故障排查范围，确定导致问题的第一责任组件。第二是查看责任组件的日志，分析故障时刻的日志。一般到这里就差不多了。对于分析日志无法定位的问题，优先 ASKTUG、其实尝试理解代码。实际中大不数问题都是重复的，例如SQL 执行oom、应用到数据库链接断开等等
2 个月前
[quote=“社区小助手, post:1, topic:1033156”]
【你最想实现的 TiDB 功能需求】
最希望能体系化的故障处理和性能优化方案，类似 oracle 的等待事件、awr。当然当前TiDB也有很多参考方法、手段。只是即使解决了，每次都是有点儿“玄学”的意思。我有一个朋友，他说“易入门但难真精通”
【你最喜欢的 TiDB 新特性 + 理由】
最喜欢 dashboard 和 tiup。dashborad 特别是其中的 SQL 语句分析，对于日常 SQL 的性能分析帮助很多，tiup 个人觉得是目前的主流分布式数据库做的最好的
【你最想要周边心愿池里的哪个周边】
T…
2 个月前
场景需求
目前业务有需求“同城双活”。TiDB 目前的解决方案是 DR-AUTOSYNC 或 Ticdc，但 corner case 其实这两个方案都不具备“真正双活”的能力，它不能 100% 保证两个中心的数据一致性。业界参考解决方案其中之一是使用“共享存储”，同城双中心的两套集群共享一份数据，理论上可以满足业务对数据库“双活的需求”
痛点描述
直通 ssd 目前有两个问题：1是可靠性待提高：单盘不具备硬件冗余性而双盘冗余，如果是“硬” raid 需要专门 raid 卡支持，如果是软 raid，可靠性和成本又会增加。 2是磁盘资源可能会浪费。共享存储可以避免这些问题
功能需求
1）…
2 个月前
1.锁历史记录查询
2.SQL执行全链路诊断
3. cluster_statements_summary|history|evited 三张表数据归并以及历史记录保存
3 个月前
没有更多内容了