高可用架构：达梦的全方位容灾方案
你有没有想过：
数据库的高可用，到底在解决什么问题？
很多人会说：「就是让数据库不宕机呗。」
这话只说对了一半。高可用真正要解决的是：在可控时间内恢复服务，同时最小化数据丢失。
今天，我们来全面了解达梦数据库的高可用架构体系。
高可用的两个核心指标
RTO（Recovery Time Objective）：恢复时间目标
从故障发生到服务恢复的最大允许时间。
故障发生 → 检测故障 → 切换/恢复 → 服务上线
│ │ │ │
└──────────┴───────────┴──────────┘
↑
这个时间就是 RTORPO（Recovery Point Objective）：恢复点目标
允许丢失的最大数据量，以时间衡量。
RPO = 0 → 零数据丢失（同步复制）
RPO = 1h → 允许丢失最多 1 小时的数据（异步复制）| 业务场景 | RTO | RPO |
|---|---|---|
| 核心金融系统 | < 1 分钟 | 0 |
| 交易系统 | < 5 分钟 | 0 或秒级 |
| 运营系统 | < 30 分钟 | 分钟级 |
| 报表系统 | < 1 小时 | 小时级 |
达梦高可用架构全景图
┌─────────────────────────────────────────────────────────────┐
│ 应用层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 连接池(Druid)│ │ 连接池(Hikari)│ │ JDBC直连 │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └───────────────────┼───────────────────┘ │
│ │ │
│ ┌───────────────▼───────────────┐ │
│ │ 服务名路由(dm_svc) │ │
│ └───────────────┬───────────────┘ │
└──────────────────────────────┼──────────────────────────────┘
│
┌──────────────────────────────▼──────────────────────────────┐
│ 高可用集群 │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 数据守护集群 │ │ 读写分离集群 │ │
│ │ (Data Guard) │ │ (RW Cluster) │ │
│ │ │ │ │ │
│ │ ┌─────────┐ │ │ ┌─────────┐ │ │
│ │ │ 主库 │ │ │ │ 主库 │ │ │
│ │ └───┬────┘ │ │ └───┬────┘ │ │
│ │ │实时同步 │ │ │ │ │
│ │ ┌───▼────┐ │ │ ┌──▼────┐ │ │
│ │ │ 备库1 │ │ │ │ 备库1 │ │ │
│ │ └───┬────┘ │ │ ├───┬───┤ │ │
│ │ │ │ │ │ 备库2 │ │ │
│ │ ┌───▼────┐ │ │ └───┬───┘ │ │
│ │ │ 备库2 │ │ │ │ │ │
│ │ └────────┘ │ │ ▼ │ │
│ └──────────────────┘ │ 备库N │ │
│ └──────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ MPP 大数据集群 │ │ 实时应用集群 │ │
│ │ │ │ (ScaleDB) │ │
│ │ ┌────┐┌────┐┌────┐│ │ │ │
│ │ │ EP ││ EP ││ EP ││ │ 多主多备集群 │ │
│ │ └──┬─┘└──┬─┘└──┬─┘│ │ │ │
│ │ │ │ │ │ │ │ │
│ │ ┌──▼┐┌──▼┐┌───▼─┐│ │ │ │
│ │ │ DN ││ DN ││ DN ││ │ │ │
│ │ └────┘└────┘└─────┘│ └──────────────────┘ │
│ └──────────────────────┘ │
└──────────────────────────────────────────────────────────────┘不同场景的高可用方案
场景一：小型系统（单实例 + 本地备份）
适用：开发测试环境、小型生产系统
成本：低
复杂度：低
RTO：小时级
RPO：天级
方案：
- 单机部署
- 每日全量备份
- 定期异地备份场景二：中小企业（主备集群 + 本地备份）
适用：一般生产系统
成本：中
复杂度：中
RTO：分钟级
RPO：秒级（同步模式）或分钟级（异步模式）
方案：
- 一主一备或一主两备
- 实时日志同步
- 自动故障切换
- dm_svc.conf 配置服务名场景三：中大型企业（数据守护 + 读写分离）
适用：有一定并发压力的系统
成本：中高
复杂度：高
RTO：秒级
RPO：秒级
方案：
- 数据守护保证高可用
- 读写分离分担查询压力
- 多个备库提供只读服务
- 应用层连接池 + 服务名自动切换场景四：大型企业（MPP + 多集群）
适用：大数据量、高并发分析系统
成本：高
复杂度：高
RTO：分钟级
RPO：取决于架构设计
方案：
- MPP 集群处理分析查询
- 主备集群处理 OLTP 业务
- 数据同步中间件打通两个集群
- 多地容灾高可用架构设计原则
1. 消除单点故障
java
// 应用层：连接池 + 服务名路由
public class HaConnectionDemo {
public DataSource createHaDataSource() {
// dm_svc.conf 配置多个节点
// 连接池自动处理故障切换
DruidDataSource ds = new DruidDataSource();
ds.setJdbcUrl("jdbc:dm://DAMENG_SERVICE"); // 使用服务名
ds.setUsername("SYSDBA");
ds.setPassword("******");
ds.setPoolPreparedStatements(true);
return ds;
}
}ini
# dm_svc.conf
DAMENG=(
192.168.1.10:5236, # 主库
192.168.1.11:5236, # 备库1
192.168.1.12:5236 # 备库2
)
SWITCH_TIME=3
SWITCH_INTERVAL=102. 多层冗余
应用层：多实例部署
↓
网关层：负载均衡
↓
数据库层：主备集群
↓
网络层：双网卡bonding
↓
存储层：RAID / 双活存储3. 定期演练
sql
-- 高可用演练检查清单
-- 1. 验证备份是否可用
RESTORE DATABASE ... FROM ARCHIVELOG ...;
-- 2. 验证故障切换是否正常
-- 执行主备切换
$ dmasmsvr tool racswitch ...
-- 3. 验证数据一致性
-- 对比主备库数据
SELECT COUNT(*) FROM critical_table; -- 两边应该一致
-- 4. 验证应用重连
-- 检查应用日志，确认自动重连成功监控与告警
sql
-- 高可用状态监控
SELECT
INSTANCE_NAME,
INSTANCE_ROLE,
INSTANCE_STATUS,
UP_TIME
FROM V$INSTANCE;
-- 守护进程状态
SELECT
GROUP_NAME,
DW_TYPE,
DW_MODE,
DW_STATUS
FROM V$DMRW_CLUSTER;java
// 高可用监控告警
public class HaMonitor {
public void monitor() {
// 检查主库是否可用
boolean primaryAlive = checkPrimaryAlive();
// 检查备库同步延迟
long lag = getReplicationLag();
// 检查守护进程状态
boolean guardianAlive = checkGuardianAlive();
// 综合判断高可用状态
if (!primaryAlive && !guardianAlive) {
sendAlert("高可用集群全部故障！");
} else if (lag > 10000) {
sendAlert("同步延迟过大: " + lag);
}
}
}面试追问方向
- 达梦的 RPO 和 RTO 能做到多少？
- 主备集群和读写分离集群有什么区别？
- 如何设计一个 RPO=0、RTO<60秒 的高可用方案？
一句话总结
高可用不是一道选择题，而是必答题。RTO 和 RPO 是设计的标尺，架构选型是手段，监控演练是保障。没有银弹，只有适合场景的方案。