这个不行，后面的信息呢（我是下个看 ，咱们执行 DDL 的频率及数量）
另外，这个和同步不同步到 tiflash 没关系，tiflash 会判断所有的表的 DDL 变更情况
|tikv_gc_run_interval|10m0s|GC run interval, at least 10m, in Go format.|
tikv_gc_safe_point 20210924-14:35:18 +0800 All versions after safe point can be accessed. (DO NOT EDIT)
这个提供一下完整的信息（你提供的信息，我看不出频率来）
频率大概是三分钟，是数据同步，用kettle做的。楼上数据已重新更新
好滴，现在原因大概率是 因为在 gc safe point 之后，有太多的 truncate ddl 导致的，另外，能把select * from mysql.tidb; 里面的完整结果发下看看不
现在问题是要看看 GC 为啥不同步了（这个就得看日志了）
| bootstrapped | True | Bootstrap flag. Do not delete. |
|---|---|---|
| tidb_server_version | 51 | Bootstrap version. Do not delete. |
| system_tz | Asia/Shanghai | TiDB Global System Timezone. |
| tikv_gc_leader_uuid | 5f06ecdbb840001 | Current GC worker leader UUID. (DO NOT EDIT) |
| tikv_gc_leader_desc | host:crm-dc-13, pid:63678, start at 2021-09-25 14:45:16.646404363 +0800 CST m=+0.988786055 | Host name and pid of current GC leader. (DO NOT EDIT) |
| tikv_gc_leader_lease | 20210927-15:08:17 +0800 | Current GC worker leader lease. (DO NOT EDIT) |
| tikv_gc_enable | true | Current GC enable status |
| tikv_gc_run_interval | 10m0s | GC run interval, at least 10m, in Go format. |
| tikv_gc_life_time | 72h | All versions within life time will not be collected by GC, at least 10m, in Go format. |
| tikv_gc_last_run_time | 20210927-15:06:18 +0800 | The time when last GC starts. (DO NOT EDIT) |
| tikv_gc_safe_point | 20210924-15:06:18 +0800 | All versions after safe point can be accessed. (DO NOT EDIT) |
| tikv_gc_auto_concurrency | true | Let TiDB pick the concurrency automatically. If set false, tikv_gc_concurrency will be used |
| tikv_gc_mode | distributed | Mode of GC, “central” or “distributed” |
| tikv_gc_concurrency | 2 | How many goroutines used to do GC parallel, [1, 128], default 2 |
| new_collation_enabled | False | If the new collations are enabled. Do not edit it. |
GC报错的日结不是今天的：
[2021/09/25 14:43:57.612 +08:00] [ERROR] [gc_manager.rs:341] [“failed to get safe point from pd”] [err_code=KV:Storage:Unknown] [err=“Other("[src/server/gc_worker/gc_worker.rs:67]: failed to get safe point from PD: Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some(\"rpc error: code = Unavailable desc = not leader\") }))")”]
这个应该没事，你的 tikv_gc_life_time 就是3天，所以是正常的，这个建议调小一些（比如24小时）
咱们的问题原因：gc_life_time 有 3 天，导致 gc_safe_point 是3天前，所以每次调用 /tiflash/replica 时都得扫这 3 天内的所有 DDL, 平均每 3 分钟有 1~3 个 truncate 的 DDL
GC改为10分钟后有同步进度显示了
那就好，我反馈一下，看看能不能优化这个情况
能优化太好了，不然会影响差异备份
在优化列表中了，得等下一个大版本了，这个涉及的模块较多
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。