Aurora Global Database, cross-Region read replica và ElastiCache Multi-AZ
EC2 instance có thể được launch lại từ AMI trong vài phút, nhưng dữ liệu đã mất thì không khôi phục được; mỗi data store cần một cơ chế bảo vệ riêng.
EC2 instance của web tier có thể được launch lại trong vài phút, nhưng dữ liệu thì không: đơn hàng đã mất không thể khôi phục. MFTECH có ba thành phần dữ liệu, mỗi thành phần cần một cơ chế bảo vệ riêng:
- Aurora lưu đơn hàng: mục tiêu RPO ≤ 5 phút, RTO ≤ 15 phút khi toàn bộ Region gặp sự cố, và đội vận hành không muốn tự phát triển script.
- RDS PostgreSQL của ứng dụng kho hàng: đã bật Multi-AZ, nhưng chưa có thành phần nào tại Region khác.
- ElastiCache Redis lưu giỏ hàng và phiên đăng nhập: chỉ có backup hằng ngày.
Chọn một tình huống, sau đó chọn nút chạy. Thay đổi cấu hình và chạy lại để so sánh.
Aurora Global Database replicate dữ liệu ở storage layer sang Region khác bằng hạ tầng chuyên dụng, với độ trễ thường dưới 1 giây. Khi Region chính gặp sự cố ngoài kế hoạch, thao tác failover promote một secondary cluster thành cluster chính, thường trong vài phút; RTO tính bằng phút và RPO thường tính bằng giây (phụ thuộc replication lag tại thời điểm sự cố). Với thay đổi có kế hoạch, thao tác switchover chuyển Region chính mà không mất dữ liệu; trên các engine version đủ điều kiện, thời gian gián đoạn thường dưới 30 giây. Dịch vụ này còn cho phép người dùng tại Region phụ đọc dữ liệu với độ trễ thấp. Các phương án tự triển khai bằng DMS, read replica promote thủ công hoặc script copy snapshot đều khả thi nhưng thời gian khôi phục dài hơn và chi phí vận hành cao hơn.
- Aurora yêu cầu RPO tính bằng giây, RTO tính bằng phút giữa các Region: Aurora Global Database.
- RDS cần chịu được sự cố cấp Region: cross-Region read replica (promote khi cần) và sao chép automated backup sang Region khác; Multi-AZ chỉ bảo vệ trước sự cố của một AZ.
- Redis yêu cầu downtime thấp và mất ít dữ liệu: Multi-AZ với automatic failover, không phải backup hằng ngày.
Aurora Global Database, cross-Region read replicas and ElastiCache Multi-AZ
EC2 instances can be launched again from an AMI in minutes, but lost data cannot be recovered; each data store needs its own protection mechanism.
Web tier EC2 instances can be launched again in minutes, but data cannot: lost orders cannot be recovered. MFTECH has three data components, each needing its own protection mechanism:
- Aurora stores orders: target RPO ≤ 5 minutes, RTO ≤ 15 minutes when the entire Region fails, and the operations team does not want to develop its own scripts.
- RDS PostgreSQL for the inventory application: Multi-AZ is enabled, but nothing exists in another Region yet.
- ElastiCache Redis stores shopping carts and login sessions: only daily backups.
Chọn một tình huống, sau đó chọn nút chạy. Thay đổi cấu hình và chạy lại để so sánh.
Aurora Global Database replicates at the storage layer to another Region using dedicated infrastructure, with latency typically under 1 second. When the primary Region has an unplanned outage, a failover promotes a secondary cluster to be the primary cluster, typically within minutes; RTO is measured in minutes and RPO is typically measured in seconds (depending on the replication lag at the time of the failure). For planned changes, a switchover moves the primary Region without data loss; on eligible engine versions, the downtime is typically under 30 seconds. The service also lets users in the secondary Region read data with low latency. Self-built approaches with DMS, manually promoted read replicas or snapshot-copy scripts all work, but they take longer to recover and cost more to operate.
- Aurora needing an RPO in seconds and an RTO in minutes across Regions: Aurora Global Database.
- RDS that must survive a Region-level failure: a cross-Region read replica (promoted when needed) and copying automated backups to another Region; Multi-AZ only protects against the failure of one AZ.
- Redis needing low downtime and little data loss: Multi-AZ with automatic failover, not daily backups.