Hi，Apache Seata Team, I found some compatibility issues in the task of migrating the Seata package to org.apache.seata, which involves the transformation of the server. I have provided several solutions for backward compatibility. For details, please check the content I forwarded, among which An overview was given in both Chinese and English. I think we should unify the solution to this problem to facilitate the advancement of this work.
Jianbin Chen funky-eyes (via GitHub) <[email protected]> 于 2024年1月24日周三 14:58写道： > > 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] > >
