能否配置AWS Elastic Load Balancer仅在主服务器故障时转发流量至备用服务器？

这个方案完全可行，属于低成本的被动故障切换方案，完美匹配客户“不想大改应用架构但要基本冗余能力”的需求，但它不是银弹，得明确它的适用场景和潜在风险。

• ELB的健康检查天然支持主备切换：AWS ELB可以配置健康检查规则（比如检测Web根目录的/health接口、TCP端口连通性），默认会持续监控主服务器状态。一旦主服务器连续几次健康检查失败，ELB会自动把流量切到备用服务器，这部分是AWS原生功能，不需要额外开发。
• rsync+MySQL Slave能保证基本的数据一致性：用rsync定期同步主服务器的Web文件（代码、静态资源、用户上传文件等），配合MySQL主从复制同步数据库，只要同步频率设置合理（比如5-15分钟一次，甚至可以做实时同步），能把故障切换时的数据丢失控制在可接受的范围内。
• 零应用代码改造：整个方案不需要修改现有Web应用的代码，完全适配单服务器架构的应用，符合客户“不愿投入足够成本改造架构”的核心诉求。

这个方案的低成本是有代价的，几个核心问题要提前预判：

• 数据丢失风险：如果用定期rsync，两次同步之间主服务器的文件变更（比如用户刚上传的头像、生成的订单文件）会丢失；MySQL默认的异步复制模式下，主库故障时可能有未同步的binlog，导致备库数据不全。
• 服务中断不可避免：ELB的健康检查有延迟（默认30秒检查一次，连续2次失败才触发切换），加上备用服务器的服务可能需要预热（比如Java应用的JVM初始化、PHP-FPM的进程启动），用户会感受到几秒到几十秒的服务中断。
• 备用服务器资源浪费：平时备用服务器几乎没有流量，相当于闲置状态，虽然可以用EC2按需实例降低成本，但还是存在资源利用率低的问题。
• 回切流程复杂：主服务器恢复后，需要先把备用服务器上故障期间产生的新数据（比如用户在备库提交的订单）同步回主库，再手动调整ELB的流量分配，这个过程容易出错，需要提前制定回切流程。

如果想在不增加太多成本的前提下提升方案可靠性，可以做这些调整：

• 把定期rsync改成实时同步：用inotify-tools监听主服务器的文件变更事件，一旦有文件新增/修改就触发rsync同步，几乎消除文件数据丢失的风险。
• 配置MySQL半同步复制：开启半同步模式，要求至少一个Slave收到binlog后主库才提交事务，大幅降低数据库数据丢失的概率。
• 收紧ELB健康检查规则：把检查间隔缩短到10秒，失败阈值设为1次，减少故障检测和切换的延迟。
• 定期做故障切换演练：每月手动模拟一次主服务器故障，验证备用服务器是否能正常接管流量、数据是否完整，避免真出问题时手忙脚乱。

内容的提问来源于stack exchange，提问作者Deej