更新一下： 目前没找到根因、没法解决这个隐患 就是找到这些表，因为都是低频表，直接确认一下上下游是同步正常的，然后删掉dmmeta 的syncer_checkpoint 表里面这些表的meta行数据，等下次自动重新同步（或者自己模拟一下插入新数据）即可

没解决。现在只是把明确有这些问题的表，给重新支持同步了

日志也没找到相关的迹象。只是在生产上发现有些表是这样，但是无法在测试环境复现出来。

没翻到。都是些低频的表，今天还故意找了一张一直没更新过的来复现，确实不同步了。

丢了 DML, 丢了一条对状态的更新的 binlog，下游停留在 INIT 状态了，上游源库已经是 Success 了。

这在上游也明显不是同一个事务了。同一个事务内的同一行的变更，最终提交后，也就只产生一个版本的 MVCC。但是在上游能看到 2 个版本 MVCC 哦。

【你们目前有上云需求吗？】 有 【如果上云你会更倾向私有云（BYOC） 还是全托管？】 BYOC 【有没有相关实践经验跟大家分享（安全、效率、成本如何）】 期待他人分享

实际是可以做同步的，但你问就是不支持、不建议 我们有临时用于一些运维场景中做过短暂的同步（小于一个月），也有遇到特殊场景下有遇到过 bug，测试过明确是只在 MYSQL2MYSQL 会同步报错，但 2TiDB 是没有问题的。

支持性能调优！

以前公司用 git+flyway 做 DDL SQL 版本发布。 现在公司依赖 DMS 做变更管理，实际上业务侧就是没有对 SQLversion 做版本管理，比较奔放。 我们（DBA）会有一套基于 git 的快照管理，方便追溯排查问题。但事实上一次没用上过。

[image]

是，删除后重启就好了。除了TopSQL 监控数据丢失外，目前没发现有什么其他影响…本身 ngmonitor 这个服务就相对独立点，风险不大

不用吧。我选择了第一个方式呢，定期（周末）直接删掉 tsdb 。TopSQL 这个功能简直神器啊，不好 disable

我正在解决这个问题中，目前思路： 要么参考最常见的思路，删除 tsdb 重启进程解决【简单粗暴快捷】 参考其他帖子，对底层使用的时序数据库相关配置进行调优，个人觉得这种一看就大概率是 compaction 之类相关坑：ng-monitoring-server 的内存使用有上限吗？怎么配置呢 【优雅费时费精力】 官方 repo 已新出了一个 release ，不过是 beta 版，自己 build binary出来，替换过去，看看能不能解决： https://github.com/pingcap/ng-monitoring/releases/tag/v9.0.0-beta.1 理论上这个组…

更新下：实在没有思路 重启大法解决了…现在重新恢复均衡了，但是不敢猛调了，就让它慢慢均衡吧…… [image]

有设置了： location-labels: zone, dc, host, disk isolation-label: host 现在是在 disk label 上，对 sata 类型进行均衡

不是，每个节点 10TB 数据，这里这个图不准，可能是 bit

哦对了。看监控图有很多 pending 的 snapshot worker 这个重要信息给忘记了。pd operator 也补上了

磁盘和 IO 都没有问题