什么云主机这么强不用重启啊？

最好是一目了然，加上放缓节奏，不然太凌乱肋

没分。

【你最想实现的 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 来做同步吧，如果只是为了数据迁移，短时间内使用估计问题不大，有试过了吗？