维护 Amazon Aurora 数据库集群
Amazon RDS 会定期对 Amazon RDS 资源执行维护。
主题
数据库集群维护更新概述
维护通常涉及对数据库集群中以下资源的更新：
-
底层硬件
-
底层操作系统（OS）
-
数据库引擎版本
针对操作系统的更新最常见的原因是安全问题。我们建议您尽快进行更新。有关操作系统更新的更多信息，请参阅应用数据库集群的更新。
维护更新期间的离线资源
一些维护项目要求 Amazon RDS 使您的数据库集群脱机一小段时间。要求资源脱机的维护项目包括必需的操作系统或数据库修补。仅对与安全性和实例可靠性相关的修补程序自动安排必需的修补。此类补丁很少发生，通常每隔几个月发生一次。它所需要的维护时间很少超过维护窗口的一小部分。
推迟的数据库实例和数据库集群修改
您已选择不立即应用的推迟的数据库集群和实例修改会在维护时段内应用。例如，您可以选择在维护时段内更改数据库实例类或集群或数据库参数组。您使用等待重启设置指定的此类修改不会显示在等待维护列表中。有关修改数据库集群的信息，请参阅修改 Amazon Aurora 数据库集群。
要查看下一个维护时段待处理的修改，请使用 describe-db-clustersPendingModifiedValues 字段。
DescribePendingMaintenanceActions API 的最终一致性
Amazon RDS DescribePendingMaintenanceActions API 采用最终一致性模型。这意味着，DescribePendingMaintenanceActions 命令的结果可能不会立即对所有后续 RDS 命令可见。当您使用之前的 API 命令后立即使用 DescribePendingMaintenanceActions 时，请记住这一点。
最终一致性可能会影响您管理维护更新的方式。例如，如果您运行 ApplyPendingMaintenanceActions 命令来更新数据库集群的数据库引擎版本，则该版本最终将对 DescribePendingMaintenanceActions 可见。在这种情况下，DescribePendingMaintenanceActions 可能表明维护操作未被应用，即使已应用也是如此。
要管理最终一致性，您可以执行以下操作：
-
请先确认数据库集群的状态，然后运行命令来对其进行修改。使用指数回退算法运行相应的
DescribePendingMaintenanceActions命令，来确保有足够的时间让前一个命令传播遍整个系统。为此，请重复运行DescribePendingMaintenanceActions命令，以几秒钟的等待时间开始，然后逐渐增加达到五分钟的等待时间。 -
增加后续命令之间的等待时间，即使
DescribePendingMaintenanceActions命令返回准确的响应，也是如此。应用指数回退算法，以几秒钟的等待时间开始，然后逐渐增加达到大约五分钟的等待时间。
查看待处理维护更新
通过使用 RDS 控制台、Amazon CLI 或 RDS API 来查看维护更新是否可用于数据库集群。如果某个更新可用，则将在 Amazon RDS 控制台上的数据库集群的维护列中指示它，如下所示。
如果没有维护更新可用于数据库集群，则它的列值为无。
如果有维护更新可用于数据库集群，则可能为以下列值：
-
必需 – 维护操作将应用于资源且不能无限期推迟。
-
available (可用) – 维护操作可用，但不会自动应用于资源。您可以手动应用它。
-
下一个窗口 – 维护操作将在下一个维护窗口期间应用于资源。
-
In progress (正在进行) – 维护操作正在应用于资源。
如果更新可用，则可执行这些操作之一：
-
如果维护值为 next window (下一时段)，请通过从 Actions (操作) 中选择 Defer upgrade (推迟升级) 来推迟维护项目。如果维护操作已经启动，则无法推迟该操作。
-
立即应用维护项目。
-
计划下一个维护时段内要开始的维护项目。
-
不执行任何操作。
要采取操作，请选择数据库集群以显示其详细信息，然后选择 Maintenance & backups (维护和备份)。将显示待处理维护项目。
维护时段确定待处理的操作何时开始，但不限制这些操作的总运行时间。维护操作不保证在维护时段结束前完成，可以在超出指定的结束时间后继续。有关更多信息，请参阅“Amazon RDS 维护时段”。
有关 Amazon Aurora 引擎更新的信息以及升级和修补这些引擎的说明，请参阅Amazon Aurora MySQL 的数据库引擎更新和Amazon Aurora PostgreSQL 更新。
您可以通过运行 describe-pending-maintenance-actions Amazon CLI 命令来查看维护更新是否可用于数据库集群。
有关应用维护更新的信息，请参阅应用数据库集群的更新。
Amazon RDS 维护时段
维护时段是每周时间间隔，在此期间会应用任何系统更改。每个数据库集群都具有每周维护时段。可以利用维护时段来控制何时进行修改和软件修补。有关调整维护时段的更多信息，请参阅调整首选数据库集群维护时段。
在应用维护时，RDS 会使用您的数据库集群上的一些资源。您可观察到对性能的影响甚微。对于数据库实例来说，在极少数情况下，可能需要多可用区故障转移才能完成维护更新。
如果在给定的周内安排了维护事件，则将在您确定的 30 分钟维护时段内启动维护。大部分维护事件也将在 30 分钟的维护时段内完成，但较大的维护事件可能需要 30 分钟以上的时间才能完成。数据库集群停止后，维护时段将暂停。
这个 30 分钟维护时段是随机从每个地区的 8 小时时间段中选择出来的。如果在创建数据库集群时未指定维护时段，则 RDS 在该星期内随机选择的某一天中分配 30 分钟的维护时段。
在下面可以找到为每个区域分配默认维护时段的时间段。
| 区域名称 | 区域 | 时间段 |
|---|---|---|
| 美国东部（弗吉尼亚州北部） | us-east-1 | 03:00–11:00 UTC |
| 美国东部（俄亥俄州） | us-east-2 | 03:00–11:00 UTC |
| 美国西部（加利福尼亚北部） | us-west-1 | 06:00–14:00 UTC |
| 美国西部（俄勒冈州） | us-west-2 | 06:00–14:00 UTC |
| 非洲（开普敦） | af-south-1 | 03:00–11:00 UTC |
| 亚太地区（香港） | ap-east-1 | 06:00–14:00 UTC |
| 亚太地区（海得拉巴） | ap-south-2 | 06:30–14:30 UTC |
| 亚太地区（雅加达） | ap-southeast-3 | 08:00–16:00 UTC |
| 亚太地区（马来西亚） | ap-southeast-5 | 09:00–17:00 UTC |
| 亚太地区（墨尔本） | ap-southeast-4 | 11:00–19:00 UTC |
| 亚太地区（孟买） | ap-south-1 | 06:00–14:00 UTC |
| Asia Pacific (Osaka) | ap-northeast-3 | 22:00–23:59 UTC |
| Asia Pacific (Seoul) | ap-northeast-2 | 13:00–21:00 UTC |
| 亚太地区（新加坡） | ap-southeast-1 | 14:00–22:00 UTC |
| 亚太地区（悉尼） | ap-southeast-2 | 12:00–20:00 UTC |
| 亚太地区（东京) | ap-northeast-1 | 13:00–21:00 UTC |
| 加拿大（中部） | ca-central-1 | 03:00–11:00 UTC |
| 加拿大西部（卡尔加里） | ca-west-1 | 18:00–02:00 UTC |
| 中国（北京） | cn-north-1 | 06:00–14:00 UTC |
| 中国（宁夏） | cn-northwest-1 | 06:00–14:00 UTC |
| Europe (Frankfurt) | eu-central-1 | 21:00–05:00 UTC |
| 欧洲地区（爱尔兰） | eu-west-1 | 22:00–06:00 UTC |
| 欧洲地区（伦敦） | eu-west-2 | 22:00–06:00 UTC |
| 欧洲（米兰） | eu-south-1 | 02:00–10:00 UTC |
| 欧洲（巴黎） | eu-west-3 | 23:59–07:29 UTC |
| 欧洲（西班牙） | eu-south-2 | 02:00–10:00 UTC |
| Europe (Stockholm) | eu-north-1 | 23:00–07:00 UTC |
| 欧洲（苏黎世） | eu-central-2 | 02:00–10:00 UTC |
| 以色列（特拉维夫） | il-central-1 | 03:00–11:00 UTC |
| 中东（巴林） | me-south-1 | 06:00–14:00 UTC |
| 中东（阿联酋） | me-central-1 | 05:00–13:00 UTC |
| 南美洲（圣保罗） | sa-east-1 | 00:00–08:00 UTC |
| Amazon GovCloud（美国东部） | us-gov-east-1 | 17:00–01:00 UTC |
| Amazon GovCloud（美国西部） | us-gov-west-1 | 06:00–14:00 UTC |
Aurora 数据库集群的自动次要版本升级
自动次要版本升级设置指定 Aurora 是否自动将升级应用于您的数据库集群。这些升级包括新的次要版本，而次要版本包括其他功能以及补丁（其中包含错误修复）。
原定设置情况下，此设置处于启用状态。对于每个新的数据库集群，为此设置选择适当的值。此值基于其重要性、预期生命周期以及每次升级后执行的验证测试量。
有关打开或关闭自动次要版本升级设置的说明，请参阅以下内容：
重要
我们强烈建议，对于新的和现有的数据库集群，将此设置应用于数据库集群，而不是单独应用于集群中的数据库实例。如果对集群中的任何数据库实例关闭了此设置，则不会自动升级数据库集群。
下表显示了在集群和实例级别应用自动次要版本升级设置时的工作原理。
| 操作 | 集群设置 | 实例设置 | 是否自动升级集群？ |
|---|---|---|---|
| 您在数据库集群上将其设置为 True。 | True | 对于所有新实例和现有实例，均为 True | 是 |
| 您在数据库集群上将其设置为 False。 | False | 对于所有新实例和现有实例，均为 False | 否 |
|
之前在数据库集群上将其设置为 True。 您至少在一个数据库实例上将其设置为 False。 |
更改为 False | 对于一个或多个实例为 False | 否 |
|
之前在数据库集群上将其设置为 False。 您至少对于一个数据库实例（但并非所有实例）将其设置为 True。 |
False | 对于一个或多个实例（但并非所有实例）为 True | 否 |
|
之前在数据库集群上将其设置为 False。 您在所有数据库实例上将其设置为 True。 |
更改为 True | 对于所有实例为 True | 是 |
事先通过 Amazon RDS 数据库集群事件（类别为 maintenance，ID 为 RDS-EVENT-0156）与自动次要版本升级进行通信。有关更多信息，请参阅 Aurora 的 Amazon RDS 事件类别和事件消息。
自动升级在维护时段发生。如果数据库集群中的各个数据库实例的维护时段与集群维护时段不同，则集群维护时段优先。
有关 Aurora PostgreSQL 引擎更新的更多信息，请参阅Amazon Aurora PostgreSQL 更新。
有关 Aurora MySQL 的自动次要版本升级设置的更多信息，请参阅 启用 Aurora MySQL 次要版本之间的自动升级。有关 Aurora MySQL 的引擎更新的一般信息，请参阅 Amazon Aurora MySQL 的数据库引擎更新。
按照使用控制台、CLI 和 API 修改数据库集群中的常规程序进行操作。
- 控制台
-
在修改数据库集群页面的维护部分中，选中允许自动次要版本升级复选框。
- Amazon CLI
-
调用 modify-db-cluster Amazon CLI 命令。为
--db-cluster-identifier选项指定数据库集群的名称，并为--auto-minor-version-upgrade选项指定true。（可选）指定--apply-immediately选项，立即为数据库集群启用此设置。 - RDS API
-
调用 ModifyDBCluster API 操作，并为
DBClusterIdentifier参数指定数据库集群的名称，为AutoMinorVersionUpgrade参数指定true。（可选）将ApplyImmediately参数设置为true，立即为数据库集群启用此设置。
按照修改数据库集群中的数据库实例中的常规程序进行操作。
- 控制台
-
在修改数据库实例页面的维护部分中，选中允许自动次要版本升级复选框。
- Amazon CLI
-
调用 modify-db-instance Amazon CLI 命令。为
--db-instance-identifier选项指定数据库实例的名称，为true选项指定--auto-minor-version-upgrade。（可选）指定--apply-immediately选项，立即为数据库实例启用此设置。为集群中的每个数据库实例运行单独的modify-db-instance命令。 - RDS API
-
调用 ModifyDBInstance API 操作，并为
DBInstanceIdentifier参数指定数据库集群的名称，为AutoMinorVersionUpgrade参数指定true。（可选）将ApplyImmediately参数设置为true，立即为数据库实例启用此设置。为集群中的每个数据库实例调用单独的ModifyDBInstance操作。
您可以使用如下 CLI 命令来检查 Aurora MySQL 集群中所有数据库实例的 AutoMinorVersionUpgrade 设置的状态。
aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
该命令产生的输出类似于以下内容：
[ { "DBInstanceIdentifier": "db-writer-instance", "DBClusterIdentifier": "my-db-cluster-57", "AutoMinorVersionUpgrade": true }, { "DBInstanceIdentifier": "db-reader-instance1", "DBClusterIdentifier": "my-db-cluster-57", "AutoMinorVersionUpgrade": false }, { "DBInstanceIdentifier": "db-writer-instance2", "DBClusterIdentifier": "my-db-cluster-80", "AutoMinorVersionUpgrade": true }, ... output omitted ...
在此示例中，数据库集群 my-db-cluster-57 的允许自动次要版本升级处于关闭状态，因为对于集群中的其中一个数据库实例关闭了此功能。
选择 Aurora MySQL 维护更新的频率
您可以控制每个数据库集群是经常还是很少进行 Aurora MySQL 升级。最佳选择取决于 Aurora MySQL 使用情况以及在 Aurora 上运行的应用程序的优先级。有关不太需要频繁升级的 Aurora MySQL 长期稳定性 (LTS) 版本的信息，请参阅 Aurora MySQL 长期支持 (LTS) 版本。
如果符合以下部分或全部条件，您可能会选择很少升级 Aurora MySQL 集群：
-
对于 Aurora MySQL 数据库引擎的每次更新，应用程序的测试周期需要很长的时间。
-
很多数据库集群或很多应用程序运行相同的 Aurora MySQL 版本。您希望同时升级所有数据库集群和关联的应用程序。
-
您同时使用 Aurora MySQL 和 RDS for MySQL。您希望将 Aurora MySQL 集群和 RDS for MySQL 数据库实例与同一级别的 MySQL 保持兼容。
-
Aurora MySQL 应用程序位于生产环境中或在其他方面对业务至关重要。除了在极少数情况下应用关键补丁以外，您无法承受升级停机。
-
Aurora MySQL 应用程序不受在后续 Aurora MySQL 版本中解决的性能问题或功能差异的限制。
如果上述因素适用于您的情况，您可以限制 Aurora MySQL 数据库集群的强制升级次数。为此，您可以在创建或升级该数据库集群时选择称为“长期支持”(LTS) 版本的特定 Aurora MySQL 版本。这样做可以最大限度减少该数据库集群的升级周期数、测试周期数以及与升级相关的中断次数。
如果符合以下部分或全部条件，您可能会选择经常升级 Aurora MySQL 集群：
-
应用程序的测试周期简单明了。
-
应用程序仍处于开发阶段。
-
数据库环境使用各种不同的 Aurora MySQL 版本或 Aurora MySQL 和 RDS for MySQL 版本。每个 Aurora MySQL 集群具有自己的升级周期。
-
在增加 Aurora MySQL 使用量之前，您正在等待改进特定的性能或功能。
如果上述因素适用于您的情况，您可以使 Aurora 更频繁地应用重要升级。为此，将 Aurora MySQL 数据库集群升级到比 LTS 版本更高的 Aurora MySQL 版本。这样做可以使您更快地获得最新的性能增强、错误修复和功能。