[image]

我要挑战

已填写~

我要挑战

[%E5%9B%BE%E7%89%87] 已报名

这种情况记得可以调高oom时被kill的优先级，让系统优先kill br之下的程序来释放内存

读paper不多，一般想剖析一个技术的根本原理与目的的时候会读，推荐 raft论文，相比paxos通俗易懂，且应用广泛 https://raft.github.io/raft.pdf

嗯，如果发现数据量匹配上了，还真就很可能忽略这个错误了

这个我也不太明白，唯一知道的配错的pd地址的集群是数据源，里面有需要同步的全量的相关库表，目标数据库中有相同的库

嗯嗯，目前是一致的，是由于我pd-addr配错集群导致，感谢提醒

哈哈感谢你的经验提醒~目前我们就一个版本5.3，没有太多版本，不过最近tidb都发布6.0了，后续使用的话，这块儿还真得多注意，确认好集群的版本及对应版本的工具

嗯嗯，感谢关注~

哈哈 卷~ dumpling这个步骤没问题，数据都是ok的；找到原因了，是我的配置文件写错了 pd-addr 感谢~

各位~找到原因了，是由于我配置文件中pd-addr地址配错ip了，配成了源库的pd地址，改成目标库这一套就好了；感谢各位~

卷起来~

感谢提醒； 关于sql文件的计算其实我有一个前提没有描述，就是我已知原库中表数据有6千万行，然后再来粗略计算的sql文件中的行数，想看看是不是有明显的缺失；原表中数据如下： [image]

关于数据量我用这个粗略算法这么算 其实是有个前提，就是我实际原库表中的数据 已经查过是6千万行数据，然后我再次来校验sql文件中的数据是否全，才有的上面的计算方式截图；实际库中数据也是6千多万，如下： [image]

希望尽快解决集群中有多副本tiflash时候，在用br备份进行集群恢复时导致失败的问题ε(*･ω･)_/ﾟ:･☆

[image] 无线充电器不错~ 书包、书包，多来几种类型的书包~