Amazon Relational Database Service
用户指南 (API Version 2014-10-31)
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。请点击 Amazon AWS 入门,可查看中国地区的具体差异

Amazon Aurora 概述

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

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

Amazon Aurora 是 MySQL 的简易替代。目前,您用于现有 MySQL 数据库的代码、工具和应用程序可用于 Amazon Aurora。

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

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

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

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

 Amazon Aurora 架构

可用性

下表显示了 Amazon Aurora 当前可用的区域。

Aurora 终端节点

您可以通过使用数据库群集的多个终端节点中的一个连接到 Aurora 数据库群集中的实例。终端节点包含一个域名和一个端口 (二者由冒号隔开),例如:mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306。从以下选项中选择适合您的场景的最佳终端节点。

群集终端节点

每个 Aurora 数据库群集均有一个可连接到的群集终端节点。群集终端节点将您连接到数据库群集的主实例。可使用群集终端节点执行读取和写入操作。

主实例还具有其自己唯一的终端节点。这两个终端节点之间的区别在于,群集终端节点将始终指向当前主实例。换言之,如果主实例发生故障,则群集终端节点将指向新的主实例。如果主实例发生故障,您将需要重新建立连接。有关故障转移的更多信息,请参阅Aurora 数据库群集的容错能力

对于高可用性方案,建议您连接到群集终端节点。如果您这样做,一旦故障转移完成,您的应用程序就将重新连接到新的主实例。在故障转移期间,Aurora 仍将向新提升的主实例中的群集终端节点发送请求,因为这将替代失败的实例。Aurora 响应群集终端节点,并且对服务造成的中断最少。

作为如何使用群集终端节点的例子,考虑其两个 Aurora 副本位于主实例的不同可用区中的 Aurora 数据库群集。通过连接到群集终端节点,可将读写流量发送到主实例。您还可连接到每个 Aurora 副本的终端节点并将查询直接发送到这些数据库实例。如果主实例或包含主实例的可用区发生故障,则 RDS 会将其中一个 Aurora 副本提升为新的主实例并更新群集终端节点的域名服务 (DNS) 记录以指向新的主实例,这种情况不太可能出现。您的应用程序将使用群集终端节点继续将读写流量发送到 Aurora 数据库群集,并且对服务造成的中断最少。

读取器终端节点

每个 Aurora 数据库群集均有一个读取器终端节点,可使用该节点连接到您的数据库群集中的某个 Aurora 副本。数据库群集的读取器终端节点 实现跨数据库群集中可用的 Aurora 副本的连接的负载均衡。当客户端请求与读取器终端节点的新连接时,Aurora 将在数据库群集中的 Aurora 副本之间分配连接请求。此功能可帮助平衡跨数据库群集中的多个 Aurora 副本的读取工作负载。

如果 Aurora 数据库群集中仅包含主实例,则无需 Aurora 副本,阅读器终端节点会将流量定向到主实例。如果有 Aurora 副本添加到数据库群集,则读取终端节点会将流量重定向到该 Aurora 副本,对服务的干扰极小。

如果发生了故障转移并且连接到的 Aurora 副本将提升到主实例,则将删除您的连接。要继续向群集中的其他 Aurora 副本发送读取工作负载,请重新连接到读取器终端节点。有关故障转移的更多信息,请参阅Aurora 数据库群集的容错能力

您可以使用读取器终端节点为数据库群集中的只读查询提供高可用性。要采用此方法,请将多个 Aurora 副本置于不同的可用区中,然后连接到您的读取工作负载的读取器终端节点。如果可用区发生故障,则您的应用程序将使用读取器终端节点继续将读取流量发送到 Aurora 数据库群集中的 Aurora 副本,并且对服务造成的中断最少,这种情况不太可能出现。

读取器终端节点仅实现与数据库群集中的 Aurora 副本的连接的负载均衡。如果您要实现查询的负载均衡以分配群集的读取工作负载,则需要在应用程序中进行管理。

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

如果客户端缓存了 DNS 信息,您可能会在客户端使用缓存的连接设置连接到同一 Aurora 副本时发现连接的负载均衡中存在一些不一致之处。

实例终端节点

数据库群集中的主实例和 Aurora 副本都有一个实例终端节点,该终端节点是一个唯一的终端节点,可用来直接连接到特定实例。实例终端节点在标识符中不包括 cluster-。例如,群集终端节点可能为 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306,而且主实例的实例终端节点可能为 mydbcluster-primary.123456789012.us-east-1.rds.amazonaws.com:3306

您可配置多个客户端以连接到 Aurora 数据库群集中不同的 Aurora 副本,以便分配应用程序的读取工作负载。对于高可用性方案,您还可以将 Aurora 副本置于单独的可用区中。将 Aurora 副本置于单独的可用区可确保您的应用程序在可用区发生故障的情况下仍可读取来自 Aurora 数据库群集的数据。

使用实例终端节点连接到实例之前,请考虑使用群集终端节点或数据库群集的读取器终端节点。如果数据库群集发生了故障转移,则群集终端节点可用于连接到新提升的主实例,而读取器终端节点可用于连接到数据库群集中任何可用的 Aurora 副本。

Amazon Aurora 存储

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

Aurora 群集卷随着数据库中数据量的增加自动增大。Aurora 群集卷可增大到最大 64 TB。表大小限制为群集卷的大小。即,Aurora 数据库群集中表的最大表大小为 64 TB。即使 Aurora 群集卷最大可增大到 64 TB,您也只需为在 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 性能增强

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

快速插入

快速插入加速了按主键排序的并行插入,特别适用于 LOAD DATAINSERT INTO ... SELECT ... 语句。在执行语句时,快速插入将光标的位置缓存到索引遍历中。这可避免再次不必要地遍历索引。

您可监控下列指标来确定数据库群集的快速插入的有效性:

  • aurora_fast_insert_cache_hits:在成功检索和验证缓存光标时递增的计数器。

  • aurora_fast_insert_cache_misses:当缓存光标不再有效且 Aurora 执行常规索引遍历时递增的计数器。

您可使用以下命令检索快速插入指标的当前值:

mysql> show global status like 'Aurora_fast_insert%';

您将获得与下内容类似的输出:

+---------------------------------+-----------+ | Variable_name | Value | +---------------------------------+-----------+ | Aurora_fast_insert_cache_hits | 3598300 | | Aurora_fast_insert_cache_misses | 436401336 | +---------------------------------+-----------+

Amazon Aurora 安全性

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

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

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

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

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

    您可采用与独立 MySQL 实例相同的方式。CREATE USERRENAME USERGRANTREVOKESET PASSWORD 等命令的作用与它们在本地数据库中的作用相同,就像直接修改数据库架构表。有关信息,请参阅 MySQL 文档中的 MySQL 用户账户管理

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

当您创建 Amazon Aurora 数据库实例时,主用户有以下默认特权:

  • ALTER

  • ALTER ROUTINE

  • CREATE

  • CREATE ROUTINE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • EVENT

  • EXECUTE

  • GRANT OPTION

  • INDEX

  • INSERT

  • LOAD FROM S3

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • SELECT

  • SHOW DATABASES

  • SHOW VIEW

  • TRIGGER

  • UPDATE

要为每个数据库群集提供管理服务,需要在创建数据库群集时创建 rdsadmin 用户。如果试图删掉、重命名、修改密码,或者修改 rdsadmin 账户的特权,会导致出错。

对于数据库群集的管理,已限制标准的 killkill_query 命令。相反,使用 Amazon RDS 命令 rds_killrds_kill_query 可终止数据库实例上的用户会话或查询。

利用 SSL 保护 Aurora 数据

Amazon Aurora 数据库群集通过使用与 Amazon RDS MySQL 数据库实例相同的过程和公钥的应用程序支持安全套接字层 (SSL) 连接。

在 Amazon RDS 预置数据库实例时,Amazon RDS 创建 SSL 证书,并将该证书安装在数据库实例上。这些证书由证书颁发机构签署。SSL 证书会将数据库实例终端节点作为 SSL 证书的公用名 (CN) 包含在内以防止欺诈攻击。因此,只有在您的客户端支持主题替代名称 (SAN) 时,您才能使用数据库群集终端节点来连接使用 SSL 的数据库群集。否则,您必须使用该主实例的终端节点。我们建议将 MariaDB Connector/J 客户端作为使用 SSL 支持 SAN 的客户端。有关更多信息,请参阅 MariaDB Connector/J 下载页面。

公有密钥存储于 https://s3.amazonaws.com/rds-downloads/rds-cn-north-1-ca-certificate.pem

要使用默认的 mysql 客户端对连接加密,需用 --ssl-ca 参数启动 mysql 客户端以便引用公共密钥,例如:

mysql -h mycluster-primary.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=[full path]rds-cn-north-1-ca-certificate.pem --ssl-verify-server-cert

您可以使用 GRANT 语句要求特定用户账户的 SSL 连接。例如,您可以使用以下语句来要求用户账户 encrypted_user 的 SSL 连接:

GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL

注意

有关与 MySQL 的 SSL 连接的更多信息,请参阅 MySQL 文档

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

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

要设置数据库群集的本地时区,请将数据库群集的群集参数组中的 time_zone 参数设置为本节后面列出的受支持值之一。在设置数据库群集的 time_zone 参数时,数据库群集中的所有实例将改为使用新的本地时区。如果其他 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

比较 Amazon Aurora 和 Amazon RDS for MySQL

尽管 Aurora 实例可与 MySQL 客户端应用程序兼容,但 Aurora 优于 MySQL,并且 Aurora 支持的 MySQL 功能受限。此功能会影响您有关 Amazon Aurora 还是 Amazon RDS 上的 MySQL 将是最适合您的解决方案的云数据库的决定。下表显示了 Amazon Aurora 与 Amazon RDS for MySQL 之间的差异。

功能 Amazon Aurora Amazon RDS for MySQL
读取扩展 支持最多 15 个 Aurora 副本,并且对写入操作的性能的影响最小。 支持最多 5 个只读副本,对写入操作的性能有一些影响。
故障转移目标 Aurora 副本是自动故障转移目标,无数据丢失。 可将只读副本手动提升到主数据库实例,可能会出现数据丢失。
MySQL 版本 仅支持 MySQL 版本 5.6。 支持 MySQL 版本 5.5、5.6 和 5.7。
AWS 区域 只能在以下区域中创建 Aurora 数据库群集:美国东部(弗吉尼亚北部) (us-east-1)、美国东部(俄亥俄州) (us-east-2)、美国西部(俄勒冈) (us-west-2)、亚太地区(孟买) (ap-south-1)、亚太区域(首尔) (ap-northeast-2)、亚太区域(悉尼) (ap-southeast-2)、亚太区域(东京) (ap-northeast-1)、加拿大 (中部) (ca-central-1)、欧洲(爱尔兰) (eu-west-1)、欧洲 (伦敦) (eu-west-2)。 在所有 AWS 区域中可用。
MySQL 存储引擎

仅支持 InnoDB。其他存储引擎中的表将自动转换为 InnoDB。

有关将现有 MySQL 表转换为 InnoDB 并导入到 Aurora 群集的信息,请参阅将数据迁移到 Amazon Aurora 数据库群集

由于 Amazon Aurora 仅支持 InnoDB 引擎,因此会启用 SQL_MODE 数据库参数的 NO_ENGINE_SUBSTITUTION 选项。这样便无法创建内存表,除非该表指定为 TEMPORARY

支持 MyISAM 和 InnoDB。
具有与主实例不同的存储引擎的只读副本 与 Aurora 数据库群集一起复制的 MySQL (非 RDS) 只读副本只能使用 InnoDB。 只读副本可使用 MyISAM 和 InnoDB。
数据库引擎参数 一些参数适用于整个 Aurora 数据库群集并且由数据库群集参数组管理。另一些参数适用于数据库群集中的每个单独的数据库实例并且由数据库参数组管理。有关更多信息,请参阅 数据库群集和数据库实例参数 参数适用于每个单独的数据库实例或只读副本并且由数据库参数组管理。