备库压力大：

• 备库设备配置通常低于主库，尤其是在主从模式下，备库既需处理来自主库的 binlog 又需作为读据库提供服务，工作负荷加重。

大事务：

• 长时间运行的事务会导致主库直到完成当前事务后才发 write 到 binlog，进而影响从库的延迟。

配置差异：

• 主从库参数设置不一致，可能导致资源冲突或 IO 操作效率低下。

从库资源竞争：

• 一台服务器上部署多个从库或备库资源紧张，尤其是 IO 概率明显增加。

备库执行状态：

• 备库处于延迟状态或执行备份操作占用 CPU 资源。

表结构问题：

• 主库依托索引优化数据修改，但从库需进行全表扫描。通过调整 slave_rows_search_algorithms 参数可以优化部分延迟。

延迟备库或空间不足：

• 延迟备库未能及时同步 transactions，或备库存储资源不足。

初始状态确认：

• 检查备库的 seconds_behind_master 是否小于设定阈值（如-5秒），如不满足则重试。

主库变只读：

• 为了防止数据写入冲突，主库设置为只读状态。

备库变可读写：

• 只当备库的 seconds_behind_master 变为 0 时才能变更状态。

切换完成：

• 将业务请求切向备库 B，同时关闭主库的只读模式。

可靠性优先策略：

• 在切换过程中保持系统不可写，确保数据完整性。优点显然是数据一致性，但可能造成短期服务中断。

可用性优先策略：

• 本地直接切向备库，降低整体系统的延迟时间。可用性优先策略可能导致数据不一致问题，只适用于特定场景。