是的。。
收到，正在内部分析。
帮忙执行下：SELECT HIGH_PRIORITY variable_value FROM mysql.tidb WHERE variable_name=‘tikv_gc_safe_point’; 拿下结果。
不好意思哈，再辛苦拿下信息：
1、执行 tiup ctl pd -u ${pd_ip:port} service-gc-safepoint 拿下结果信息
2、执行 select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb;
在结果里看下这项： tikv_gc_leader_desc 所对应的 tidb-server 节点信息，麻烦拿下对应节点的日志信息
3、集群有使用其他工具吗，比如 CDC 之类的？
-
执行结果：
-
gc_leader 信息：
93上的 tidb 日志：
tidb.log (1.2 MB)
- 除了一开始迁移数据使用了DM工具，其他都未使用。架构为 3tidb+3tikv+3pd+1tiflash
能确定拿到的 tidb.log 是 GC leader 的日志吗？
是这样的，我通过91的tidb去连，返回结果是localhost。通过93的tidb去连返回结果也是localhost。。。
也不确定gc_leader在哪台机器上，还有什么办法确认吗？
或者我把三天 tidb 的 log 都发你
这样，一共就三个 tidb-server 吧，都拿下可以吗？
重启了 92 的 tidb 节点，日志还是无法打开。
是否可以关闭 tidb 节点，然后删除日志文件，再启动？
我先翻翻这两日志
后面是怎么处理这个节点的，有没有 tidb.log 产生以及正常打开？
辛苦再跑跑这个信息：EXPLAIN ANALYZE SELECT HIGH_PRIORITY variable_value FROM mysql.tidb WHERE variable_name=‘tikv_gc_safe_point’;
暂时还没处理，在等你们回复:joy:
execution_info:
time:1.32ms, loops:2, Get:{num_rpc:2, total_time:1.28ms}, scan_detail: {total_process_keys: 2, total_keys: 2, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 10, read_count: 0, read_byte: 0 Bytes}}}
诶诶，感谢小哥及时回复，研发小哥一直在盯着问题。
小哥，92 节点的 tidb.log 怎么样了？能拿出来一份吗？如果太大不好传，grep gc_worker 试试
等6点后，我关闭92的 tidb 节点，然后 rm 日志文件，再启动 tidb，到时候看下重新生成的日志，可以查看的话我去下来发你
收到，辛苦小哥