GitHub user funky-eyes added a comment to the discussion: How to smooth the upgrade after transferring to an apache organization
io.seata:seata-server迁移至org.apache.seata:seata-server待讨论问题: 当新老版本seata-server采用raft集群同步时，新版本使用的新class下的,由于当时设计的序列化器使用了jackson以及协议类使用了writeObject，纷纷记录了类的信息，如`io.seata.server.cluster.raft.sync.msg.dto`包下的类，目前在新版本上可以通过保留老的类来做到向下兼容，但是如果新版本的seata-server一旦被选为leader，由它发起同步task，老版本的seata-server将因为本地没有这个类，而导致序列化失败。 当然有几种解决方案来处理： 1.保留所有的老类，同步时直接使用老类，百分百兼容，但是会导致这部分类一直是在io.seata包下 （简单，但是太过粗糙，做法不优雅） 2.保留所有老类，增加集群间的版本协商能力，通过jraft扩展的出集群同步能力，在选主前记录每个节点的版本，使用最低版本的协议进行兼容，直到所有节点都是最新版才启用新包下的同步类。 （复杂度高，但100%兼容） 3.仅保留协议类，因为新版向下兼容，升级的过程中会重选举，新节点不太可能成为leader，只要新节点超过半数，老节点序列化异常并不会影响集群稳定性，举个例子假设节点 1,2,3 3为leader，1和2滚动升级，3继续为leader，1,2节点兼容节点3的同步消息，集群没有任何影响，最后再升级节点3，集群完成升级。如果节点2为leader的情况下升级，那么升级1,2后，触发重选举，可能1,2之间产生一个新leader，新leader进行同步时，节点3由于序列化失败，状态机不会继续往下执行，但是同步log继续会落到磁盘中，当节点3升级后，他便能解析之前的raft log，能迅速恢复的数据一致的状态。（高度兼容，官网侧升级方案即可） 希望大家能参与讨论下raft集群模式下的io.seata:seata-server如何平滑迁移至org.apache.seata:seata-server中来。 The issue being discussed is the migration from io.seata:seata-server to org.apache.seata:seata-server in a Raft cluster synchronization scenario. The problem arises due to the use of different packages and changes in class paths. In the new version, the classes are located in a different package, causing deserialization failures in the old version when it acts as the leader and initiates synchronization tasks. There are several proposed solutions: 1.Preserve all the old classes and use them directly for synchronization. This ensures complete compatibility but results in the classes remaining in the io.seata package. This approach is simple but not elegant. 2.Preserve all the old classes and introduce version negotiation capabilities between cluster nodes. Using extensions provided by jraft, record the version of each node before leader election and use the lowest version protocol for compatibility until all nodes are upgraded to the latest version. This solution is more complex but guarantees 100% compatibility. 3.Keep only the protocol classes. Since the new version is backward compatible, during the upgrade process, there will be a re-election, and it is unlikely that a new node will become the leader. As long as more than half of the nodes are upgraded, the serialization failures in the old nodes won't affect the stability of the cluster. This solution provides a high level of compatibility and can be considered as an official upgrade plan. The discussion aims to determine the best approach for a smooth migration from io.seata:seata-server to org.apache.seata:seata-server in a Raft cluster mode. GitHub link: https://github.com/apache/incubator-seata/discussions/6059#discussioncomment-8228950 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
