Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,55 +1,55 @@
|
||||
---
|
||||
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 是实际测量值）
|
||||
---
|
||||
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 是实际测量值）
|
||||
|
||||
Reference in New Issue
Block a user