Orchestrator 控制主从复制集群的failover的切换流程？

1.从库选主算法：
当主服务或主服务器挂掉时，Orchestrator会自动选择一个从库作为新的主库。它使用以下算法来选择新主库：
最小延迟（Lowest Latency）：Orchestrator会选择延迟最低的从库作为新的主库。这确保了新主库能够尽快接收并处理客户端的写请求。
最高可用性（Highest Availability）：如果有多个从库延迟相同，Orchestrator会选择可用性最高的从库作为新的主库。这通常意味着选择与其他从库连接最稳定的那个。

2.异步复制模式下的数据一致性：
MySQL默认的复制模式是异步的，主库在执行完客户端提交的事务后会立即将结果返回给客户端，而不关心从库是否已经接收并处理。
这可能导致一个问题：如果主库在提交事务后崩溃，已经提交的事务可能尚未传输到从库。如果此时强行将某个从库提升为新的主库，可能导致新主库上的数据不完整。
为了保证数据一致性，你可以考虑以下方法：
半同步复制（Semi-Synchronous Replication）：在半同步复制模式下，主库会等待至少一个从库确认已经接收并处理了提交的事务，然后才返回给客户端。这确保了数据在主从之间的一致性。
组复制（MySQL Group Replication，MGR）：它由若干个节点组成一个复制组，一个事务的提交必须经过组内大多数节点决议并通过，才能得以提交。这样可以保证数据的一致性。

KAiTO 发表于 2024-3-14 14:45
1.从库选主算法：
当主服务或主服务器挂掉时，Orchestrator会自动选择一个从库作为新的主库。它使用以下算 ...

组复制可以理解，但是半同步或者增强半同步也有丢失数据的风险，我想问下增强半同步下丢失数据的场景和原理

zhangerqun 发表于 2024-3-15 13:23
组复制可以理解，但是半同步或者增强半同步也有丢失数据的风险，我想问下增强半同步下丢失数据的场景和原 ...

增强半同步下丢数的风险只在于，主从复制之间的网络链路出问题的情况下，在默认设置下，10秒主库未收到从库ack应答的情况下，会降级为异步，金融级别设置就把这个设置为无限大来规避降级为异步复制导致的丢失数据风险。

互联网一般不会这么玩。互联网的玩法是通过补数的逻辑，这个逻辑需要自己开发，orch自身并不提供，orch提供的是hook的接口，让切换前能让你插入你的脚本代码逻辑，去判断，去补数。常见的补数方法有两种： 1. 从老主拷贝binlog然后补回放到从库。2. 从binlog server拷贝binlog然后补回放到从库。