希望每周六从 Live DB 刷新 Stage DB，以便我们始终使用实时数据更新 Stage DB。
开放积分：
执行此操作的正确步骤是什么？请帮忙。
嗯，我想您可以设置一个自动化流程，每周六从 Live 数据库刷新 Stage 数据库。这将最大限度地减少停机时间并优化 AWS 资源。以下是我解决这个问题的想法：
1。最大限度地减少停机时间
如果您想最大限度地减少停机时间，您应该考虑使用复制策略或执行增量刷新，而不是使用完整快照。
深入研究复制策略，通过将数据从“主”数据库（Live）同步和复制到一个或多个“辅助”数据库（Stage），这一流程或过程主要可以是自动的——通常是实时的。因此，当实时数据库中发生更改时，该更改会自动镜像到阶段数据库中。
优点：通过复制，您可以保持 Stage 数据库始终更新，而无需制作数据的完整副本，更重要的是，无需停止数据库来执行必要的更新。这可以最大限度地减少停机时间，因为您不需要断开服务或停止 Stage 数据库。
2。增量刷新
这将涉及仅更新自上次更新以来的新数据或修改过的数据（在您的情况下，自上周六以来），这与复制整个数据库的完整快照不同。
优点：通过仅处理新的或修改的数据，此过程显然会消耗更少的时间。
3.更新选项
我们有 Lambda 函数：您可以选择 AWS Lambda 来协调刷新过程。使用 Lambda，您可以：
执行查询来识别新数据并将其添加到 Stage。 启动快照和恢复。 在处理数百万条记录时，Lambda 很可能会受到限制——最常见的是时间和内存方面的限制。如果是这种情况，请使用 AWS Step Functions 管理工作流程逻辑，将工作分配为多个步骤。
4。完整快照与新数据
完整快照：这将是更安全方法的标准 - 您每周创建实时数据库的快照并将其恢复到阶段数据库。我们保证什么？舞台将与现场完全同步。这意味着什么？停机时间更长。 新数据：如果您有可管理的数据量，您可以选择每周增量更新，仅同步修改的数据或新数据。
5。建议步骤
识别新数据：配置更改数据捕获 (CDC) 流程或使用行上的时间戳来识别新数据或修改后的数据。 自动化：对于此步骤，我建议使用 EventBridge 安排每周六执行 Lambda 或 Step Functions。 同步：一旦您做出选择（无论是完整快照还是增量），您就可以执行更新。对于快照，请使用命令 CREATE DB SNAPSHOT 和 RESTORE DB INSTANCE。对于增量更新，我们使用 Lambda 中的 INSERT 或 UPDATE 命令。 验证：在将流量重定向到 Stage 之前，确保同步数据正确（如有必要）。
6。您可以使用的其他工具
DMS（数据库迁移服务）：如果您想减少手动工作量，我建议使用 AWS DMS 来处理增量迁移。 Aurora 副本：我提出的另一个选项是为 Stage 配置 Aurora 只读副本，它与实时数据库保持同步。 请记住：
您可以根据停机时间要求和数据大小在完整快照或增量更新之间进行选择。在许多情况下，使用 DMS 等工具进行增量复制会更加高效。
我希望我已经澄清了一些事情，并且您可以做出明智的决定。干杯！