我正在尝试为Aurora MySQL创建一个具有成本效益、可维护性且几乎不会出现故障的灾难恢复计划。
我希望在两个不同的区域有两个读/写数据库，它们可以是单独的数据库，分别称为PRIMARY-US-EAST-1和BACKUE-US-EAST-2。我还希望在PRIMARY-US-EAST-1到BACKUS-US-EAST-2之间进行双向复制。只有一个数据库将始终连接，因此冲突不是问题。如果区域us-East-1关闭，我要做的就是触发一个指向us-East-2的dns开关，因为Backup-us-East-2已经更新了。
我已经查看了Aurora Global数据库，但这需要将辅助区域中的读取副本升级为主区域，然后更新DNS以从区域中断中恢复。我喜欢跨多个区域进行数据复制的0工作，但我不喜欢在此过程中失去新资源的可维护性，因为如果通过lambda或手动创建，新创建的资源(集群/副本)在CDK中将不可维护。
我的要求有可能实现吗？如果是，有没有人知道可以在Backup-US-East-2之间复制数据的复制解决方案？
更新1：
一个潜在的解决方案是使用cdk建立Aurora MySQL资源PRIMARY-US-EAST-1和BACKUS-EAST-2。使用AWS数据库迁移服务实现连续复制，使它们保持同步。使用lambda检测区域中断，然后执行DNS切换以指向Backup-US-East-2。唯一的后续任务将是使PRIMARY-US-EAST-1与BACKUS-US-EAST-2同步。
1条答案
按热度按时间vxf3dgd41#
整个地区的停机非常罕见(请参阅https://awsmaniac.com/aws-outages/)。我对您在尝试自动检测和故障转移这类情况上投入了多少精力持谨慎态度。如果这是可能的话，做这件事需要做很多工作。要做到这一点非常困难，很难测试，也很难继续工作。存在大量误报故障转移事件或失控的反复无常的可能性。所有公司都在尝试创建全自动故障转移解决方案，但都以失败告终。我敢打赌，即使是FAANG的公司也无法做到这一点，而是依靠现场可靠性工程师来应对停电。
在国际海事组织，更具成本效益的做法是开发一本写得很好的运行手册，用于手动切换到其他区域，然后确保您的员工定期练习区域故障切换。这确保文档是最新的，工具可以工作，团队熟悉步骤。
域名系统更新速度很慢。相反，我建议使用某种类型的代理服务器，这样您的应用程序就可以使用单个端点，并且代理可以在后端切换到动态使用哪个数据库。这基本上就是MySQL Router的用途，我还用Envoy Proxy做了一个概念验证(抱歉，我不能再访问该代码了)，我想您可以用ProxySQL做同样的事情。
我的观点是，AWS在RDS和Aurora的故障转移方面仍有改进的潜力。它可以工作，但可能会导致长达几分钟的停机时间。因此，与手动故障转移相比，这几乎算不上什么改进。也就是说，某个OnCall工程师被寻呼，检查一些 Jmeter 板以确认这是合法的停机，然后执行Runbook以执行手动故障转移。