多谢。

v5.1.4 mvcc 测试 create table t123 (id int primary key,name varchar(100),age int,city varchar(100)); insert into t123 values (1,‘user1’,1,‘bj’); update t123 set name=‘user2’ where id=1; update t123 set name=‘user3’ where id=1; []# curl http://192.168.1.13:10080/mvcc/key/test/t123/1 { “key”: “74…

多谢答复。

除了这部分耗时外，其他部分的耗时较少，就没做记录 total_process_keys由于基本上都是100左右，所以没做记录，下面是其中一次记录 12月6号，耗时 0.79 秒 total_process_keys: 173, total_keys: 1835642, rocksdb:{delete_skipped_count: 417, key_skipped_count: 1837387

谢谢答复 问题1 这篇文章里的第二章tombstone key 引发的“血案”里说：gc后在没有被compact之前做了优化，是不需要扫描的 问题2 这个经过测试，当前版本是存在的，除非compact之后才会消失，而且用了5.1.4和5.4版本进行了测试 但是这个如何确认mvcc数据是否gc了，例如我insert一条数据，update了10次，那如何确认这9条mvcc数据是否被gc了？ 如果可以确认被gc了，就方便查找是否在compact之前还存在这9条数据 问题5 集群开启老的gc是在11月23号，下面是记录的同一条sql的执行计划情况 11月30号，耗时 13.23 秒 …

已填写

A集群上数据是正常的。B集群上应该只有那一条数据又问题。

，，

5.1版本又冒出来了，

谢谢，是的，没办法删除这条数据

多谢老师答复。目前集群同步已经从 TiDB 4.0.9 ---- drainer(4.0.9) ----> TiDB 5.1.4 升级到 TiDB 5.1.4 ---- drainer(5.1.4) ----> TiDB 5.1.4 我们继续观察这个问题，如果有结果，我再反馈，多谢

感谢，明白了

出问题期间，是这样抓取drainer信息吗？ curl http://xx.xx.xx.xx:8250/debug/pprof/goroutine?debug=2 -o goroutine.log 会不会和版本升级有关系，因为以前4.0.9 —> 4.0.9 ，这种报警信息不频繁，我忘记是否有了，应该有，可能非常少。但是自从下游集群升级到5.1.4之后，drainer报警开始变多，几乎一两天内就会报一次。

开启黑白名单了，drainer配置如下 【drainer配置如下】 [syncer] channel-id = 123456789 db-type = “tidb” ignore-schemas = “INFORMATION_SCHEMA,METRICS_SCHEMA,PERFORMANCE_SCHEMA,mysql,test,dm_meta” loopback-control = true sync-ddl = true txn-batch = 100 worker-count = 256 [[syncer.ignore-table]] db-name = “tidb_…

这个是在drainer event时间段抓取的debug信息 drainer所在服务器磁盘是充足的，11T磁盘，而且有告警 tidb-binlog版本是5.1.4，即 tidb 5.1.4 ----drainer(5.1.4)-----> tidb 4.0.9 谢谢

感谢，只能选择一个，所以我选择楼上的了，对不住了

由于cdc无法启动，不断panic，导致监控上没显示内存使用

drainer_stderr.log里，出问题时刻没日志，下游是通的

有几个疑问也借这个机会问下，谢谢 手动 compact 和自动 compact 优先级是怎样的？如果手动 compact 优先级更高，执行时间长的话会不会影响到集群的写入，因为手动 compact 可能会影响系统正常的自动 compact tikv中没有看到配置参数 max_background_compactions (没有对外暴露这个参数)，而是使用 max_background_jobs 来代替，那么是不是这样的： max_background_jobs = max_background_flushes + max_background_compactions compact 进度…