# 切换 Amazon Aurora 中的蓝绿部署
*切换*将绿色环境中的数据库集群（包括其数据库实例）转换为生产数据库集群。在切换之前，生产流量将路由到蓝色环境中的集群。切换后，生产流量将路由到绿色环境中的数据库集群。
*切换* 蓝绿部署不同于在蓝绿部署中*提升* 绿色数据库集群。如果您通过从**操作**菜单中选择**提升**来手动提升绿色数据库集群，则蓝色环境与绿色环境之间的复制会中断，蓝绿部署将进入**无效配置**状态。
**Topics**
+ [切换超时](#blue-green-deployments-switching-timeout)
+ [切换防护机制](#blue-green-deployments-switching-guardrails)
+ [切换操作](#blue-green-deployments-switching-actions)
+ [切换最佳实践](#blue-green-deployments-switching-best-practices)
+ [在切换之前验证 CloudWatch 指标](#blue-green-deployments-switching-over-cloudwatch)
+ [在切换之前监控副本滞后](#blue-green-deployments-monitor-replica-lag)
+ [切换蓝绿部署](#blue-green-deployments-switching-over)
+ [切换后](#blue-green-deployments-switching-after)
## 切换超时
您可以指定 30 秒与 3600 秒（一小时）之间的切换超时时间。如果切换所花的时间超过指定的持续时间，则所有更改都将回滚，并且不会对任一环境进行任何更改。默认的超时期间为 300 秒（5 分钟）。
## 切换防护机制
当您开始切换时，Amazon RDS 会运行一些基本检查，以测试蓝绿环境是否准备好进行切换。这些检查称为*切换防护机制*。如果环境还没有准备好进行切换，这些切换防护机制可以防止发生切换。因此，它们可以避免比预期更长的停机时间，并防止切换开始时可能导致的蓝色和绿色环境之间的数据丢失。
Amazon RDS 在绿色环境中运行以下防护机制检查：
+ **复制运行状况** - 检查绿色数据库集群复制状态是否为正常运行。绿色数据库集群是蓝色数据库集群的副本。
+ **复制滞后** - 检查绿色数据库集群的副本滞后是否在切换的允许范围内。允许的限制基于指定的超时期间。副本滞后表示绿色数据库集群滞后于其蓝色数据库集群的程度。有关更多信息，请参阅 [在切换之前监控副本滞后](#blue-green-deployments-monitor-replica-lag)。
+ **主动写入** - 确保绿色数据库集群上没有主动写入。
Amazon RDS 在蓝色环境中运行以下防护机制检查：
+ **外部复制** – 对于 Aurora PostgreSQL，请确保蓝色环境不是自行管理的逻辑源（发布者）或副本（订阅用户）。如果是，建议您删除蓝色环境中所有数据库的自行管理的复制插槽和订阅，继续切换，然后重新创建它们以恢复复制。对于 Aurora MySQL，请确保蓝色数据库不是外部二进制日志副本。如果是，请确保它未在主动复制。
+ **长时间运行的活动写入** - 确保蓝色数据库集群上没有长时间运行的活动写入，因为它们会增加副本滞后。
+ **长时间运行的 DDL 语句** - 确保蓝色数据库集群上没有长时间运行的 DDL 语句，因为它们会增加副本滞后。
+ **不支持的 PostgreSQL 更改** – 对于使用逻辑复制的 Aurora PostgreSQL，确保在蓝色环境中没有进行 DDL 更改，也没有添加或修改大型对象。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。
如果 Amazon RDS 检测到不支持的 PostgreSQL 更改，它会将复制状态更改为 `Replication degraded`，并通知您蓝绿部署无法进行切换。要继续切换，建议您删除并重新创建蓝绿部署和所有绿色数据库。为此，请选择**操作**、**使用绿色数据库删除**。
## 切换操作
当您切换蓝绿部署时，RDS 会执行以下操作：
1. 运行防护机制检查，以验证蓝色和绿色环境是否已准备好进行切换。
1. 在两个环境中停止对数据库集群进行新的写入操作。
1. 在这两个环境中删除与数据库实例的连接，并且不允许新的连接。
1. 等待复制在绿色环境中赶上进度，以便绿色环境与蓝色环境同步。
1. 重命名这两个环境中的数据库集群和数据库实例。
RDS 重命名绿色环境中的数据库集群和数据库实例，以匹配蓝色环境中相应的数据库集群和数据库实例。例如，假设蓝色环境中数据库实例的名称为 `mydb`。还假设绿色环境中相应的数据库实例的名称为 `mydb-green-abc123`。在切换期间，绿色环境中数据库实例的名称更改为 `mydb`。
RDS 通过在当前名称后面附加 `-oldn`（其中 `n` 是一个数字）来重命名蓝色环境中的数据库集群和数据库实例。例如，假设蓝色环境中数据库实例的名称为 `mydb`。切换后，数据库实例名称可能为 `mydb-old1`。
RDS 还重命名绿色环境中的端点，以匹配蓝色环境中的相应端点，以便无需更改应用程序。
1. 允许在这两种环境中连接到数据库。
1. 允许在新的生产环境中对数据库集群进行写入操作。
切换之后，先前的生产数据库集群仅允许读取操作。即使您对数据库集群启用写入，它仍为只读的，直到您删除蓝绿部署。
您可以使用 Amazon EventBridge 监控切换的状态。有关更多信息，请参阅 [蓝绿部署事件](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)。
在切换期间，蓝色环境中的标签会替换绿色环境中相应资源上的所有标签。在此过程中，您直接添加到绿色环境资源的所有标签都将被覆盖。有关标签的更多信息，请参阅[为 Amazon Aurora 和Amazon RDS 资源添加标签](USER_Tagging.md)。
如果切换开始后由于任何原因在完成之前停止，则所有更改都将回滚，并且不会对任一环境进行任何更改。
## 切换最佳实践
在切换之前，我们强烈建议您通过完成以下任务来遵循最佳实践：
+ 在绿色环境中彻底测试资源。确保它们正常高效地运行。
+ 监控相关的 Amazon CloudWatch 指标。有关更多信息，请参阅 [在切换之前验证 CloudWatch 指标](#blue-green-deployments-switching-over-cloudwatch)。
+ 确定最佳切换时间。
在切换期间，两个环境中的数据库都会切断写入操作。确定生产环境中流量最低的时间。长时间运行的事务（例如活动的 DDL）会延长您的切换时间，从而延长生产工作负载的停机时间。
如果您的数据库集群和数据库实例上有大量连接，请考虑在切换蓝绿部署之前，手动将连接减少到应用程序所需的最低数量。实现此目标的一种方法是创建一个脚本，该脚本监控蓝绿部署的状态，并在检测到状态已更改为 `SWITCHOVER_IN_PROGRESS` 时开始清理连接。
+ 确保两个环境中的数据库集群和数据库实例均处于 `Available` 状态。
+ 确保绿色环境中的数据库集群运行状况良好且正在复制。
+ 确保您的网络和客户端配置不会将 DNS 缓存存活时间（TTL）增加到五秒以上，这是 Aurora DNS 区域的默认值。否则，应用程序将在切换后继续向蓝色环境发送写入流量。
+ 对于使用逻辑复制的 Aurora PostgreSQL 蓝绿部署，执行以下操作：
+ 在切换之前，请查看逻辑复制限制并采取任何必需的操作。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。
+ 运行 `ANALYZE` 操作以刷新 `pg_statistics` 表。这样可以降低切换后出现性能问题的风险。
+ 在启动蓝绿部署切换之前，请验证您的应用程序没有在会话级别覆盖 `default_transaction_read_only` 参数。在切换期间，此参数在绿色环境写入器上设置为 `on`，以防止在升级完成之前写入。如果您的应用程序或事务将此配置覆盖为 `off`，则应用程序可能会在切换过程中向绿色环境写入数据。如果切换必须回滚，则这些写入在蓝色环境中不可用，要求您手动解决数据不一致问题。我们强烈建议您在继续切换之前审计应用程序查询，以确保它们遵循 `default_transaction_read_only` 设置。
**注意**
在切换期间，您无法修改切换中包含的任何数据库集群。
## 在切换之前验证 CloudWatch 指标
在切换蓝绿部署之前，建议您检查 Amazon CloudWatch 中以下指标的值。
+ `DatabaseConnections` – 使用此指标估算蓝绿部署上的活动水平，并在切换之前确保该值处于部署的可接受水平。如果开启了性能详情，则 `DBLoad` 是更准确的指标。
+ `ActiveTransactions` – 如果在任何数据库实例的数据库参数组中 `innodb_monitor_enable` 设置为 `all`，请使用此指标来查看是否存在大量可能阻止切换的活跃事务。
有关更多信息，请参阅 [Amazon Aurora 的 Amazon CloudWatch 指标](Aurora.AuroraMonitoring.Metrics.md)。
## 在切换之前监控副本滞后
在您切换蓝绿部署之前，请确保副本滞后接近于零，以减少停机时间。
### Aurora MySQL
对于 MySQL 蓝绿部署，请在绿色环境中检查 `AuroraBinlogReplicaLag` CloudWatch 指标，以确定当前的副本滞后。有关更多信息，请参阅 [诊断并解决只读副本之间的滞后](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。
### Aurora PostgreSQL
对于的 PostgreSQL 蓝绿部署，请在蓝色环境中检查 `OldestReplicationSlotLag` CloudWatch 指标，以确定当前的副本滞后。有关更多信息，请参阅 [Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
此外，您还可以在蓝色环境中运行以下 SQL 查询：
```
SELECT slot_name,
confirmed_flush_lsn as flushed,
pg_current_wal_lsn(),
(pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';
slot_name | flushed | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8 | 37192
```
`confirmed_flush_lsn` 表示发送到副本的最后一个日志序列号（LSN）。`pg_current_wal_lsn` 表示数据库现在的位置。如果 `lsn_distance` 为 0，则表示已捕获副本。
## 切换蓝绿部署
您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 切换蓝绿部署。
### 控制台
**切换蓝绿部署**
1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。
1. 在导航窗格中，选择 **Databases**（数据库），然后选择要切换的蓝绿部署。
1. 对于 **Actions**（操作），选择 **Switch over**（切换）。
将出现 **Switch over**（切换）页面。
![\[切换蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switch-over-aurora.png)
1. 在 **Switch over**（切换）页面上，查看切换摘要。确保两个环境中的资源都符合您的期望。如果不符合预期，请选择 **Cancel**（取消）。
1. 对于**超时设置**，输入切换的时间限制。
1. 如果您的集群运行 Aurora PostgreSQL，请查看并确认切换前建议。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。
1. 选择 **Switch over**（切换）。
### AWS CLI
要使用 AWS CLI 切换蓝绿部署，请使用带有以下选项的 [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) 命令：
+ `--blue-green-deployment-identifier` – 指定蓝绿部署的资源 ID。
+ `--switchover-timeout` – 指定切换的时间限制，以秒为单位。默认值为 300。
**Example 切换蓝绿部署**
对于 Linux、macOS 或 Unix：
```
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--switchover-timeout 600
```
对于：Windows
```
aws rds switchover-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--switchover-timeout 600
```
### RDS API
要使用 Amazon RDS API 切换蓝绿部署，请使用带有以下参数的 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) 操作：
+ `BlueGreenDeploymentIdentifier` – 指定蓝绿部署的资源 ID。
+ `SwitchoverTimeout` – 指定切换的时间限制，以秒为单位。默认值为 300。
## 切换后
切换后，将保留先前蓝色环境中的数据库集群和数据库实例。标准成本适用于这些资源。蓝色和绿色环境之间的复制和二进制日志记录会停止。
RDS 通过在当前资源名称后面附加 `-oldn`（其中 `n` 是一个数字）来重命名蓝色环境中的数据库集群和数据库实例。蓝色数据库集群被强制进入只读状态。即使您启用了写入操作，它仍为只读的，直到您删除蓝绿部署。RDS 会命名绿色环境 `-newn` 中的数据库集群和数据库实例。
如果您删除蓝绿部署资源，RDS 会保留 `-oldn` 和 `-newn` 资源。
![\[切换蓝绿部署之后\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-after-switchover-aurora.png)
### 更新使用者的父节点
RDS 提供完全托管式只读副本。但是，它还提供用于设置自托管式副本（也称为*外部副本*）的选项。外部副本允许您使用第三方资源作为复制目标。
切换 Aurora MySQL 蓝绿部署后，如果蓝色数据库集群在切换之前有任何外部副本或二进制日志使用者，则必须在切换后更新其父节点以保持复制连续性。
**更新父节点**
1. 切换后，之前处于绿色环境中的写入器数据库实例会发出一个事件，其中包含主日志文件名和主日志位置。要找到该事件，请导航到 RDS 控制台，然后从左侧导航窗格中选择**事件**。
1. 在切换之前，按源为旧绿色写入器数据库实例名称的事件进行筛选。
1. 找到包含二进制日志坐标的事件。事件消息类似于：`Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`。
1. 确保使用者或副本已应用来自旧蓝色环境的所有二进制日志。然后，使用提供的二进制日志坐标在使用者上恢复复制。例如，如果您在 EC2 上运行 MySQL 副本，则可以使用下列命令：
**MySQL 8.0.22 及更低的主要和次要版本**
```
CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
```
**MySQL 8.0.23 及更高的主要和次要版本**
```
CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
```