Amazon Relational Database Service
用户指南 (API 版本 2014-10-31)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

Amazon Aurora 概述

Amazon Aurora (Aurora) 是一种完全托管的、兼容 MySQL 和 PostgreSQL 的关系数据库引擎。它结合了高端商用数据库的速度和可靠性,同时还具有开源数据库的简单性和成本效益。它最多可将 MySQL 吞吐量增加至 5 倍,将 PostgreSQL 的吞吐量增加至 3 倍,而无需对大多数现有应用程序进行更改。

利用 Aurora,可以通过简单且经济高效的方式设置、操作和扩展 MySQL 和 PostgreSQL 部署,使您能够腾出时间专注于业务和应用程序。Amazon RDS 通过处理例行数据库任务 (如预置、修补、备份、恢复、故障检测和修复) 来管理 Aurora。Amazon RDS 还提供按钮式迁移工具,这些工具可用于将现有的 Amazon RDS for MySQL 应用程序和 Amazon RDS for PostgreSQL 应用程序转换到 Aurora。

Amazon Aurora 可以直接替代 MySQL 和 PostgreSQL。您目前用于现有 MySQL 和 PostgreSQL 数据库的代码、工具和应用程序可用于 Amazon Aurora。

在创建 Amazon Aurora 实例时,将创建一个数据库集群。数据库集群包含一个或多个数据库实例以及一个管理这些实例的数据的集群卷。Aurora 集群卷是一个跨多个可用区的虚拟数据库存储卷,每个可用区均有一个数据库集群数据副本。Aurora 数据库集群由两类数据库实例组成:

  • 主实例 – 支持读取和写入操作,并执行针对集群卷的所有数据修改。每个 Aurora 数据库集群均有一个主实例。

  • Aurora 副本 – 支持只读操作。除主实例之外,每个 Aurora 数据库集群最多可拥有 15 个 Aurora 副本。多个 Aurora 副本将分配读取工作负载,您还可通过将 Aurora 副本置于单独的可用区中来提高数据库可用性。

下图说明了 Aurora 数据库集群中的集群卷、主实例和 Aurora 副本之间的关系。

 Amazon Aurora 架构

可用性

Amazon Aurora 在 AWS 区域中的可用性因数据库引擎兼容性而异。

数据库引擎 可用性

Amazon Aurora MySQL

请参阅 Amazon Aurora MySQL 的可用性

Amazon Aurora PostgreSQL

请参阅 Amazon Aurora PostgreSQL 的可用性

Aurora 终端节点

您可以使用终端节点连接到 Amazon Aurora 数据库集群中的数据库实例。终端节点是包含主机地址和端口的 URL。可从 Aurora 数据库集群使用以下终端节点。

集群终端节点

集群终端节点是 Aurora 数据库集群的一个终端节点,连接到该数据库集群的当前主实例。每个 Aurora 数据库集群都具有集群终端节点和一个主实例。

集群终端节点为数据库集群的读取/写入连接提供故障转移支持。对数据库集群上的所有写入操作使用集群终端节点,这些操作包括插入、更新、删除和数据定义语言 (DDL) 更改。您还可以对读取操作 (如查询) 使用集群终端节点。

如果数据库集群的当前主实例失败,Aurora 将自动故障转移到新的主实例。在故障转移期间,数据库集群将继续为从新主实例到集群终端节点的请求提供服务,对服务造成的中断最少。

以下示例介绍 Aurora MySQL 数据库集群中的集群终端节点。

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

读取实例终端节点

读取器终端节点是 Aurora 数据库集群的一个终端节点,连接到该数据库集群的可用 Aurora 副本之一。每个 Aurora 数据库集群具有一个读取实例终端节点。如果有多个 Aurora 副本,则读取实例终端节点会将每个连接请求定向到 Aurora 副本之一。

读取实例终端节点为数据库集群的只读连接提供负载平衡支持。对读取操作 (如查询) 使用读取实例终端节点。不能对写入操作使用读取器终端节点。

数据库集群在可用 Aurora 副本之间分配对读取实例终端节点的连接请求。如果数据库集群只包含主实例,则读取实例终端节点从主实例为连接请求提供服务。如果为该数据库集群创建了 Aurora 副本,则读取实例终端节点将从新 Aurora 副本继续为针对读取实例终端节点的连接请求提供服务,对服务造成的中断最少。

以下示例介绍 Aurora MySQL 数据库集群中的读取实例终端节点。

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

实例终端节点

实例终端节点是 Aurora 数据库集群中数据库实例的一个终端节点,连接到该特定数据库实例。数据库集群中的每个数据库实例,不论其实例类型,都有各自唯一的实例终端节点。因此,数据库集群的当前主实例具有一个实例终端节点,并且数据库集群中的每个 Aurora 副本都具有一个实例终端节点。

对于可能不适合使用集群终端节点或读取实例终端节点的场景,实例终端节点提供对与数据库集群连接的直接控制。例如,您的客户端应用程序可能需要按读取工作负载而不是按连接进行负载平衡,在这种情况下,您可以配置多个客户端连接到数据库集群中的不同 Aurora 副本,以便分布读取工作负载。有关使用实例终端节点改进故障转移之后的连接速度的示例,请参阅 使用 Amazon Aurora PostgreSQL 进行快速故障转移

以下示例介绍 Aurora MySQL 数据库集群中数据库实例的实例终端节点。

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

终端节点注意事项

使用 Aurora 终端节点的一些注意事项如下所示:

  • 使用实例终端节点连接到数据库集群中的特定数据库实例之前,请考虑改为对数据库集群使用集群终端节点或读取实例终端节点。

    集群终端节点和读取实例终端节点可提供对高可用性场景的支持。如果数据库集群的主实例失败,Aurora 将自动故障转移到新的主实例。它通过将现有 Aurora 副本提升为主实例或者创建新的主实例来完成该操作。如果发生了故障转移,您可以使用集群终端节点连接到新提升或新创建的主实例,或者使用读取实例终端节点重新连接到数据库集群中的其他 Aurora 副本之一。

    如果未采用此方法,您仍可以确保连接到数据库集群中的合适数据库实例来执行目标操作。为此,您可在故障转移之后,以手动或以编程方式先搜索数据库集群中得到的可用数据库实例集,并确认其实例类型,然后再使用特定数据库实例的实例终端节点。

    有关故障转移的更多信息,请参阅Aurora 数据库集群的容错能力

  • 读取实例终端节点仅对与 Aurora 数据库集群中的可用 Aurora 副本的连接执行负载平衡。它没有负载平衡特定的查询。如果要对查询进行负载平衡以分配数据库集群的读取工作负载,您需要在应用程序中管理该集群,并使用实例终端节点直接连接到 Aurora 副本以进行负载平衡。

  • 在故障转移期间,如果将 Aurora 副本提升为新的主实例,则读取实例终端节点可能会在短时间内将连接定位到数据库集群的新主实例。

Amazon Aurora 存储

Aurora 数据存储在集群卷中,此卷是一个使用固态硬盘 (SSD) 驱动器的单一虚拟卷。集群卷由跨一个区域中的多个可用区的数据副本组成。由于数据会自动跨可用区复制,因此,数据具有高持久性,同时数据丢失的可能性很小。此复制还可确保数据库的可用性在故障转移期间更高,因为数据副本已存在于其他可用区中并且继续响应对数据库集群中实例的数据请求。

Aurora 集群卷随着数据库中数据量的增加自动增大。Aurora 集群卷可增大到最大 64 TiB。表大小限制为集群卷的大小。即,Aurora 数据库集群中表的最大表大小为 64 TiB。即使 Aurora 集群卷最大可增大到 64 TiB,您也只需为在 Aurora 集群卷中使用的空间付费。有关定价信息,请参阅 Amazon RDS for Aurora 定价

Amazon Aurora 复制

Aurora 副本是 Aurora 数据库集群中的独立终端节点。它们提供对数据库集群卷中数据的只读访问。通过这些节点,您能够跨多个复制实例扩展数据的读取工作负载,从而提高数据读取性能以及 Aurora 数据库集群中数据的可用性。Aurora 副本还是故障转移目标,并且在 Aurora 数据库集群的主实例发生故障时将快速提升。

有关 Aurora 副本和用于复制 Aurora 数据库集群中的数据的其他选项的更多信息,请参阅 使用 Amazon Aurora 进行复制

Amazon Aurora 可靠性

Aurora 的设计具有可靠、持久和容错的特点。您可通过执行一些操作 (例如,添加 Aurora 副本并将这些副本置于不同的可用区中) 来构建 Aurora 数据库集群以提高可用性,Aurora 还包括一些自动化功能,这些功能可使其成为一种可靠的数据库解决方案。

存储自动修复

由于 Aurora 将多个数据副本保留在三个可用区中,因此,大大降低了因磁盘故障导致数据丢失的可能性。Aurora 自动检测集群卷包含的磁盘卷中的故障。如果磁盘卷的某个区段发生故障,Aurora 会立即修复该区段。在 Aurora 修复磁盘区段时,它使用集群卷包含的其他卷中的数据以确保已修复区段中的数据最新。因此,Aurora 将避免数据丢失,并减少了执行时间点还原以从磁盘故障恢复的需求。

自动恢复缓存预热

当数据库在关闭后启动或在发生故障后重新启动时,Aurora 将对缓冲池缓存进行“预热”。即,Aurora 会用内存页面缓存中存储的已知常用查询页面预加载缓冲池。这样,缓冲池便无需从正常的数据库使用“预热”,从而提高性能。

Aurora 页面缓存将通过与数据库不同的单独进程进行管理,这将允许页面缓存独立于数据库进行自动恢复。在出现极少发生的数据库故障时,页面缓存将保留在内存中,这将确保在数据库重新启动时,使用最新状态预热缓冲池。

崩溃恢复

Aurora 设计为在发生崩溃时立即恢复并继续提供应用程序数据。Aurora 以异步方式对并行线程执行崩溃恢复,以便数据库在发生崩溃后打开并立即可用。

有关崩溃恢复的更多信息,请参阅Aurora 数据库集群的容错能力

下面是二进制日志记录与 Aurora MySQL 上的崩溃恢复的注意事项:

  • 直接在 Aurora 上启用二进制日志记录会影响崩溃后的恢复时间,因为它强制数据库实例执行二进制日志恢复。

  • 所用二进制日志记录的类型影响日志记录的大小和效率。对于相同数量的数据库活动,某些格式会比二进制日志中的其他格式记录更多信息。binlog_format 参数的以下设置会产生不同的日志数据量:

    • ROW - 最多的日志数据

    • STATEMENT - 最少的日志数据

    • MIXED - 中等日志数据量,通常提供数据完整性和性能的最佳组合

    二进制日志数据量影响恢复时间。二进制日志中记录的数据越多,数据库实例在恢复过程中就必须处理更多数据,这会增加恢复时间。

  • Aurora 不需要二进制日志来复制数据库集群中的数据或执行时间点恢复 (PITR)。

  • 如果您不需要外部复制的二进制日志 (或外部二进制日志流),我们建议您将 binlog_format 参数设置为 OFF 以禁用二进制日志记录。这样做可以减少恢复时间。

有关 Aurora 二进制日志记录和复制的更多信息,请参阅使用 Amazon Aurora 进行复制。有关不同 MySQL 复制类型的含义的更多信息,请参阅 MySQL 文档中的基于语句和基于行的复制的优点和缺点

Amazon Aurora 性能增强

Amazon Aurora 包括用于支持高端商用数据库的不同需求的性能增强。

Amazon Aurora MySQL 性能增强

Aurora MySQL 包括以下性能增强:

快速插入

快速插入加速了按主键排序的并行插入,特别适用于 LOAD DATAINSERT INTO ... SELECT ... 语句。

有关 Aurora MySQL 性能增强的更多信息,请参阅 Amazon Aurora MySQL 性能增强

Amazon Aurora 安全性

Amazon Aurora 的安全性在三个级别上进行管理:

  • 要控制可对 Aurora 数据库集群和数据库实例执行 Amazon RDS 管理操作的人员,请使用 AWS Identity and Access Management (IAM)。使用 IAM 凭证连接到 AWS 时,您的 IAM 账户必须具有授予执行 Amazon RDS 管理操作所需的权限的 IAM 策略。有关更多信息,请参阅 Amazon RDS 的身份验证和访问控制

    如果使用 IAM 账户访问 Amazon RDS 控制台,则必须先使用您的 IAM 账户登录到 AWS 管理控制台,然后转至 https://console.amazonaws.cn/rds 中的 Amazon RDS 控制台。

  • Aurora 数据库集群必须在 Amazon Virtual Private Cloud (VPC) 中创建。要控制哪些设备和 Amazon EC2 实例能够建立与 VPC 中 Aurora 数据库集群的数据库实例的终端节点和端口的连接,请使用 VPC 安全组。可使用安全套接字层 (SSL) 建立这些终端节点和端口连接。此外,公司的防火墙规则也可以控制公司中运行的哪些设备可以建立与数据库实例的连接。有关 VPC 的更多信息,请参阅Amazon Virtual Private Cloud (VPCs) 和 Amazon RDS

  • 要对 Amazon Aurora 数据库集群的登录名和权限进行身份验证,可单独或组合采用以下各种方式。

    • 您可以采用与独立 MySQL 或 PostgreSQL 实例相同的方式。

      对独立 MySQL 或 PostgreSQL 实例的登录名和权限进行身份验证的技术 (例如使用 SQL 命令或修改数据库表) 也适用于 Aurora。有关更多信息,请参阅 使用 Amazon Aurora MySQL 实现高安全性使用 Amazon Aurora PostgreSQL 实现高安全性

    • 您还可以使用 Aurora MySQL 的 IAM 数据库身份验证。

      如果采用 IAM 数据库身份验证方式,可使用 IAM 用户或 IAM 角色以及身份验证令牌对您的 Aurora MySQL 数据库集群进行身份验证。身份验证令牌是使用签名版本 4 签名流程生成的唯一值。通过使用 IAM 数据库身份验证,您可以使用相同的凭证来控制对 AWS 资源和数据库的访问。有关更多信息,请参阅 对 MySQL 和 Amazon Aurora 使用 IAM 数据库身份验证

将 SSL 与 Aurora 数据库集群配合使用

Amazon Aurora 数据库集群通过使用与 Amazon RDS 数据库实例相同的过程和公有密钥的应用程序,支持安全套接字层 (SSL) 连接。有关更多信息,请参阅 使用 Amazon Aurora MySQL 实现高安全性使用 Amazon Aurora PostgreSQL 实现高安全性

Amazon Aurora 数据库集群的本地时区

默认情况下,Amazon Aurora 数据库集群的时区是协调世界时 (UTC)。您可以改为将数据库集群中实例的时区设置为您的应用程序的本地时区。

要设置数据库集群的本地时区,请将数据库集群的集群参数组中的 time_zone 参数设置为本节后面列出的受支持值之一。在设置数据库集群的 time_zone 参数时,数据库集群中的所有实例将改为使用新的本地时区。如果其他 Aurora 数据库集群使用相同的集群参数组,则这些数据库集群中的所有实例也将改为使用新的本地时区。有关集群级参数的信息,请参阅Amazon Aurora 数据库集群和数据库实例参数

设置本地时区之后,所有新数据库连接都会反映更改。如果在更改本地时区时打开了任何数据库连接,则到关闭连接再打开新连接之后才会看到本地时区更新。

如果要跨区域复制,则复制主数据库集群和副本使用不同的参数组 (参数组对于某个区域是唯一的)。要对每个实例使用相同的本地时区,您必须在复制主体和副本的参数组中设置 time_zone 参数。

从数据库集群快照还原数据库集群时,本地时区设置为 UTC。还原完成之后,可以将时区更新为本地时区。如果将数据库集群还原到某个时间点,则还原的数据库集群的本地时区是来自还原的数据库集群的参数组的时区设置。

您可以将本地时区设置为下表中列出的值之一。对于一些时区,可能会错误报告某些日期范围的时间值,如表中所述。对于澳大利亚时区,返回的时区缩写为过时的值,如表中所述。

Time Zone

备注

Africa/Harare

此时区设置回返回 28 Feb 1903 21:49:40 GMT 和 28 Feb 1903 21:55:48 GMT 之间的错误值。

Africa/Monrovia

Africa/Nairobi

此时区设置会返回 31 Dec 1939 21:30:00 GMT 和 31 Dec 1959 21:15:15 GMT 之间的错误值。

Africa/Windhoek

America/Bogota

此时区设置会返回 23 Nov 1914 04:56:16 GMT 和 23 Nov 1914 04:56:20 GMT 之间的错误值。

America/Caracas

America/Chihuahua

America/Cuiaba

America/Denver

America/Fortaleza

America/Guatemala

America/Halifax

此时区设置会返回 27 Oct 1918 05:00:00 GMT 和 31 Oct 1918 05:00:00 GMT 之间的错误值。

America/Manaus

America/Matamoros

America/Monterrey

America/Montevideo

America/Phoenix

America/Tijuana

Asia/Ashgabat

Asia/Baghdad

Asia/Baku

Asia/Bangkok

Asia/Beirut

Asia/Calcutta

Asia/Kabul

Asia/Karachi

Asia/Kathmandu

Asia/Muscat

此时区设置会返回 31 Dec 1919 20:05:36 GMT 和 31 Dec 1919 20:05:40 GMT 之间的错误值。

Asia/Riyadh

此时区设置会返回 13 Mar 1947 20:53:08 GMT 和 31 Dec 1949 20:53:08 GMT 之间的错误值。

Asia/Seoul

此时区设置会返回 30 Nov 1904 15:30:00 GMT 和 07 Sep 1945 15:00:00 GMT 之间的错误值。

Asia/Shanghai

此时区设置会返回 31 Dec 1927 15:54:08 GMT 和 02 Jun 1940 16:00:00 GMT 之间的错误值。

Asia/Singapore

Asia/Taipei

此时区设置会返回 30 Sep 1937 16:00:00 GMT 和 29 Sep 1979 15:00:00 GMT 之间的错误值。

Asia/Tehran

Asia/Tokyo

此时区设置会返回 30 Sep 1937 15:00:00 GMT 和 31 Dec 1937 15:00:00 GMT 之间的错误值。

Asia/Ulaanbaatar

Atlantic/Azores

此时区设置会返回 24 May 1911 01:54:32 GMT 和 01 Jan 1912 01:54:32 GMT 之间的错误值。

Australia/Adelaide

此时区的缩写以 CST 而非 ACDT/ACST 形式返回。

Australia/Brisbane

此时区的缩写以 EST 而非 AEDT/AEST 形式返回。

Australia/Darwin

此时区的缩写以 CST 而非 ACDT/ACST 形式返回。

Australia/Hobart

此时区的缩写以 EST 而非 AEDT/AEST 形式返回。

Australia/Perth

此时区的缩写以 WST 而非 AWDT/AWST 形式返回。

Australia/Sydney

此时区的缩写以 EST 而非 AEDT/AEST 形式返回。

Brazil/East

Canada/Saskatchewan

此时区设置会返回 27 Oct 1918 08:00:00 GMT 和 31 Oct 1918 08:00:00 GMT 之间的错误值。

Europe/Amsterdam

Europe/Athens

Europe/Dublin

Europe/Helsinki

此时区设置会返回 30 Apr 1921 22:20:08 GMT 和 30 Apr 1921 22:20:11 GMT 之间的错误值。

Europe/Paris

Europe/Prague

Europe/Sarajevo

Pacific/Auckland

Pacific/Guam

Pacific/Honolulu

此时区设置会返回 21 May 1933 11:30:00 GMT 和 30 Sep 1945 11:30:00 GMT 之间的错误值。

Pacific/Samoa

此时区设置会返回 01 Jan 1911 11:22:48 GMT 和 01 Jan 1950 11:30:00 GMT 之间的错误值。

US/Alaska

US/Central

US/Eastern

US/East-Indiana

US/Pacific

UTC