重启 Amazon Aurora 数据库集群或 Amazon Aurora 数据库实例 - Amazon Aurora
重启 Aurora 集群内的数据库实例在具有读取可用性的情况下重启 Aurora 集群在没有读取可用性功能的情况下重启 Aurora 集群检查 Aurora 集群和实例的正常运行时间Aurora 重启操作示例
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

重启 Amazon Aurora 数据库集群或 Amazon Aurora 数据库实例

通常出于维护原因，您可能需要重启数据库集群或该集群内的某些实例。例如，假设您修改了参数组中的参数或将不同参数组与集群关联起来。在这些情况下，您必须重启集群才能使更改生效。同样，您可以重启集群中的一个或多个读取器数据库实例。您可以为单个实例安排重启操作，以最大限度地减少整个集群的停机时间。

重启集群中每个数据库实例所需的时间取决于重启时的数据库活动，还取决于特定数据库引擎的恢复过程。如果可行，请在开始重启过程前减少该特定实例上的数据库活动。这样做可以减少重启数据库所需的时间。

您只能在集群中的每个数据库实例处于可用状态时重新启动该实例。由于多种原因，数据库实例可能无法使用。其中包括正处于停止状态的集群、正在对实例应用的修改以及维护窗口操作（如版本升级）。

重启数据库实例会重新启动数据库引擎流程。重启数据库实例将导致短暂中断，在此期间，数据库实例状态将设置为正在重启。

注意

如果数据库实例未使用对其关联的数据库参数组所做的最新更改，则 Amazon Web Services Management Console 将显示状态为 pending-reboot 的数据库参数组。pending-reboot 参数组状态不会在下一个维护时段期间导致自动重启。要向该数据库实例应用最新的参数更改，请手动重启数据库实例。有关参数组的更多信息，请参阅 使用参数组。

重启 Aurora 集群内的数据库实例

此过程是您在利用 Aurora 执行重启时采取的最重要的操作。许多维护过程都涉及按特定顺序重启一个或多个 Aurora 数据库实例。

重启数据库实例

  1. 登录Amazon Web Services Management Console并通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/rds/。

  2. 在导航窗格中，选择数据库，然后选择要重启的数据库实例。

  3. 对于操作，选择重启。

    将显示重启数据库实例页。

  4. 选择重新引导以重新引导您的数据库实例。

    或者选择 Cancel（取消）。

要使用 Amazon CLI 重新引导数据库实例，请调用 reboot-db-instance 命令。

对于 Linux、macOS 或 Unix：

aws rds reboot-db-instance \
    --db-instance-identifier mydbinstance

对于 Windows：

aws rds reboot-db-instance ^
    --db-instance-identifier mydbinstance

要使用 Amazon RDS API 重启数据库实例，请调用 RebootDBInstance 操作。

在具有读取可用性的情况下重启 Aurora 集群

在具有读取可用性功能的情况下，您可以重启 Aurora 集群的写入器实例，而无需重启集群中的读取器实例。这样做有助于在重启写入器实例时维持集群的高可用性，以进行读取操作。您可以稍后按照方便的时间安排重启读取器实例。例如，对于生产集群，您可以一次重启一个读取器实例，但只有在主实例完成重启后才能开始。对于您重启的每个数据库实例，请按照 重启 Aurora 集群内的数据库实例 中的步骤操作。

读取可用性功能在 Aurora MySQL 2.10 及更高版本中可用。对于 Aurora PostgreSQL，原定设置情况下，此功能在以下版本中可用：

  • 15.2 及更高的 15 版本

  • 14.7 及更高的 14 版本

  • 13.10 及更高的 13 版本

  • 12.14 及更高的 12 版本

有关 Aurora PostgreSQL 中读取可用性功能的更多信息，请参阅提高 Aurora 副本的读取可用性。

在推出此功能之前，重启主实例会同时导致每个读取器实例重启。如果您的 Aurora 集群运行的是旧版本，请改用在没有读取可用性功能的情况下重启 Aurora 集群中的重启过程。

重要

对于 Aurora 全局数据库，在具有读取可用性功能的 Aurora 集群中对重启行为的更改有所不同。如果重启 Aurora 全局数据库中主集群的写入器实例，则主集群中的读取器实例仍可用。但是，所有辅助集群中的数据库实例都会同时重启。

在对集群参数组进行更改后，您需要经常重启集群。您可以按照 使用参数组 中的过程进行参数更改。假设您重启 Aurora 集群中的写入器数据库实例，以便对集群参数应用更改。部分或全部读取器数据库实例可能会继续使用旧的参数设置。但是，不同的参数设置不会影响集群的数据完整性。任何影响数据文件条理性的集群参数只能由写入器数据库实例使用。

例如，在 Aurora MySQL 集群中，您可以先更新写入器实例上的集群参数（如 binlog_format 和 innodb_purge_threads），然后再对读取器实例进行相同的操作。只有写入器实例需要编写二进制日志并清除撤消记录。对于更改查询解释 SQL 语句或查询输出方式的参数，您可能需要注意立即重启读取器实例。这样做是为了避免查询期间出现意外的应用程序行为。例如，假设您更改了 lower_case_table_names 参数并重启了写入器实例。在这种情况下，只有全部重启后，读取器实例才可能可以访问新建的表。

有关所有 Aurora MySQL 集群参数的列表，请参阅 集群级别的参数。

有关所有 Aurora PostgreSQL 集群参数的列表，请参阅Aurora PostgreSQL 集群级参数。

提示

如果您的集群正在处理高吞吐量的工作负载，Aurora MySQL 可能仍会重启部分读取器实例以及写入器实例。

在故障转移操作过程中，重新启动次数减少也会如此。Aurora MySQL 在故障转移期间仅重启写入器数据库实例和故障转移目标。集群中的其他读取器数据库实例仍然可以通过与读取器终端节点的连接来继续处理查询。因此，您可以通过在集群中拥有多个读取器数据库实例来提高故障转移期间的可用性。

在没有读取可用性功能的情况下重启 Aurora 集群

如果没有读取可用性功能，则是通过重启整个 Aurora 数据库集群的写入器数据库实例来重启该集群。为此，请按照重启 Aurora 集群内的数据库实例中的过程操作

重启写入器数据库实例还会为集群中的每个读取器数据库实例启动重启操作。这样，任何集群范围内的参数更改都将同时应用于所有数据库实例。但是，重启所有数据库实例会导致集群短暂中断。在写入器数据库实例完成重启并变为可用状态之前，读取器数据库实例一直不可用。

这种重启行为适用于在 Aurora MySQL 2.9 及更低版本中创建的所有数据库集群。对于 Aurora PostgreSQL，此行为适用于以下版本：

  • 14.6 及更低的 14 版本

  • 13.9 及更低的 13 版本

  • 12.13 及更低的 12 版本

  • 所有 PostgreSQL 11 版本

在 RDS 控制台中，写入器数据库实例在数据库页面的角色列下的值为 Writer。在RDS CLI 中，describe-db-clusters 命令的输出包括部分 DBClusterMembers。表示写入器数据库实例的 DBClusterMembers 元素在 true 字段的值为 IsClusterWriter。

重要

在具有读取可用性功能的情况下，Aurora MySQL 和 Aurora PostgreSQL 中的重启行为有所不同：读取器数据库实例通常在您重启写入器实例时仍然可用。然后，您可以在方便的时候重启读取器实例。如果希望某些读取器实例始终可用，您可以按错开的时间安排重启读取器实例。有关更多信息，请参阅在具有读取可用性的情况下重启 Aurora 集群。

检查 Aurora 集群和实例的正常运行时间

您可以检查和监控 Aurora 集群中每个数据库实例自上次重启以来的时间长度。Amazon CloudWatch 指标 EngineUptime 会报告自上次启动数据库实例以来的秒数。您可以在某个时间点检查此指标，以了解数据库实例的正常运行时间。您还可以随着时间的推移监控此指标，以检测实例的重启时间。

您还可以在集群级别检查 EngineUptime 指标。Minimum 和 Maximum 会维度报告集群中所有数据库实例的最小和最大的正常运行时间值。要检查集群中的读取器实例最近的重启时间或出于其他原因重启的时间，请使用 Minimum 维度监控集群级指标。要在不重启的情况下检查集群中运行时间最长的实例，请使用 Maximum 维度监控集群级指标。例如，您可能需要确认在进行配置更改后，集群中的所有数据库实例都已重启。

提示

对于长期监控，我们建议监控单个实例的 EngineUptime 指标，而不是在集群级进行监控。新数据库实例添加到集群后，集群级 EngineUptime 指标将设置为零。此类集群更改可以作为维护和扩缩操作（例如由 Auto Scaling 执行的操作）的一部分。

以下 CLI 示例显示了如何检查集群中写入器和读取器实例的 EngineUptime 指标。这些示例使用名为 tpch100g 的集群。此集群有一个写入器数据库实例 instance-1234。它还有两个读取器数据库实例（instance-7448 和 instance-6305）。

首先，reboot-db-instance 命令会重启其中一个读取器实例。wait 命令会等到实例完成重启。

$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-6305

CloudWatch get-metric-statistics 命令每隔一分钟便会检查过去五分钟内的 EngineUptime 指标。instance-6305 实例的正常运行时间将重置为零并再次开始向上计数。以下适用于 Linux 的 Amazon CLI 示例使用 $() 变量替换在 CLI 命令中插入适当的时间戳。它还使用 Linux sort 命令按照指标收集时间对输出进行排序。该时间戳值是每行输出中的第三个字段。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	231.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	291.0	2021-03-16T18:20:00+00:00	Seconds
DATAPOINTS	351.0	2021-03-16T18:21:00+00:00	Seconds
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds

由于集群中的一个实例已重启，因此集群的最短正常运行时间将重置为零。由于集群中至少有一个数据库实例仍然可用，因此集群的最长正常运行时间不会重置。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Minimum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63099.0	2021-03-16T18:12:00+00:00	Seconds
DATAPOINTS	63159.0	2021-03-16T18:13:00+00:00	Seconds
DATAPOINTS	63219.0	2021-03-16T18:14:00+00:00	Seconds
DATAPOINTS	63279.0	2021-03-16T18:15:00+00:00	Seconds
DATAPOINTS	51.0	2021-03-16T18:16:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63389.0	2021-03-16T18:16:00+00:00	Seconds
DATAPOINTS	63449.0	2021-03-16T18:17:00+00:00	Seconds
DATAPOINTS	63509.0	2021-03-16T18:18:00+00:00	Seconds
DATAPOINTS	63569.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	63629.0	2021-03-16T18:20:00+00:00	Seconds

之后另一个 reboot-db-instance 命令将重启集群的写入器实例。另一个 wait 命令会暂停，直至写入器实例完成重启。

$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
  "DBInstanceIdentifier": "instance-1234",
  "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234

现在，写入器实例的 EngineUptime 指标显示实例 instance-1234 最近已重启。读取器实例 instance-6305 也会与写入器实例一起自动重启。此集群运行 Aurora MySQL 2.09，因此在写入器实例重启时读取器实例不会保持运行状态。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63749.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	63809.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	63869.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	41.0	2021-03-16T18:25:00+00:00	Seconds
DATAPOINTS	101.0	2021-03-16T18:26:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	531.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	49.0	2021-03-16T18:26:00+00:00	Seconds

Aurora 重启操作示例

以下 Aurora MySQL 示例显示了 Aurora 数据库集群中读取器和写入器数据库实例的多种重启操作组合。每次重启后，SQL 查询会显示集群中各实例的正常运行时间。

查找 Aurora 集群的写入器实例和读取器实例

在具有多个数据库实例的 Aurora MySQL 集群中，重要的是要知道哪个是写入器实例，哪些是读取器实例。在发生故障转移操作时，写入器实例和读取器实例还可以切换角色。因此，最好在执行任何需要写入器或读取器实例的操作之前执行如下检查。在这种情况下，False 的 IsClusterWriter 值识别读取器实例 instance-6305 和 instance-7448。True 值识别写入器实例 instance-1234。

$ aws rds describe-db-clusters --db-cluster-id tpch100g \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:     tpch100g
Instance:    instance-6305    False
Instance:    instance-7448    False
Instance:    instance-1234    True

在我们开始重启示例之前，写入器实例的正常运行时间约为一周。此示例中的 SQL 查询显示了一种特定于 MySQL 的正常运行时间检查方法。您可以在数据库应用程序中使用此技术。有关使用 Amazon CLI 并适用于两个 Aurora 引擎的另一种技术，请参阅检查 Aurora 集群和实例的正常运行时间。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+

重启单个读取器实例

此示例重启其中一个读取器数据库实例。也许是此实例被一个巨大查询或许多并发连接过载了。或者它可能由于网络问题落后于写入器实例。开始重启操作后，示例使用 wait 命令暂停，直至实例变为可用。届时，该实例的正常运行时间为几分钟。

$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-6305",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-6305
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:35:02.000000 | 00h 03m |
+----------------------------+---------+

重启读取器实例不会影响写入器实例的正常运行时间。它的正常运行时间仍为大约一周。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+----------+
| Last Startup               | Uptime   |
+----------------------------+----------+
| 2021-03-08 17:49:06.000000 | 174h 49m |
+----------------------------+----------+

重启写入器实例

此示例将重启写入器实例。此集群正在运行 Aurora MySQL 2.09 版。由于 Aurora MySQL 版本低于 2.10，因此重启写入器实例也会重启集群中的所有读取器实例。

wait 命令会暂停，直至重启完成。现在，该实例的正常运行时间重置为零。写入器数据库实例和读取器数据库实例的重启操作所需的时间可能大不相同。写入器数据库实例和读取器数据库实例根据其角色执行不同类型的清理操作。

$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
    "DBInstance": {
        "DBInstanceIdentifier": "instance-1234",
        "DBInstanceStatus": "rebooting",
...
    }
}
$ aws rds wait db-instance-available --db-instance-id instance-1234
$ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:27.000000 | 00h 00m |
+----------------------------+---------+

在写入器数据库实例重启后，两个读取器数据库实例也会重置其正常运行时间。重启写入器实例也会导致读取器实例重启。此行为适用于 Aurora PostgreSQL 集群和低于 2.10 版的 Aurora MySQL 集群。

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+

$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+

独立重启写入器和读取器

接下来的几个示例显示了运行 Aurora MySQL 2.10 版的集群。在此 Aurora MySQL 版本及更高版本中，您可以重启写入器实例，而不会导致所有读取器实例重启。这样一来，当您重启写入器实例时，查询密集型应用程序不会出现任何中断。您可以稍后重启读取器实例。可以在查询流量偏低时重启这些实例。也可以一次重启一个读取器实例。这样一来，至少有一个读取器实例始终可供您的应用程序的查询流量使用。

以下示例使用名为 cluster-2393 且运行 Aurora MySQL 5.7.mysql_aurora.2.10.0 版的集群。此集群有一个写入器实例 (instance-9404) 和三个读取器实例（instance-6772、instance-2470 和 instance-5138）。

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
  --output text
Cluster:        cluster-2393
Instance:       instance-5138        False
Instance:       instance-2470        False
Instance:       instance-6772        False
Instance:       instance-9404        True

通过 uptime 命令检查每个数据库实例的 mysql 值表明，每个数据库实例的正常运行时间大致相同。例如，这是 instance-5138 的正常运行时间。

mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 3866  |
+---------------+-------+

通过使用 CloudWatch，我们可以获得相应的正常运行时间信息，而无需实际登录实例。这样，管理员可以监控数据库，但无法查看或更改任何表数据。在这种情况下，我们指定一个五分钟时间段，然后每分钟检查一次正常运行时间值。不断增加的正常运行时间值表明，这些实例在此期间没有重启。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4648.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4708.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4768.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4828.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4888.0	2021-03-17T23:46:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4315.0	2021-03-17T23:42:00+00:00	Seconds
DATAPOINTS	4375.0	2021-03-17T23:43:00+00:00	Seconds
DATAPOINTS	4435.0	2021-03-17T23:44:00+00:00	Seconds
DATAPOINTS	4495.0	2021-03-17T23:45:00+00:00	Seconds
DATAPOINTS	4555.0	2021-03-17T23:46:00+00:00	Seconds

现在重启其中一个读取器实例 instance-5138。等待实例在重启后再次可用。现在监控五分钟内的正常运行时间，可以看到正常运行时间在此期间已重置为零。最近的正常运行时间值是在重启完成后 5 秒钟测得的。

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	4500.0	2021-03-17T23:46:00+00:00	Seconds
DATAPOINTS	4560.0	2021-03-17T23:47:00+00:00	Seconds
DATAPOINTS	4620.0	2021-03-17T23:48:00+00:00	Seconds
DATAPOINTS	4680.0	2021-03-17T23:49:00+00:00	Seconds
DATAPOINTS  5.0 2021-03-17T23:50:00+00:00 Seconds

接下来，对写入器实例 instance-9404 执行重启。比较写入器实例和其中一个读取器实例的正常运行时间值。借此，我们可以看到重启写入器并没有导致读取器重启。在 Aurora MySQL 2.10 之前的版本中，所有读取器的正常运行时间值将与写入器同时重置。

$ aws rds reboot-db-instance --db-instance-identifier instance-9404
{
  "DBInstanceIdentifier": "instance-9404",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-9404

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	371.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	431.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	491.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	551.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS  37.0  2021-03-18T00:01:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5215.0	2021-03-17T23:57:00+00:00	Seconds
DATAPOINTS	5275.0	2021-03-17T23:58:00+00:00	Seconds
DATAPOINTS	5335.0	2021-03-17T23:59:00+00:00	Seconds
DATAPOINTS	5395.0	2021-03-18T00:00:00+00:00	Seconds
DATAPOINTS	5455.0	2021-03-18T00:01:00+00:00	Seconds

为确保所有读取器实例对配置参数的更改与写入器实例所做的更改相同，请在重启写入器实例之后重启所有读取器实例。此示例将重启所有读取器，然后等到所有读取器都可用后再继续操作。

$ aws rds reboot-db-instance --db-instance-identifier instance-6772
{
  "DBInstanceIdentifier": "instance-6772",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}

$ aws rds wait db-instance-available --db-instance-id instance-6772
$ aws rds wait db-instance-available --db-instance-id instance-2470
$ aws rds wait db-instance-available --db-instance-id instance-5138

现在可以看到，写入器数据库实例的正常运行时间最长。该实例的正常运行时间值在整个监控期内稳步增加。读取器数据库实例都在读取器之后重启。我们可以看到监控期内每个读取器重启且其正常运行时间重置为零的时间点。

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	457.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	517.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	577.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	637.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS  697.0 2021-03-18T00:12:00+00:00 Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	5819.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS  35.0  2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS	95.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS	155.0	2021-03-18T00:11:00+00:00	Seconds
DATAPOINTS	215.0	2021-03-18T00:12:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
  --output text | sort -k 3
EngineUptime
DATAPOINTS	1085.0	2021-03-18T00:08:00+00:00	Seconds
DATAPOINTS	1145.0	2021-03-18T00:09:00+00:00	Seconds
DATAPOINTS	1205.0	2021-03-18T00:10:00+00:00	Seconds
DATAPOINTS  49.0  2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS	109.0	2021-03-18T00:12:00+00:00	Seconds

将集群参数更改应用于 Aurora MySQL 2.10 版集群

以下示例演示了如何将参数更改应用于 Aurora MySQL 2.10 集群中的所有数据库实例。使用此 Aurora MySQL 版本，您可以独立重启写入器实例和所有读取器实例。

该示例使用 MySQL 配置参数 lower_case_table_names 进行说明。当写入器数据库实例和读取器数据库实例的此参数设置不同时，查询可能无法访问使用大写字母或混合大小写名称声明的表。或者，如果两个表名仅在字母大小写方面有所不同，则查询可能会访问错误的表。

此示例显示如何通过检查每个实例的 IsClusterWriter 属性来确定集群中的写入器实例和读取器实例。该集群名为 cluster-2393。集群有一个名为 instance-9404 的写入器实例。集群中的读取器实例名为 instance-5138 和 instance-2470。

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
cluster-2393
instance-5138        False
instance-2470        False
instance-9404        True

为了展示更改 lower_case_table_names 参数的影响，我们设置了两个数据库集群参数组。lower-case-table-names-0 参数组将此参数设置为 0。lower-case-table-names-1 参数组将此参数组设置为 1。

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-0
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-0",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-0"
    }
}

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \
  --db-parameter-group-family aurora-mysql5.7 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
    "DBClusterParameterGroup": {
        "DBClusterParameterGroupName": "lower-case-table-names-1",
        "DBParameterGroupFamily": "aurora-mysql5.7",
        "Description": "lower-case-table-names-1"
    }
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-0 \
  --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-0"
}

$ aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name lower-case-table-names-1 \
    --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "lower-case-table-names-1"
}

lower_case_table_names 的默认值为 0。使用此参数设置时，表 foo 与表 FOO 不相同。此示例验证参数是否仍使用默认设置。之后，该示例创建了三个表，区别仅在于其名称中字母的大小写。

mysql> create database lctn;
Query OK, 1 row affected (0.07 sec)

mysql> use lctn;
Database changed
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> create table foo (s varchar(128));
mysql> insert into foo values ('Lowercase table name foo');

mysql> create table Foo (s varchar(128));
mysql> insert into Foo values ('Mixed-case table name Foo');

mysql> create table FOO (s varchar(128));
mysql> insert into FOO values ('Uppercase table name FOO');

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+

接下来，将数据库参数组与集群关联以将 lower_case_table_names 参数设置为 1。此更改仅在每个数据库实例重启后生效。

$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \
  --db-cluster-parameter-group-name lower-case-table-names-1
{
  "DBClusterIdentifier": "cluster-2393",
  "DBClusterParameterGroup": "lower-case-table-names-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

首先重启写入器数据库实例。然后等待该实例再次可用。届时，连接到写入器终端节点并验证写入器实例的参数值是否已更改。SHOW TABLES 命令确认数据库包含三个不同的表。但是，引用名为 foo、Foo 或 FOO 的表的查询都会访问名称全小写的表。foo

# Rebooting the writer instance
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
$ aws rds wait db-instance-available --db-instance-id instance-9404

现在，使用集群终端节点的查询显示了参数更改的影响。无论查询中的表名是大写、小写还是混合大小写，SQL 语句都会访问名称全小写的表。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

mysql> use lctn;
mysql> show tables;
+----------------+
| Tables_in_lctn |
+----------------+
| FOO            |
| Foo            |
| foo            |
+----------------+

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

下一个示例显示的查询与前一个示例相同。在这种情况下，查询使用读取器终端节点并在其中一个读取器数据库实例上运行。这些实例尚未重启。因此，他们仍然使用 lower_case_table_names 参数的原始设置。这意味着查询可以访问 foo、Foo 和 FOO 表中的每一个。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+

mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+---------------------------+
| s                         |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+

接下来，重启其中一个读取器实例，然后等待它再次可用。

$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
  "DBInstanceIdentifier": "instance-2470",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-2470

在连接到 instance-2470 的实例终端节点时，查询显示新参数已生效。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

此时，集群中的两个读取器实例以不同的 lower_case_table_names 设置运行。因此，与集群读取器终端节点的任何连接都会对此设置使用一个不可预测的值。务必立即重启另一个读取器实例，以便它们使用一致的设置。

$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
  "DBInstanceIdentifier": "instance-5138",
  "DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138

以下示例确认所有读取器实例具有相同的 lower_case_table_names 参数设置。这些命令会检查每个读取器实例的 lower_case_table_names 设置值。使用读取器终端节点的同一命令表明，与读取器终端节点的每个连接都使用其中一个读取器实例，但该实例不可预测。

# Check lower_case_table_names setting on each reader instance.

$ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

$ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-2470            |                        1 |
+--------------------------+--------------------------+

# Check lower_case_table_names setting on the reader endpoint of the cluster.

$ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138            |                        1 |
+--------------------------+--------------------------+

# Run query on writer instance

$ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \
  -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id       | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-9404            |                        1 |
+--------------------------+--------------------------+

随着参数更改应用到各处，我们可以看到设置 lower_case_table_names=1 的影响。无论表名是 foo、Foo 还是 FOO，查询都会将名称转换为 foo，并在各种情况下都访问同一个表。

mysql> use lctn;

mysql> select * from foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from Foo;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+

mysql> select * from FOO;
+--------------------------+
| s                        |
+--------------------------+
| Lowercase table name foo |
+--------------------------+