Questions about the high availability mechanism of sidecar-syncer

[fengbao123]

Hey Team,
I read an article about Sealos that introduced how KubeBlocks handles classic primary-replica scenarios, such as MySQL and PostgreSQL. KubeBlocks is responsible for tasks like detection, decision-making, failover, rebuilding, and role correction. However, I have the following questions regarding some of its mechanisms:

1. If the server hosting POD-0 fails and the entire POD-0 becomes unavailable, who initiates the unlock task in ETCD?
2. When other pods lock in ETCD, what are the rules? Is there communication between different pods? Is it first-come, first-served? Is it based on the highest GTID? How is data consistency ensured?
3. Setting POD-0 to "Demote Readonly": I understand this as a fencing mechanism. What happens if fencing fails and POD-0 recovers before RoleLabelling?
4. What is the entire process of rebuilding the failed master node POD-0? Will there be a rewind?

Currently, there is a lack of detailed documentation on high availability mechanisms for MySQL in such scenarios. As a result, it is unclear whether its data consistency and high availability mechanisms meet production requirements.