Amazon SOA-C02: 資料庫與快取 — 學習指南

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

屬於 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 會在另一個 AZ 建立一個同步的備用執行個體 — 由 AWS 管理，能在數分鐘內自動容錯移轉，不需手動提升，且備用執行個體無法用於讀取。Aurora 分離了寫入者與讀取者端點：寫入者是一個由主執行個體支援的叢集端點，而 Aurora 使用分散式儲存，會自動跨 AZ 複寫，且因為儲存是共享的，通常能比 RDS 更快地進行容錯移轉。

使用以下方式設定備份與保留期：

• 自動備份：啟用並設定保留期 (例如：modify-db-instance –backup-retention-period 7)。對於支援的引擎，這能在保留期間內提供任意秒數的時間點復原 (PITR)。
• 手動快照：使用 create-db-snapshot (或對 Aurora 使用 create-db-cluster-snapshot) 來擷取一個會被保留的快照；快照會一直存在直到您刪除為止。
• PITR 還原：對 RDS 使用 aws rds restore-db-instance-to-point-in-time，或對 Aurora 使用 restore-db-cluster-from-snapshot 然後再建立執行個體。

決策標準：

• 當寫入可用性至關重要，且不需要在備用執行個體上進行讀取時，使用 Multi-AZ 來實現高可用性與自動容錯移轉。
• 當您需要高 IOPS、快速容錯移轉以及儲存自動擴展時，使用 Aurora (叢集式儲存)。
• 使用讀取複本來擴展讀取流量及進行跨區域災難復原 (它們是非同步的，且可以被提升)。

維運 CLI 範例：

• 啟用 Multi-AZ：aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
• 建立手動快照：aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
• 還原 PITR：aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

讀取複本、容錯移轉與複寫策略

讀取複本是非同步的複本 (RDS 或 Aurora 讀取器)，主要用於擴展讀取流量及分擔報表負載。它們會產生複寫延遲 (監控 ReplicaLag 指標)，不適用於強一致性的場景。讀取複本可以被提升為獨立的資料庫執行個體，以支援災難復原。

複寫策略與選擇：

• 同步 (RDS Multi-AZ 備用執行個體) — 保證零資料漂移，備用執行個體上沒有讀取容量。
• 非同步讀取複本 — 擴展讀取、啟用跨區域複本，但有複寫延遲及容錯移轉時可能遺失資料的風險。
• Aurora 讀取器 — 提供叢集式讀取端點，透過端點重新路由實現低延遲容錯移轉，並自動平衡讀取器端點的負載。

維運模式：

• 建立讀取複本：aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
• 提升複本：aws rds promote-read-replica –db-instance-identifier read1
• 監控：使用 CloudWatch 的 DatabaseConnections、ReplicaLag、ReadIOPS、WriteIOPS 及 Performance Insights 來決定何時新增或移除複本。

決策標準：

• 如果您需要寫入的高可用性，請選擇 Multi-AZ。如果您需要讀取吞吐量及分析負載分擔，請選擇讀取複本或 Aurora 讀取器。
• 對於跨區域災難復原，可在目標區域建立讀取複本，並考慮使用自動快照複製或 DMS 進行遷移。

使用 ElastiCache 進行快取與快取失效

ElastiCache 提供 Redis 與 Memcached 來降低資料庫負載與延遲。當您需要持久性、複寫、資料結構以及具備 Multi-AZ 和自動容錯移轉的高可用性時，請選擇 Redis。當您需要簡單的水平擴展快取，且優先考量分片與多執行緒效能時，請選擇 Memcached。

關鍵設定與模式：

• 建立具備複本與 Multi-AZ 的 Redis 叢集：aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
• 使用 Redis 的叢集模式 (cluster mode enabled) 來擴展分片；Memcached 則需要客戶端雜湊 (client-side hashing) 來進行分片。
• 逐出策略：volatile-lru、allkeys-lru、noeviction — 根據您在記憶體滿時，偏好僅逐出過期鍵還是任何鍵來進行調整。
• 監控 CacheHits 與 CacheMisses 來計算快取命中率：命中率 = CacheHits / (CacheHits + CacheMisses)。目標是維持高命中率以減少資料庫讀取。

快取失效策略：

• Cache-aside (旁路快取)：應用程式先檢查快取，若未命中則讀取資料庫並填入快取；在寫入時明確地讓快取過期或刪除。
• Write-through (寫入穿透) / Write-behind (寫入回沖)：快取寫入會傳播至資料庫；Write-behind 會批次處理資料庫寫入 (增加複雜度)。
• 存留時間 (TTL)：對於可接受過期資料的內容設定保守的 TTL；結合快取版本控制或失效鍵 (invalidation keys) 來處理結構變更或大量失效。
• 在需要時，使用 Redis pub/sub 或 Lambda 事件來通知應用程式執行個體，以進行分散式失效。

資料庫參數群組、擴展與監控

參數群組控制著引擎特定的設定 (例如：max_connections、innodb_buffer_pool_size)。RDS 對於執行個體使用 DB 參數群組，對於 Aurora 則使用 DB 叢集參數群組。變更某些參數需要重新啟動 (apply pending-reboot)，而其他參數則會立即套用。

管理模式：

• 建立與修改參數群組：aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; then 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 和最主要的等待事件。
• 啟用 Enhanced Monitoring 並設定精細度 (例如，用於故障排除時設為 1 秒)。
• 對於無伺服器或高並行應用程式，使用 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 來實現寫入高可用性 (HA) 和同步複寫。
• 忽略快取失效機制：設計 TTL、版本化金鑰或事件驅動的失效機制；避免僅依賴短 TTL 來確保資料正確性。
• 未正確啟用自動備份或設定保留期：將 backup-retention-period 設定為 >0，並透過測試還原來驗證 PITR；確保目標區域中可用於快照複製的 KMS 金鑰。
• 修改參數群組後未重新啟動：檢查 ApplyMethod；對於需要重新啟動才能生效的參數，應安排在維護時段內重啟，以避免非預期的停機。
• 擴展時未管理連線：若不使用 RDS Proxy 或連線池，僅增加執行個體類型可能無法解決連線風暴；應實作連線池來管理大量短生命週期的連線。

實務問題：使用情境

Acme Retail 公司執行一個 MySQL RDS 主要資料庫，其讀取流量繁重，且偶爾有分析工作的高峰；他們在夜間 ETL 過程中面臨複本延遲，並觀察到高連線流失導致 CPU 飆升。

1. 為分析工作啟用一個額外的讀取複本群組，與應用程式的讀取器隔離，並將其放置在不同的可用區 (AZ) 或區域以供災難備援 (DR)。
2. 設定複本監控 (ReplicaLag 指標)，並增加自動擴展邏輯，當延遲或 ReadLatency 超過閾值時增加讀取器。
3. 在應用程式前端部署 RDS Proxy 以多工處理連線並減少連線流失；在參數群組中適當調整 max_connections。
4. 將分析工作移至使用分析專用的複本，並透過 ElastiCache Redis 採用 Cache-Aside (旁路快取) 模式，搭配適當的 TTL 來減少重複的查詢。
5. 測試容錯移轉與還原程序：在預備環境的執行個體上執行一次 PITR 還原，並驗證複本提升的步驟。

這種方法分離了讀取工作負載，減少了主要資料庫的連線壓力，並利用快取來降低資料庫的讀取量。它遵循 AWS 的最佳實務，結合了讀取擴展、連線池管理以及經過測試的備份/還原流程，以維持可用性與營運彈性。

← 運算與 Auto Scaling · 所有領域 · 無伺服器與應用程式整合 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →