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

针对 Amazon RDS 的最佳实践

本部分汇总了使用 Amazon RDS 的最佳实践。随着新的最佳实践的确定,我们将持续更新此部分。

Amazon RDS 基本操作指导方针

以下是使用 Amazon RDS 时每个人都应遵循的基本操作指导方针。请注意,Amazon RDS 服务等级协议要求您遵循以下指导方针:

  • 监控您的内存、CPU 和存储空间的使用情况。可将 Amazon CloudWatch 设置为在使用模式发生更改或接近部署容量时向您发送通知,以便您对系统性能和可用性进行维护。

  • 当接近存储容量限制时,可以向上扩展数据库实例。存储和内存中应含有一些缓冲区,以适应应用程序的意外增大需求。

  • 启用自动备份并设置备份时段,以在每天写入 IOPS 较低的时段进行。

  • 如果您的数据库工作负载需要的 I/O 超过您的预置,那么出现故障转移或数据库故障后,恢复的速度将会变缓。要增加数据库实例的 I/O 容量,请执行以下任一或所有操作:

    • 迁移到具有高 I/O 容量的数据库实例类。

    • 从标准存储转换为通用存储或预配置 IOPS 存储,具体取决于您需要增加的量。有关可用存储类型的信息,请参阅 Amazon RDS 存储类型

      如果转换为预配置 IOPS 存储,请确保还使用已针对预配置 IOPS 进行优化的数据库实例类。有关预配置 IOPS 的信息,请参阅 用于提高性能的 Amazon RDS 预配置 IOPS 存储

    • 如果您已在使用预配置 IOPS 存储,请额外预置吞吐量容量。

  • 如果您的客户端应用程序正在缓存数据库实例的域名服务 (DNS) 数据,请将生存时间 (TTL) 值设置为小于 30 秒。因为数据库实例的底层 IP 地址在故障转移后可能会发生变化,所以如果您的应用程序试图连接到不再使用的 IP 地址,那么在较长时间内缓存 DNS 数据可能会导致连接失败。

  • 测试数据库实例的故障转移,以了解对于您的使用案例而言该过程所需的时间,并确保访问数据库实例的应用程序能够在故障转移后自动连接至新数据库实例。

数据库实例 RAM 建议

Amazon RDS 性能最佳实践是分配足够的 RAM,以便您的工作集几乎完全驻留在内存中。若要确定您的工作集是否几乎完全位于内存中,请在数据库实例加载期间检查 ReadIOPS 指标 (使用 Amazon CloudWatch)。ReadIOPS 的值应是一个较小且稳定的值。如果将数据库实例类向上扩展到带更多 RAM 的类,则会导致 ReadIOPS 大幅降低,从而使您的工作集不能几乎完全位于内存中。继续向上扩展直至 ReadIOPS 不再在扩展操作后大幅降低,否则 ReadIOPS 将降低至非常小的数量。有关监控数据库实例的指标的信息,请参阅查看数据库实例指标

Amazon RDS 安全最佳实践

使用 AWS IAM 账户控制 Amazon RDS API 操作的访问权限,尤其是创建、修改或删除 RDS 资源 (如数据库实例、安全组、选项组或参数组) 的操作,以及执行常见管理操作 (如备份和还原数据库实例或配置预配置 IOPS 存储) 的操作。

  • 为每个管理 RDS 资源的人员分配个人 IAM 账户。切勿使用 AWS 根凭证管理 Amazon RDS;您应当为所有人 (包括您自己) 创建 IAM 用户。

  • 授予每位用户执行其职责所需的最小权限集。

  • 使用 IAM 组有效地管理适用于多个用户的权限。

  • 定期交替 IAM 凭证。

有关 IAM 的更多信息,请转至 AWS Identity and Access Management。有关 IAM 最佳实践的信息,请转至 IAM 最佳实践

使用增强监控来标识操作系统问题

Amazon RDS 为数据库实例运行的操作系统 (OS) 实时提供指标。您可以使用控制台查看数据库实例指标,或者在您选择的监控系统中使用 Amazon CloudWatch Logs 的增强监控 JSON 输出。有关增强监控的更多信息,请参阅增强监控

增强监控对以下数据库引擎可用:

  • Amazon Aurora

  • MariaDB

  • Microsoft SQL Server

  • MySQL 版本 5.5 或更高版本

  • Oracle

  • PostgreSQL

增强监控可用于除 db.t1.microdb.m1.small 之外的所有数据库实例类。增强监控在除 AWS GovCloud (US) 之外的所有区域都可用。

使用指标确定性能问题

要确定资源不足和其他常见瓶颈导致的性能问题,您可以监控可用于 Amazon RDS 数据库实例的指标。

查看性能指标

您应定期监控性能指标以查看各种时间范围内的平均值、最大值和最小值。通过这样做,您可以确定性能下降的时间。您还可以针对特定指标阈值设置 Amazon CloudWatch 警报,以便在达到这些阈值时向您发出警报。

要排除性能问题,了解系统的基准性能十分重要。设置新的数据库实例并让它在典型工作负载下运行时,您应按一些不同的间隔 (例如,一小时、24 小时、一周、两周) 来捕获所有性能指标的平均值、最大值和最小值,以了解运行状况。这有助于将操作的高峰时间与非高峰时间进行比较。您随后可以利用这些信息确定性能何时降到标准水平以下。

查看性能指标

  1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 在左侧导航窗格中,选择 Instances,然后选择数据库实例。

  3. 选择 Show Monitoring。前八个性能指标随即显示。指标默认显示当日的信息。

  4. 使用右上角的编号按钮可翻阅其他指标页,或选择 Show All 查看所有指标。

  5. 可以选择性能指标来调整时间范围,以便查看当日之外的数据。可以更改 StatisticTime RangePeriod 值以调整显示的信息。例如,要查看某个指标在最近两个星期内每天的峰值,请将 Statistic 设置为 Maximum,将 Time Range 设置为 Last 2 Weeks,并将 Period 设置为 Day

    注意

    StatisticTime RangePeriod 值的更改将应用于所有指标。更新的值会在您的会话的剩余时间内保持有效,直到您再次更改它们。

还可以使用 CLI 或 API 查看性能指标。有关更多信息,请参阅 查看数据库实例指标

设置 CloudWatch 警报

  1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  2. 在左侧导航窗格中,选择 Instances,然后选择数据库实例。

  3. 选择 Show Monitoring,然后选择一个性能指标以显示扩展的视图。

  4. 选择 Create Alarm

  5. Create Alarm 页面上,通过在 Send a notification to 框中选择值,指定接收警报的电子邮件地址。如果需要,可选择该框右侧的 create topic 以创建新的警报收件人。

  6. Whenever 列表中,选择要设置的警报统计数据。

  7. of 框中,选择警报指标。

  8. Is 框及其右侧不带标签的框中,设置警报阈值,如下所示:

    Create Alarm 对话框
  9. For at least 框中,输入要触发警报而必须达到指定阈值的次数。

  10. consecutive period(s) of 框中,选择要触发警报而必须达到阈值的时间段。

  11. Name of alarm 框中,输入警报的名称。

  12. 选择 Create Alarm

性能指标页面随即出现,可以在 CloudWatch Alarms 状态栏中看到新警报。如果您没有看到该状态栏,请刷新页面。

评估性能指标

数据库实例有一些不同类别的指标,确定可接受的值的方式取决于具体的指标。

CPU

  • CPU 使用率 – 使用的计算机处理容量的百分比。

内存

  • 可用内存 – 数据库实例上可用的 RAM 量 (以兆字节为单位)。

  • 交换区使用情况 – 数据库实例使用的交换空间量 (以兆字节为单位)。

磁盘空间

  • 可用存储空间 – 数据库实例当前未使用的磁盘空间量 (以 MB 为单位)。

输入/输出操作

  • 读取 IOPS,写入 IOPS – 每秒进行的磁盘读取或写入操作平均数。

  • 读取延迟,写入延迟 – 读取或写入操作的平均时间 (以毫秒为单位)。

  • 读取吞吐量,写入吞吐量 – 每秒对磁盘读取或写入的平均兆字节数。

  • 队列深度 – 等待对磁盘写入或读取的 I/O 操作数。

网络流量

  • 网络接收吞吐量,网络传输吞吐量 – 每秒出入数据库实例的网络流量速率 (以兆字节为单位)。

数据库连接

  • 数据库连接 – 连接到数据库实例的客户端会话数。

有关可用性能指标的各个更详细的说明,请参阅 Amazon RDS 维度与指标

一般而言,性能指标的可接受值取决于您的基准性能以及应用程序执行的操作。应调查相对于基准性能的一致或趋势性变化。有关特定类型指标的建议如下:

  • 高 CPU 或 RAM 消耗 – 较高的 CPU 或 RAM 消耗值可能是正常情况,只要它们符合您的应用程序的目标 (如吞吐量或并发度) 并且是预期情况。

  • 磁盘空间消耗 – 如果使用的空间始终不低于总磁盘空间的 85%,则应调查磁盘空间消耗。应查看是否可以从实例中删除数据或是将数据存档到其他系统以释放空间。

  • 网络流量 – 对于网络流量,应与系统管理员进行讨论,以了解域网络和 Internet 连接的预期吞吐量。如果吞吐量始终低于预期,则应调查网络流量。

  • 数据库连接 – 如果发现用户连接数较高,同时实例性能下降并且响应时间延长,请考虑约束数据库连接。数据库实例的最佳用户连接数因您的实例类所执行操作的复杂性而异。您可以通过将数据库实例与 User Connections 参数设置为 0 (无限制) 之外的值的参数组关联,指定数据库连接的数目。您可以使用现有参数组或新建一个。有关更多信息,请参阅 使用数据库参数组

  • IOPS 指标 – IOPS 指标的预期值取决于磁盘规格和服务器配置,因此请使用您的基准来了解典型状况。调查值是否始终与您的基准不同。要获得最佳 IOPS 性能,请确保典型工作集适合内存大小,以最大程度减少读取和写入操作。

对于与性能指标有关的问题,提高性能的首要手段之一是优化最常使用和成本最高昂的查询,以了解这是否会减少对系统资源的压力。有关更多信息,请参阅 优化查询

如果优化查询后问题仍然存在,请考虑将您的 Amazon RDS 数据库实例类升级为具有更多与所遇问题相关的资源 (CPU、RAM、磁盘空间、网络带宽,I/O 容量) 的实例类。

优化查询

提高数据库实例性能的最佳方式之一是优化最常使用和占用最多资源的查询,以降低其运行成本。

MySQL 查询优化

有关编写查询以实现更佳性能的更多信息,请转到 MySQL 文档中的优化 SELECT 语句。还可以转到 MySQL 性能调整和优化资源以了解其他查询优化资源。

Oracle 查询优化

有关编写和分析查询以实现更佳性能的更多信息,请转到 Oracle 文档中的数据库 SQL 优化指南

SQL Server 查询优化

请转到 SQL Server 文档中的分析查询以针对 SQL Server 数据库实例改进查询。您还可以使用与执行、索引和 I/O 相关的数据管理视图 (DMV) (在动态管理视图和功能文档中进行了介绍) 以排除 SQL Server 查询问题。

查询优化的一个常见途径是创建有效的索引。您可以使用 Database Engine Tuning Advisor 实现数据库实例的潜在索引改进。有关更多信息,请参阅 使用 SQL Server Tuning Advisor 分析 Amazon RDS 数据库实例上的数据库工作负载

PostgreSQL 查询优化

请转到 PostgreSQL 文档中的使用 EXPLAIN 以了解如何分析查询计划。您可以参考此信息修改查询或底层表以提高查询性能。还可以转到使用显式 JOIN 子句控制计划程序来获取有关如何在查询中指定联接以获得最佳性能的提示。

MariaDB 查询优化

有关编写查询以实现更佳性能的更多信息,请转到 MariaDB 文档中的查询优化

MySQL 存储引擎使用最佳实践

在 MySQL 数据库实例上,观察以下表创建限制:

  • 如果您使用的是预配置 IOPS 存储或使用的是通用存储且实例的大小为 200 GB 或更大,则将限制为 10000 个表。

  • 如果您使用的是标准存储或使用的是通用存储且实例的大小不到 200 GB,则将限制为 1000 个表。

我们之所以推荐这些限制,是因为大量的表明显增加了故障转移或数据库崩溃后的数据库恢复时间。如果您需要创建的表数多于建议的数量,请将 innodb_file_per_table 参数设置为 0。有关更多信息,请参阅 使用 InnoDB 表空间改善崩溃恢复时间 和 使用数据库参数组

对于使用 5.7 版或更高版本的 MySQL 数据库实例,由于 InnoDB 崩溃恢复已改进,可超出这些表创建限制。但是,我们仍建议您谨慎行事,因为创建大量表可能会影响性能。

在 MySQL 数据库实例中,请避免数据库中的表增长得过大。预配置的存储限制将 MySQL 表文件的最大大小限制为 6 TB。请对大型表进行分区,以将文件大小限制在 6 TB 以内。此方法还可以提高性能并缩短恢复时间。有关更多信息,请参阅 MySQL 文件大小限制

适用于 MySQL 的 Amazon RDS 的时间点恢复和快照恢复功能要求使用崩溃恢复存储引擎,且仅支持 InnoDB 存储引擎。尽管 MySQL 支持功能不同的多种存储引擎,但并非所有引擎都为崩溃恢复和数据耐久性而进行了优化。例如,MyISAM 存储引擎不支持可靠的崩溃恢复,并且可能使时间点恢复或快照恢复无法按预期工作。这可能导致在崩溃后重启 MySQL 时丢失或损坏数据。

InnoDB 是 Amazon RDS 上的 MySQL 数据库实例的推荐和支持的存储引擎。InnoDB 实例还可迁移到 Aurora,而 MyISAM 实例无法迁移。但是,如果您需要高强度的全文搜索功能,MyISAM 的效果比 InnoDB 更好。如果您仍然选择对 Amazon RDS 使用 MyISAM,遵循使用不支持的 MySQL 存储引擎进行自动备份中概述的步骤可能在某些情况下对执行快照恢复功能会有所帮助。

如果您要将现有 MyISAM 表转换为 InnoDB 表,您可以使用 MySQL 文档中概述的过程。MyISAM 和 InnoDB 各有优缺点,所以请在执行转换前充分评估转换可能对您的应用程序造成的影响。

此外,适用于 MySQL 的 Amazon RDS 当前不支持联合存储引擎。

MariaDB 存储引擎使用最佳实践

适用于 MariaDB 的 Amazon RDS 的时间点恢复和快照恢复功能要求使用崩溃恢复存储引擎,且仅支持 XtraDB 存储引擎。尽管 MariaDB 支持功能不同的多种存储引擎,但并非所有引擎都针对崩溃恢复和数据耐久性而进行了优化。例如,尽管 Aria 是 MyISAM 的崩溃安全替代,但它仍可能使时间点恢复或快照恢复无法按预期工作。这可能导致在崩溃后重启 MariaDB 时丢失或损坏数据。

XtraDB 是 Amazon RDS 上的 MariaDB 数据库实例的推荐和支持的存储引擎。如果您仍然选择对 Amazon RDS 使用 Aria,遵循使用不支持的 MariaDB 存储引擎进行自动备份中概述的步骤可能在某些情况下对执行快照恢复功能会有所帮助。

使用 PostgreSQL 的最佳实践

在以下两种情况下,您可对 Amazon RDS 使用 PostgreSQL 来提高性能:将数据加载到数据库实例中时和使用 PostgreSQL autovacuum 功能时。以下各节涵盖了我们针对以下情况建议的一些实例。

将数据加载到 PostgreSQL 数据库实例中

在将数据加载到 Amazon RDS PostgreSQL 数据库实例中时,您应修改数据库实例设置和数据库参数组值,以便能够最有效地将数据导入数据库实例中。

对数据库实例设置进行以下修改:

  • 禁用数据库实例备份 (将 backup_retention 设置为 0)

  • 禁用多可用区

修改数据库参数组以包括以下设置。您应测试参数设置以查找对数据库实例最有效的设置:

  • 增大 maintenance_work_mem 参数的值. 有关 PostgreSQL 资源消耗参数的更多信息,请参阅 PostgreSQL 文档

  • 增加 checkpoint_segmentscheckpoint_timeout 参数的值可减少对 wal 日志进行写入的次数。

  • 禁用 synchronous_commit 参数 (不关闭 FSYNC)。

  • 禁用 PostgreSQL autovacuum 参数.

pg_dump -Fc (压缩) 或 pg_restore -j (并行) 命令与这些设置结合使用。

使用 fsync 和 full_page_writes 数据库参数

在 Amazon RDS 上的 PostgreSQL 9.4.1 中,fsync full_page_writes 数据库参数不可修改。禁用 fsync full_page_writes 数据库参数可能会导致数据损坏,因此我们为您启用了这两个参数。我们建议使用其他 9.3 数据库引擎版本的 PostgreSQL 的客户不要禁用 fsync full_page_writes 参数。

使用 PostgreSQL Autovacuum 功能

PostgreSQL 数据库的 autovacuum 功能是我们强烈向您推荐的一项功能,您可使用此功能保持 PostgreSQL 数据库实例正常运行。Autovacuum 自动执行 VACUUM 和 ANALYZE 命令;使用 autovacuum 是 PostgreSQL 所需的而不是 Amazon RDS 强制的,并且使用此功能对于获得良好性能是至关重要的。默认情况下,为所有新的 Amazon RDS PostgreSQL 数据库实例启用此功能,并将正确设置相关的配置参数。

您的数据库管理员需要知道和了解此维护操作。有关 autovacuum 功能的 PostgreSQL 文档,请访问 http://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM

Autovacuum 不是一个“不占用资源”的操作,但它将会在后台运行并尽可能地在让位于用户操作。启用后,autovacuum 将检查是否有包含大量更新的或删除的元组的表。它还可防止因事务 ID 重现导致丢失非常旧的数据。

Autovacuum 不应被视为是一种开销较高的操作 (可减少此类操作以获得更佳性能)。相反,如果未运行 autovacuum,则更新和删除速度较快的表的性能将随时间推移而快速降低。

重要

不运行 autovacuum 可能导致最终需要中断工作来执行侵入性更强的 vacuum 操作。当 Amazon RDS PostgreSQL 数据库实例因过于谨慎地使用 autovacuum 而变得不可用时,PostgreSQL 数据库将关闭以进行自我保护。此时,Amazon RDS 必须直接在数据库实例上执行单一用户模式完全 vacuum,这会导致多个小时的中断。 因此,强烈建议您不要关闭默认启用的 autovacuum。

autovacuum 参数确定 autovacuum 运行的时间和难度。 autovacuum_vacuum_thresholdautovacuum_vacuum_scale_factor 参数确定 autovacuum 运行的时间。autovacuum_max_workersautovacuum_nap_timeautovacuum_cost_limitautovacuum_cost_delay 参数确定 autovacuum 运行的难度。有关 autovacuum、其运行时间和所需参数的更多信息,请参阅 PostgreSQL 文档

以下查询显示名为 table1 的表中的“不活动”元祖数:

Copy
PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname =  ’table1' order by n_dead_tup desc;

查询结果将与下面类似:

Copy
relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

使用 SQL Server 的最佳实践

利用 SQL Server 数据库实例实现多可用区部署的最佳实践包括:

  • 使用 Amazon RDS 数据库事件来监控故障转移。例如,当数据库实例发生故障转移时,您会收到文本消息或电子邮件通知。有关 Amazon RDS 事件的更多信息,请参阅 使用 Amazon RDS 事件通知

  • 如果您的应用程序缓存了 DNS 值,则将生存时间 (TTL) 设置为小于 30 秒的值。在发生故障转移的情况下 (IP 地址可能发生更改,而且缓存值可能不再可用),对 TTL 进行这样的设置是一个好的做法。

  • 建议您不要 启用以下模式,因为它们会关闭多可用区所需的事务日志记录:

    • Simple 恢复模式

    • 离线模式

    • 只读模式

  • 进行测试以确定您的数据库实例执行故障转移所需的时长。故障转移时间会因使用的数据库类型、实例类和存储类型而异。如果发生故障转移,还应测试您的应用程序继续运行的能力。

  • 若要缩短故障转移时间,您应执行以下操作:

    • 确保为您的工作负载分配了足够的预配置 IOPS。I/O 不足会导致延长故障转移时间。数据库恢复需要 I/O。

    • 使用小型事务。数据库恢复依赖于事务,因此,如果您可将大型事务分成多个小型事务,则您的故障转移时间将缩短。

  • 在故障转移期间,请考虑到延迟可能会有所提升。作为故障转移过程的一部分,Amazon RDS 自动将您的数据复制到新的备用实例。该复制意味着新数据将提交到两个不同的数据库实例,因此,在备用数据库实例赶上新的主数据库实例的进度之前,可能会出现一些延迟。

  • 在所有可用区内部署您的应用程序。如果某个可用区出现故障,您在其他可用区内的应用程序仍将可用。

在使用 SQL Server 的多可用区部署时,请记住,Amazon RDS 会映射您的实例上的所有 SQL Server 数据库。如果不希望映射特定数据库,请设置不使用这些数据库的多可用区的单独数据库实例。

使用数据库参数组

我们建议,在将参数组更改应用于生产数据库实例前,您应当在测试数据库实例上试验数据库参数组更改。在数据库参数组内不恰当地设置数据库引擎参数可能会产生意外的不利影响,包括性能降低和系统不稳定。修改数据库引擎参数时应始终保持谨慎,并且在修改数据库参数组前要备份数据库实例。有关备份数据库实例的信息,请参阅备份和还原 Amazon RDS 数据库实例

Amazon RDS 最佳实践演示视频

芝加哥 2016 AWS 峰会包括有关使用 Amazon RDS 创建和配置安全、高度可用的数据库实例的最佳实践的演示。可在此处获取演示视频: