客戶 v8.5.2 與 v8.5.3 報的 timestamp 是一樣的嗎 assertion left == right failed\n left: TimeStamp(461120534839033880)\n right: TimeStamp(461120534839033913)

感谢反馈，已反馈给产研 https://github.com/tikv/tikv/issues/18498 具体的处理进度可见这个链接， 目前问题正在定位中，还没有找到影响的根本原因，如有新进度，我也随时同步给你们 感谢反馈 @xmlianfeng @TiDBer_yyy @HGHNICE_666 如果 BUG 需要配合产研定位，我也会第一时间联系你们寻求帮助。

在执行 FLASHBACK CLUSTER 之后，TiDB 中的统计信息可能不再准确。这是因为 FLASHBACK CLUSTER 操作会将整个集群恢复到指定的时间点或 TSO（事务序列号），这可能导致数据的状态与当前统计信息不一致。因此，为了确保查询优化器的有效性，建议在执行 FLASHBACK CLUSTER 之后重新收集统计信息。这可以通过执行 ANALYZE TABLE 命令来实现，以更新表的统计信息，从而帮助优化器选择更高效的查询执行计划

可以用这个工具恢复一下： https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/pd-recover

收到，我来了，我微信：billmay

好勒！有问题再随时发帖！

https://docs-archive.pingcap.com/zh/tidb/v8.3/maintain-tidb-binlog-cluster/ 可以使用 binlogctl 来下线 Pump/Drainer https://docs-archive.pingcap.com/zh/tidb/v8.3/binlog-control/ [image] 建议先下线之后再做集群升级

生产环境中不要用 DMR 版本，建议把集群升级到v8.5.3

你目前有几台服务器？

建议用敏捷模式~ 这样子 3台机器就能搭 3节点 国庆你可以测起来

[image] tidb operator: 1.6 是支持 k8s 1.28 ，排除下版本的兼容问题，

已知的 bug~ https://github.com/pingcap/tidb/issues/54535 更新到 v6.5.12 可以解决该问题

Hi~ TiCDC 在v6.5 的系列修复了 200+ 个 bug， 建议如果有使用 TiCDC 的，可以升级到 6.5.12~ 这个版本好用一些~

单机部署尽量使用敏捷模式

但是正常来说，可控的范围内，大部分基本上用户会规划 百 TB 级别就开始拆库

目前来看 这边有看过最大的集群是单集群 1.4 pb

根据大家的建议，如果你仍然要使用 v2.0 ，那么你需要检查： [7c40a353c456f58496031acb0406ada2] [6ce8420e48ac039a6fb2af3c4ae155ee]

感谢大佬的解答！