tidb binlog_format这个参数只做适配用没有实际作用。

用tidb-binlog更稳定一点，实时同步需要看具体的写入速度及集群间网络带宽及延迟的

三副本同时挂两个tikv，访问到问题数据，可能会出现TiKV server timeout报错，先把tikv恢复再用dumping导出数据。当前看-t 设置为2，后续可以考虑将-t设置为1再试试

携手奔赴下一个十年！

max-snapshot-count可以设置大一点再看下

down的store已经没有leader了，可以直接用tiup缩容掉，重新扩一下这个节点。

analyze是系统sql，一般不会影响整个集群性能，无需过于关注，除了analyze之外有没有其他业务sql慢的

我这边实际测了一下，对于right这个expression index，dm的parser应该还没有支持。提了个issue，等修复吧。 https://github.com/pingcap/tiflow/issues/12461

binlog_row_image这个值改过吗，可以用mysqlbinlog命令解析下卡住的binlog位置看下内容

可以发下tidb的启动日志看看，allow-expression-index参数是否已经生效，修改tidb参数需要reload一下

应该是raft message的cache满了

dumpling导出指定一下–loglevel debug看看有没有别的信息

是的，先扩容好pump，再开启binlog

可以试试这种方式：https://docs.pingcap.com/zh/tidb/v7.1/use-tispark-to-read-tiflash/#使用-tispark-读取-tiflash

默认系统内存的45%

看执行计划，这两个表的数据量差距较大。 link1表11040521行 link表194142行

1、检查所有tidb的binlog写入状态： curl http://tidb_ip:10080/binlog/recover?op=status 2、如果有skip的手动恢复一下 curl http://tidb_ip:10080/binlog/recover

可以删除，可以考虑添加log的相关配置自动删除 https://docs.pingcap.com/zh/tidb/v7.5/tidb-configuration-file/#logfile

刚看了下版本，是只记录server的执行时间了。