56 lines
2.0 KiB
Markdown
56 lines
2.0 KiB
Markdown
---
|
||
title: "RTO"
|
||
type: concept
|
||
tags:
|
||
- AWS
|
||
- Disaster Recovery
|
||
- High Availability
|
||
- Cloud Architecture
|
||
sources:
|
||
- ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
|
||
last_updated: 2026-04-23
|
||
---
|
||
|
||
## Overview
|
||
RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。
|
||
|
||
## Definition
|
||
- **RTO**：系统从故障中恢复的时间目标
|
||
- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标
|
||
|
||
## AWS Database RTO 对比
|
||
|
||
| 数据库服务 | AZ 故障 RTO | 架构特点 |
|
||
|-----------|------------|----------|
|
||
| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 |
|
||
| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 |
|
||
| **传统自建** | 数小时 | 需手动恢复 |
|
||
|
||
## RTO vs RPO
|
||
|
||
| 指标 | 定义 | 衡量内容 |
|
||
|------|------|----------|
|
||
| **RTO** | 恢复时间目标 | 系统不可用的最大时长 |
|
||
| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 |
|
||
|
||
## Key Insights
|
||
- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据
|
||
- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接
|
||
- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面
|
||
- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例
|
||
|
||
## Related Concepts
|
||
- [[RPO]]：Recovery Point Objective，恢复点目标
|
||
- [[Disaster Recovery]]：灾备策略
|
||
- [[High Availability]]：高可用性
|
||
- [[Amazon Aurora]]：Aurora 的 RTO 优势
|
||
- [[Amazon RDS]]：RDS 的 RTO 特点
|
||
- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比
|
||
- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略
|
||
|
||
## Aliases
|
||
- Recovery Time Objective
|
||
- 恢复时间目标
|
||
- RTO
|
||
- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值）
|