Amazon SOA-C02: 数据库与缓存 — 学习指南
属于 AWS SysOps Administrator Associate SOA-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
数据库和缓存是 SysOps 管理员的核心运维职责：它们为应用程序提供持久性存储、可用性和低延迟读取。该领域涵盖运行托管关系型数据库 (RDS 和 Aurora)、扩展读/写容量、复制和故障转移行为，以及使用 ElastiCache 减轻数据库负载。正确配置备份、参数组、监控和缓存失效模式可以防止数据丢失并减少运维事件。
RDS 和 Aurora 的运维、备份与 Multi-AZ
RDS (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server) 和 Amazon Aurora (兼容 MySQL 和 PostgreSQL) 是具有不同运维语义的托管关系型引擎。RDS 的 Multi-AZ 在另一个可用区中创建一个同步备用实例——由 AWS 管理，可在数分钟内自动故障转移，无需手动提升，且备用实例不可用于读取。Aurora 分离了写入器和读取器端点：写入器是由主实例支持的集群端点，而 Aurora 使用跨可用区自动复制的分布式存储，并且由于存储是共享的，通常比 RDS 故障转移更快。
使用以下方式配置备份和保留期：
- 自动备份：启用并设置保留期（例如，
undefined
）。对于支持的引擎，这可以在保留窗口内提供到任意秒级的时间点恢复 (PITR)。
- 手动快照：使用
undefined
(或用于 Aurora 的
undefined
) 创建一个保留的快照；快照会一直存在，直到您删除它们。
- PITR 恢复：对于 RDS 使用
undefined
，或对于 Aurora 先使用
undefined
再创建实例。
决策标准：
- 当写入可用性至关重要且不需要在备用实例上进行读取时，使用 Multi-AZ 实现高可用性和自动故障转移。
- 当您需要高 IOPS、快速故障转移和存储自动扩展时，使用 Aurora (集群化存储)。
- 使用只读副本进行读取扩展和跨区域灾难恢复（它们是异步的，并且可以被提升）。
运维 CLI 示例：
- 启用 Multi-AZ：
undefined
- 创建自动快照：
undefined
- 恢复 PITR：
undefined
只读副本、故障转移和复制策略
只读副本是异步副本 (RDS 或 Aurora 读取器)，主要用于扩展读取流量和分载报告任务。它们会产生复制延迟 (监控 ReplicaLag 指标)，不适用于强一致性场景。只读副本可以提升为独立的数据库实例以支持灾难恢复。
复制策略和选择：
- 同步 (RDS Multi-AZ 备用实例) — 保证零数据偏差，备用实例上没有读取能力。
- 异步只读副本 — 扩展读取，支持跨区域副本，存在复制延迟和故障转移时潜在数据丢失的风险。
- Aurora 读取器 — 提供集群化的读取端点，通过端点重新路由实现低延迟故障转移，并自动平衡读取器端点。
运维模式：
- 创建只读副本：
undefined
- 提升副本：
undefined
- 监控：使用 CloudWatch 的 DatabaseConnections、ReplicaLag、ReadIOPS、WriteIOPS 和 Performance Insights 来决定何时添加或删除副本。
决策标准：
- 如果您需要写入的高可用性，请选择 Multi-AZ。如果您需要读取吞吐量和分析分载，请选择只读副本或 Aurora 读取器。
- 对于跨区域灾难恢复，在目标区域创建只读副本，并考虑使用自动快照复制或 DMS 进行迁移。
使用 ElastiCache 进行缓存与缓存失效
ElastiCache 提供 Redis 和 Memcached 以降低数据库负载和延迟。当您需要持久性、复制、数据结构以及通过 Multi-AZ 和自动故障转移实现的高可用性时，请选择 Redis。当分片和多线程性能是优先考虑的因素时，请选择 Memcached 进行简单的水平缓存。
关键配置和模式：
- 创建带有副本和 Multi-AZ 的 Redis 集群：
undefined
- 使用 Redis 的集群模式启用 (cluster mode enabled) 来扩展分片；Memcached 需要客户端哈希来进行分片。
- 驱逐策略：volatile-lru、allkeys-lru、noeviction — 根据您是倾向于仅在内存满时驱逐已过期的键，还是驱逐任何键来进行调整。
- 监控 CacheHits 和 CacheMisses 来计算缓存命中率：hit_ratio = CacheHits / (CacheHits + CacheMisses)。目标是高命中率以减少数据库读取。
缓存失效策略：
- 旁路缓存 (Cache-aside)：应用程序首先检查缓存，未命中则读取数据库并填充缓存；在写入时显式地使缓存过期或删除。
- 穿透写/回写 (Write-through/write-behind)：缓存的写入会传播到数据库；回写会批量处理数据库写入（增加了复杂性）。
- 生存时间 (TTL)：为可能过时的数据设置保守的 TTL；结合缓存版本控制或失效键来处理模式更改或批量失效。
- 在需要时，使用 Redis 的发布/订阅 (pub/sub) 或 Lambda 事件来通知应用程序实例以进行分布式失效。
数据库参数组、扩展和监控
参数组控制特定于引擎的设置（例如，max_connections、innodb_buffer_pool_size）。RDS 对实例使用数据库参数组，对 Aurora 使用数据库集群参数组。某些参数的更改需要重启（应用状态为 pending-reboot），而其他参数则会立即应用。
管理模式：
- 创建和修改参数组：aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”；然后 aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
- 扩展实例类：aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately（或在维护时段内以避免重启）。
- 存储自动扩展：为支持的引擎类型启用；Aurora 会自动扩展存储。
监控和扩展信号：
- 使用 CloudWatch（FreeableMemory、CPUUtilization、DatabaseConnections、WriteLatency、ReadLatency、DiskQueueDepth）和 Performance Insights 来分析慢 SQL 和主要等待事件。
- 启用增强监控并设置粒度（例如，1s 用于故障排查）。
- 使用 RDS Proxy 管理连接池，为无服务器或高并发应用程序减少连接风暴。
备份/恢复过程和迁移注意事项
备份和恢复必须是明确的且经过测试。自动备份在保留期内提供时间点恢复（PITR）；手动快照会一直保留直到被删除，并且可以跨区域复制以及使用不同的 KMS 密钥进行复制。恢复时要明确指定区域和时间戳。
常用恢复命令：
- 恢复到时间点 (RDS)：aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / 或指定 –restore-time
- 恢复快照（跨区域）：首先将 copy-db-snapshot 到目标区域，然后进行恢复。
迁移注意事项：
- 使用 AWS DMS 进行停机时间最短的迁移（异构/同构）。DMS 支持持续复制；确保源引擎设置正确（例如 MySQL 启用了 binlog）。
- 逻辑迁移（mysqldump、pg_dump）适用于简单的导出；物理快照恢复适用于大型数据集。
- 验证字符集、参数组差异以及用于加密快照的 KMS 密钥。
常见陷阱和决策标准
- 将备份恢复到错误的区域或错误的时间：在恢复前始终验证 –region 和 –restore-time；使用复制到目标区域的快照，并在预生产环境中测试恢复。
- 假设只读副本提供高可用性：请记住副本是异步的；使用 Multi-AZ 或 Aurora 实现写入高可用性和同步复制。
- 忽略缓存失效策略：设计 TTL、版本化键或事件驱动的失效策略；避免仅依赖短 TTL 来保证正确性。
- 未正确启用自动备份或设置保留期：将 backup-retention-period 设置为 >0，并通过测试恢复来验证 PITR；确保 KMS 密钥在目标区域可用以进行快照复制。
- 修改参数组后未重启：检查 ApplyMethod；对于需要重启的参数，在维护时段内安排重启，以避免意外停机。
- 在没有连接管理的情况下进行扩展：在不使用 RDS Proxy 或连接池的情况下增加实例类可能无法解决连接风暴问题；应实施连接池来管理大量短生命周期的连接。
实践问题：用例场景
Acme Retail 运行一个 MySQL RDS 主实例，该实例具有繁重的读取流量和偶尔的分析峰值；他们在夜间 ETL 期间面临副本延迟，并观察到高连接流失导致 CPU 峰值。
- 为分析工作负载启用一个额外的只读副本组，将其与应用程序读取器隔离，并将其放置在不同的可用区或区域以实现灾难恢复。
- 配置副本监控（ReplicaLag 指标）并添加自动扩展逻辑，以便在延迟或 ReadLatency 超过阈值时增加读取器。
- 在应用程序前面部署 RDS Proxy 以复用连接并减少连接流失；在参数组中适当调整 max_connections。
- 将分析作业转移到使用分析副本，并通过 ElastiCache Redis 采用旁路缓存（cache-aside）模式，设置适当的 TTL 以减少重复查询。
- 测试故障转移和恢复过程：在预生产（staging）实例上执行一次 PITR 恢复，并验证副本提升步骤。
这种方法分离了读取工作负载，减少了主实例的连接压力，并使用缓存来降低数据库的读取量。它遵循了 AWS 的最佳实践，结合了读取扩展、连接池和经过测试的备份/恢复流程，以保持可用性和操作弹性。
← 计算与自动伸缩 · 所有领域 · Serverless 与应用程序集成 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →