cheniujh

**Testing:** **Platform**： 1 40 CPU Cores, 256GB Memory 2 The maximum tranfer rate between slave and master machine is 2-5 Gib/s 3 Master and slave are deployed on 2 different...

Reopen this Issue, Cause the problem it related is not completed fixed, This issue requires another PR to do the further fixing.

          

洛杉矶服务器，我连续封了2个号，目前第三个号暂时正常。你项目这个向openai发送请求时，它会知道请求的真正来源吗（我访问我的服务器时是直接中国ip直连的）

我的和你的不一样，我是前端界面可以加载，就是突然gpt一直在思考，不回复的那种

同@liuyuecai讨论，认为暂时没有做的必要： 之前提出这个需求，应该是因为以下两种场景之一： 1. 旧master挂了之后重新回到集群，可能会恰好可以连上新主做增量，但实际上应当做全量（Pika主从只保证最终一致性，换句话说就是主从可能就滞后，有可能旧主有少量数据在新主上是没有的，应当以新主的为准） 2. 旧master挂了之后，回到集群里，在重新作为slave连接到新master之前，如果恰好新master也挂了，要避免旧master会被选为新的主节点 关于这两个点： 对于1：@liuyuecai已经提交过PR, 旧主重新上线会执行slaveof force进行强制全量同步 对于2：如果真的出现了这种问题，且需要解决，调整sentinel逻辑即可，比如给下线的主节点一个标记（标志没有资格参与选举），在他重新上线以后，在作为Slave完成建联（link_status为up）之后，才去除这个标记

**Description:** Currently, Pika's thread model for consuming Binlog from nodes is as follows: 1. The value of `sync-thread-num` from the configuration file is taken to generate `sync-thread-num * 2` worker...

1 maybe you can try clang++, or simply reinstall all the package related with compiling(just let gpt4 write an sh for you to reinstall your compiling env) 2 try to...

1. 请问本问题是否发生在3.5.4以及之前的版本？是否能稳定复现呢？ 2. 从节点如果在binlog队列还有过期任务的情况下转入tryconnect，发出trysync请求，也会触发其他问题（我称作二次trysync问题）。我修复过相关的主从问题（3.5.5才发版，之前的版本没有带上），主要做的修改是：**在从节点处理trysync response的时候，使用binlog thread去同步处理，也就是必须等到从节点解除阻塞，前面的binlog都消化完，从节点才会去处理这个trysync response**，他自己的session id才会去增长，所以我理解，现在被你注释掉的这句代码现在也是很难被执行到了（当然也有可能存在其他情况会走入这个分支，所以之前做修复的时候我没有直接注释掉它）。 辛苦您看一下下面这个PR中的第二个部分： https://github.com/OpenAtomFoundation/pikiwidb/pull/2638 请确认一下，在这个PR合入之后，您提到的问题是否还存在，辛苦了！ 如果是最新代码出现的这个问题，可以考虑是不是从节点的写阻塞还没解除，处于WaitReply状态（发出了trysync请求，还没对trysync的response进行处理），这种情况等下去应该是能恢复的。

> 我的是3.3.6版本，可能你修复的版本跟我的版本有点偏差，产生的问题似乎有点不一样，不过触发的原因是类似的，也是连续两次trysync引发的问题，请问一下当时为什么不直接注释而是采用了同步的方式进行处理，直接丢弃不匹配的会有什么问题吗，感觉这样修复也更简单。之前为什么采用的是异步处理，现在改成同步后性能会不会有什么问题 1.不采用注释的方式进行处理主要是无法确定之前这个代码到底处理了什么case，害怕注释掉之后出新的问题，将trysync从异步改成同步的话，至少带来的影响，以及潜在的副作用是能搞清楚的。 2. 采用了同步改异步方案之后，造成的影响是，从节点夯住，超时重连之后，因为trysync resp被延迟处理了，从节点会一直处于waitReply状态，直到从节点解除阻塞（消费完或者丢弃完了过期的binlog）才能成功建联，也就是说主从重连会延迟（master_status_link会更久的时间处于down状态）。在**主从同步性能方面没有实质影响**，因为哪怕你异步处理trysync resp，让主从重连，从节点的RocksDB解除阻塞之前也是没有消费能力的，所以性能上来说和你的那个方法没有显著差异。 还有一个关联PR你可以看一下：https://github.com/OpenAtomFoundation/pikiwidb/pull/2656 （另外在当前这种改异步处理的方案下，还有一种极端情况是，从节点阻塞超过40s（两个超时周期）的情况下，后面主从还能否恢复连接，这点经过验证是可以的。）