没分。

【你最想实现的 TiDB 功能需求】 DM 同步支持 Truncate 语义 【你最喜欢的 TiDB 新特性 + 理由】 可视化 Dashboard ，尤其是里面的 Top SQL，简直没有之一的神器，排查紧急问题时，一抓一个准 【你最想要周边心愿池里的哪个周边】 2024 社区新款双背包 【你考过哪些 TiDB 证书？】 PCTA 【你身边有多少位朋友在用 TiDB？】 前司、现司同事们都在用，好几十套集群了

在应用层设置吧，这样已经是最灵活了。你还想要个中间灵活度的

支持。

这个需求，给你的备集群设置更长一些的 GC TTL 应该也是异曲同工

参考你这个,还不如参考官方文档呢

感谢！你这个回答靠谱

咦，已经没有积分奖励了吗

是把任务迁移到规格更高的新服务器，但是应该要有一个标准流程去下线老服务器呢。我看到就有两种，不知道用哪个

刚好最近在做表结构备份相关工作，我用的 mydumper 可以并行呢，挺快的

恭喜嗮

目前版本迭代飞快，业务该如何敲定待升级的版本，例如 6.5 版本升级，选择 7.1 、7.5 还是 8.X？是否一定是越新越好？

看你提到了 query-error 命令，是不是有点搞混了，query-error 是最早版本的用法了，后面改为 handle-error，然后现在是使用 binlog 。。。实话说我之前也有点混淆 其实 DM v6.0 之前版本是使用 handle-error， 6.0+ 之后改为使用 binlog skip ，参考：https://docs.pingcap.com/zh/tidb/stable/handle-failed-ddl-statements 需要注意的是，目前只支持 ddl 语句的一键跳过，如果是数据变更 DML 的话，不支持。

结合出事（告警）的时间段，再在 Dashboard 里面的 TopSQL 对应着捞一把，简直太好用了，没有之一

如果是同个 IDC ，只是为了更换硬件设备，第二种方案更好啊，TiDB 扩容缩容操作很成熟的，就是周期会长一点，过程中注意控制一下数据迁移速率避免影响业务正常使用。

你是想问 tiup cdc xxx 这样用？可以的，本来就推荐这样用吧

虽然旧环境生产 TiDB 是 5.4，理论上也可以使用 6.2 +版本的 TiCDC 来做同步吧，如果只是为了数据迁移，短时间内使用估计问题不大，有试过了吗？

结合研发流程规范处理：JAVA、Golang 等编译时对变量类型不一致应该能前置发现 看你的版本的 7.5 ，也可考虑引入 TiDB 的资源管控，对这类 runaway Query 进行监控和自动识别：管理资源消耗超出预期的查询-runaway-queries，建议先做好调研和功能测试，看可否符合你的需求。

WAL 是用于数据持久化，raft log 是 raft 协议，数据副本同步同步使用。我个人日常运维的问题排查都比较少接触这俩日志，不过 rocksdb.info 这个文件倒可能会检视一下，如果要类比，就有点类似 show Innodb engine status 里面的引擎状态信息、各个分层数据信息