GitHub user YongGoose added a comment to the discussion: Proposal for global_table Cleanup Optimization in Seata Transacion Coordinator
Thank you for your response! 👍🏻 I wasn’t aware that ShardingSphere internally uses Seata—appreciate the insight. I also agree that introducing an additional component to solve this issue might not be the best approach. As you suggested, using different `global_table` names per `TC` node would effectively result in sharding. However, I’m a bit concerned that this setup could introduce issues in case of a TC node failure. If a node goes down, **recovery from another TC node might not be possible**, which could lead to `data loss`. Also seems like handling data imbalance across nodes would be difficult in this setup. Since this is a simpler approach, the trade-offs are quite clear. What are your thoughts on these potential downsides? GitHub link: https://github.com/apache/incubator-seata/discussions/7362#discussioncomment-13268207 ---- This is an automatically sent email for dev@seata.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@seata.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org For additional commands, e-mail: dev-h...@seata.apache.org
