2个从节点S1和S2，S1完成全量同步，S2全量同步执行一半，主从切换，将S1提升新主，S2切新主后，不再进行全量同步

[chengyu-l]

Is this a regression?

Yes

Description

2个从节点S1和S2，S1完成全量同步，S2全量同步执行一半，主从切换，将S1提升新主，S2切新主后，不再进行全量同步。

20240614更新:
1 这个case是否存在还存疑，需要再验证，因为即使replicationID相同，offset也不应该可以对的上
2 但有一个关联问题确实存在:
如果一主一从，从节点全量同步到一半的时候主挂了，这个时候从节点内部没有数据（或者都是脏数据）是没有资格提升为主的。 预计提供一个对外的标志位放在info命令的返回值中来告知该节点是否在全量同步过程中出现过意外

Please provide a link to a minimal reproduction of the bug

No response

Screenshots or videos

No response

Please provide the version you discovered this bug in (check about page for version information)

No response

Anything else?

No response

[chengyu-l]

问题原因是：S1和S2都已经在pika配置文件中设置了 replication_id，S2 在切新主后，replication_id 都相同，slave在MetaSync时，force_full_sync_ 不会被设置为 true，此时不会进入 TryDBSync 逻辑。S2 接下来会进入TrySync逻辑，新主S1在收到TrySync请求后，只会判断binlog文件是否已存在，如果存在，就不进行全量同步。
修改方法：新主S1在收到TrySync请求后，除了判断binlog文件是否已存在，还需要再判断一下 filenum 和 offset 是否都为0 ，如果都为0，则设置响应状态为 kSyncPointBePurged，要求 S2 发起全量同步请求。

[chengyu-l]

遇到该问题，需要运维人员介入。由运维与业务协商。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

When encountering this problem, operation and maintenance personnel need to intervene. It is negotiated between operation and maintenance and business.

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Update: It is still doubtful whether this case exists and needs to be verified again.
But there is a correlation problem that does exist: if there is one master and one slave, the slave node is fully synchronized and the master hangs up halfway. At this time, there is no data (or all dirty data) in the slave node and it is not eligible to be promoted to the master. It is expected to provide an external flag bit in the return value of the info command to inform the node whether there has been an accident during the full synchronization process.