变更操作，一定要仔细核对！！！

可能不是机器配置低的问题，可能是你的两个安装包没有merge成功。可以看一下tidb-community-server-v6.5.2-linux-amd64 里面是否有tikv-cdc,tidb-dashboard 组件包

update 关联更新的时候，条件没写对，误更新了很多数据，虽然更新前有备份，但是也丢了一些数据，

你的pump 有几个节点？ 再看看有没有binlog ERROR相关的日志

在出现skip binlog 的tidb server 的节点的日志里面搜binlog 关键字，应该记录了skip binlog 的原因，根据你上面说的删除大事务来看，应该是这个删除的大事务导致的。可以根据日志里面的startts 到慢日志里面找一下具体的sql

可以看看监控，是否有skip binlog 的tidb server

可能是集群的负载太小了，建议用压测等方式把负载打上去

这种情况一般都是底层的资源出现了问题，建议先排查系统资源，包括磁盘，网络

cdc 有自己的gc-ttl 设置，当cdc 任务出现异常后，会阻塞集群的gc ,防止数据被gc 掉，导致任务同步的数据重做

就是加一个keepalive 然后用vip 作为负载均衡的地址，这样任何一个hapoxy 出问题后，都可以通过vip 来提供高可用服务

已报名

haproxy+ keepalive 确保负载均衡高可用，或者用F5之类的负载均衡

资源管控

这个库是已经很久了吗？ 很多的DDL 吗？ 如果是的可能是已知的问题

可以参考一下这个文章专栏 - 迁移prometheus数据 | TiDB 社区

慢跑或者吃自己喜欢吃的美食

可以看看这个参数是否可以解决 idb_txn_assertion_level 从 v6.0.0 版本开始引入 作用域：SESSION | GLOBAL 是否持久化到集群：是 默认值：FAST 可选值：OFF，FAST，STRICT 这个变量用于设置 assertion 级别。assertion 是一项在事务提交过程中进行的数据索引一致性校验，它对正在写入的 key 是否存在进行检查。如果不符则说明数据索引不一致，会导致事务 abort。详见数据索引一致性报错。 对于新创建的 v6.0.0 及以上的集群，默认值为 FAST。对于升级版本的集群，如果升级前是低于 v6.0.0 的版本，升…

从官方文档上看，drainer 是没有remap 的功能的，只能上下游一致

可以tikv的监控，看看leader和region 是否都均衡了