当您必须在AWS上运行可伸缩应用程序时，您的数据库也必须可伸缩。 扩展无状态应用程序层更容易，在无状态应用程序层中，每个节点大部分都是可使用的-即使3节点集群中的一个节点发生故障，您也可以启动另一个节点，而没人注意到。

数据库层是有状态的，因此存在丢失数据的风险。 仅拥有一个节点不是一个选择，因为一个节点总是会宕机，这意味着停机。 因此，您需要在群集中有多个节点，以确保您的应用程序具有高可用性并具有容错能力（我不会在术语上有所差异）。

我在说什么数据库？ 没关系 它可以是SQL或NoSQL数据库-每个数据库都有某种形式的集群。 无论是主动-主动还是主动-被动。

现在，特别是对于AWS，您可以选择RDS（或其他托管选项），它将为您处理。 但是，如果没有托管选项（例如Cassandra），或者您不觉得托管选项可以为您提供足够的控制权，或者价格更高，或者您所需的版本不可用，则必须自己管理数据库层。 我不会详细介绍如何配置特定于数据库的集群-您应该查看特定数据库的文档。 我将尝试提供一些技巧，以提示如何安全地运行支持数据库集群的基础架构。

这里是自动缩放组。 它们允许您有一组相同的节点（基于启动配置），并且ASG通过在现有节点发生故障时启动新节点来确保您始终至少有X个健康节点（它们可以自动杀死不健康的节点（即，节点）无法响应自动运行状况检查））。

这对于应用程序节点来说真是太棒了，但是对于数据库节点来说可能是个问题。 如果数据库节点一段时间没有响应，则不一定要杀死它。 这就是为什么我在下面汇总了一些避免陷阱的提示的原因。 不幸的是，其中的许多功能无法通过CloudFormation获得，因此您必须手动进行操作。 并记录它们，以防万一您需要重新创建堆栈时不会忘记：

• 将最小节点数设置为1。它可以防止在尝试其他不相关的ASG时意外将“所需”计数设置为0。
• 确保已为每个实例启用终止保护，并且已根据ASG启用了扩展终止保护。
• 在ASG设置中，有“悬浮过程”。 确保暂停“终止”和“替换不健康”。
• 确保在启动配置中，不会终止EBS卷。 考虑到您已禁用所有终止选项，为什么需要它？ 好吧，由于底层主机的问题，终止有时可能会发生，或者可能安排了某个节点的退役
• 如果需要从EBS卷还原，请执行以下操作：1.让ASG产生一个新节点2.将“启动”暂时添加到已暂停的操作中3.分离节点的根卷4.将旧的EBS卷附加到/ dev / xvda 5.启动节点。
• 设置生命周期策略（通过CloudFormation或手动）以对数据库EBS卷进行备份。 确保为卷设置了正确的标签（并且只能手动完成）
• 确保ASG可以在多个可用区域中生成实例（以防实例掉线）

如果您遵循此步骤，则您的自动伸缩组将不会完全像自动伸缩组那样运行。 您仍然可以配置为在增加负载的情况下自动增加节点数，但是对于数据库层而言，其余功能很少是一个好主意–您宁愿解决现有计算机上的数据库问题，即使暂时停止也是如此。不只是产生新的。

但是你应该拥抱失败。 即使具有所有终止保护，您也必须假设一切都可能失败并消亡，并且应该有一条清晰的路径来还原节点。

翻译自: https://www.javacodegeeks.com/2020/02/running-a-safe-database-cluster-in-aws-with-auto-scaling-groups.html