Oracle Data Guard Broker RedoRoutes 属性配置文档

最新推荐文章于 2025-11-23 21:47:20 发布

原创最新推荐文章于 2025-11-23 21:47:20 发布 · 582 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#oracle #数据库

一、文档概述

1.1 核心说明

RedoRoutes 是 Oracle Data Guard Broker（以下简称 DG Broker）中的关键路由配置属性，用于替代传统 Data Guard 中复杂的 LOG_ARCHIVE_DEST_n 和 LOG_ARCHIVE_TRANSPORT_DISABLE 等初始化参数，集中管理主数据库（Primary Database）的 Redo 日志传输路径。

通过 RedoRoutes，可灵活定义：主库向哪些备库（物理备库、逻辑备库、级联备库）传输 Redo 日志、日志传输的优先级，以及级联备库的日志来源（主库直接传输 vs 从其他备库级联传输），大幅简化多备库架构的日志流向配置。

1.2 适用场景

多备库架构（1 主 N 备）：需指定主库向部分备库直接传输，部分备库通过级联方式接收日志；
跨地域灾备：本地备库接收主库日志，异地备库从本地备库级联接收（减少主库网络带宽占用）；
动态调整日志流向：无需重启数据库或 DG Broker，实时修改日志传输路径；
与 Fast-Start Failover（FSFO）联动：故障切换后自动继承或调整 Redo 路由策略。

1.3 前置依赖

已部署 Oracle Data Guard 主备环境（支持 11gR2+ 版本，推荐 12c+ 以获得完整功能）；
已启用 DG Broker（通过 DGMGRL 命令行工具管理）；
主备库状态正常：主库（Primary）处于 OPEN 状态，备库（Standby）处于 MOUNTED 或 OPEN READ ONLY 状态；
主备库之间网络连通：监听服务正常，tnsnames.ora 中已配置所有数据库的连接串；
主库日志模式：已启用 ARCHIVELOG 模式，且 FORCE LOGGING 已开启（确保所有数据变更生成 Redo 日志）。

二、RedoRoutes 核心作用

集中化路由管理：替代分散的 LOG_ARCHIVE_DEST_n 参数，通过一个属性统一定义所有日志传输路径，降低配置复杂度；
灵活控制流向：支持 “主库→直接备库”“主库→中间备库→级联备库” 等多层路由，适配复杂灾备架构；
动态调整：通过 DGMGRL 实时修改 RedoRoutes，无需重启数据库或 DG Broker，配置立即生效；
与 DG Broker 深度集成：故障切换（Failover）或角色转换（Switchover）后，DG Broker 会自动调整 RedoRoutes，确保新主库的日志传输策略正确；
简化多备库负载均衡：可指定部分备库优先接收日志，或分散主库的日志传输压力（如本地备库直接传输，异地备库级联传输）。

三、RedoRoutes 语法规则

3.1 基础语法

RedoRoutes = (
  <目标备库标识1> : ( <日志来源1>, <日志来源2>, ... ),
  <目标备库标识2> : ( <日志来源1>, <日志来源2>, ... ),
  ...
)

3.2 关键参数说明

参数	含义	合法值示例
目标备库标识	接收 Redo 日志的备库在 DG Broker 中的唯一名称（通过 `show configuration` 查看）	`STBY_LOCAL`（本地备库）、`STBY_REMOTE`（异地备库）
日志来源	日志的发送端（主库或其他备库）	`PRIMARY`（主库）、`STBY_LOCAL`（其他备库名称）
可选参数（扩展）	日志传输的优先级、延迟阈值等（12c+ 支持）	`PRIORITY=1`（优先级 1，最高）、`LAG_LIMIT=30`（延迟阈值 30 秒）

3.3 语法约束

主库的 RedoRoutes 仅定义 “主库向外发送日志” 的路径，备库的 RedoRoutes 定义 “备库向级联备库转发日志” 的路径；
日志来源必须是当前架构中存在的数据库（主库或其他备库），且需确保来源库与目标库之间网络连通；
多个日志来源用逗号分隔，DG Broker 会按顺序尝试传输（前一个来源不可用时，自动切换到下一个）；
级联备库的日志来源必须是 “已接收主库日志的备库”（即中间备库需启用日志转发功能）。

四、详细配置案例

4.1 案例架构说明

假设现有以下 Data Guard 环境（1 主 2 备），通过 DG Broker 管理：

数据库角色	DG Broker 名称	服务器地址	数据库类型	核心作用
主库（Primary）	PRIMARY_DB	192.168.1.10	单实例 /rac	业务生产库，生成 Redo 日志
物理备库（Standby）	STBY_LOCAL	192.168.1.20	物理备库	本地灾备库，快速故障切换目标
级联备库（Cascaded）	STBY_CASCADE	10.0.0.30	物理级联备库	异地灾备库，从本地备库接收日志（减少主库带宽占用）

需求：

主库（PRIMARY_DB）优先向本地备库（STBY_LOCAL）直接传输 Redo 日志；
异地级联备库（STBY_CASCADE）不直接接收主库日志，而是从本地备库（STBY_LOCAL）级联接收日志；
若本地备库不可用，主库直接向异地备库传输日志（兜底策略）。

4.2 配置步骤

步骤 1：检查 DG Broker 环境状态

首先通过 DGMGRL 工具登录 DG Broker，确认环境状态正常：

-- 1. 登录 DG Broker（使用主库 SYSDBA 权限）
dgmgrl sys/Orcl123456@PRIMARY_DB

-- 2. 查看配置状态（确保所有数据库状态为 SUCCESS）
show configuration verbose;

预期输出（关键部分）：

Configuration - DG_CONFIG
  Protection Mode: MaxAvailability
  Members:
  PRIMARY_DB - Primary database
  STBY_LOCAL - Physical standby database
  STBY_CASCADE - Physical standby database (cascaded)
  Fast-Start Failover: Disabled
  Configuration Status:
  SUCCESS   (status updated 30 seconds ago)

步骤 2：查看当前 RedoRoutes 配置

默认情况下，DG Broker 会自动生成简单的 Redo 路由，可通过以下命令查看：

-- 查看主库的 RedoRoutes 配置
show database PRIMARY_DB RedoRoutes;

-- 查看本地备库的 RedoRoutes 配置（级联转发需配置此处）
show database STBY_LOCAL RedoRoutes;

默认输出（主库）：

RedoRoutes = '(STBY_LOCAL : (PRIMARY), STBY_CASCADE : (PRIMARY))'

（默认主库直接向两个备库传输日志，不符合需求，需修改）

步骤 3：修改主库 RedoRoutes 配置

按需求配置主库的日志路由：优先向 STBY_LOCAL 传输，STBY_CASCADE 从 STBY_LOCAL 级联接收，同时保留主库直接向 STBY_CASCADE 传输的兜底策略：

-- 修改主库 RedoRoutes（主库→STBY_LOCAL，STBY_CASCADE 优先从 STBY_LOCAL 接收）
edit database PRIMARY_DB set property RedoRoutes = 
'(
  STBY_LOCAL : (PRIMARY, PRIORITY=1),  -- 主库优先向本地备库传输（优先级1）
  STBY_CASCADE : (STBY_LOCAL, PRIMARY, PRIORITY=2)  -- 级联备库优先从本地备库接收，本地备库不可用时主库直接传输
)';

步骤 4：配置本地备库的日志转发功能

级联备库（STBY_CASCADE）从本地备库（STBY_LOCAL）接收日志，需启用 STBY_LOCAL 的 “日志转发” 功能，并配置其 RedoRoutes：

-- 1. 启用本地备库的日志转发（允许向级联备库转发 Redo 日志）
edit database STBY_LOCAL set property LogXptMode = 'SYNC';  -- 同步转发（确保无数据丢失）
edit database STBY_LOCAL set property RedoRoutes = 
'(
  STBY_CASCADE : (STBY_LOCAL, PRIORITY=1)  -- 本地备库向级联备库转发日志
)';

-- 2. 验证级联备库的日志来源配置
edit database STBY_CASCADE set property LogXptMode = 'SYNC';  -- 级联备库同步接收日志

步骤 5：激活配置并验证

修改完成后，需激活配置使修改生效，并验证 RedoRoutes 是否正确：

-- 激活配置（DG Broker 应用所有修改）
enable configuration;

-- 再次查看主库和本地备库的 RedoRoutes 配置
show database PRIMARY_DB RedoRoutes;
show database STBY_LOCAL RedoRoutes;

预期输出（主库）：

RedoRoutes = '(STBY_LOCAL : (PRIMARY, PRIORITY=1), STBY_CASCADE : (STBY_LOCAL, PRIMARY, PRIORITY=2))'

预期输出（本地备库）：

RedoRoutes = '(STBY_CASCADE : (STBY_LOCAL, PRIORITY=1))'

步骤 6：测试日志传输有效性

通过模拟业务操作生成 Redo 日志，验证日志传输路径是否符合预期：

-- 1. 在主库执行数据插入（生成 Redo 日志）
sqlplus sys/Orcl123456@PRIMARY_DB as sysdba
insert into test.t_user (id, name) values (1, 'test_redo_routes');
commit;
exit;

-- 2. 查看本地备库的日志应用状态（确认接收并应用主库日志）
dgmgrl sys/Orcl123456@PRIMARY_DB
show database STBY_LOCAL recovery progress;

预期输出（本地备库）：

Media Recovery Status: Active
Applied Redo Log File: +DATA/STBY_LOCAL/REDO01.LOG
Recovery Progress: 100% (applied all received redo)

-- 3. 查看级联备库的日志应用状态（确认从本地备库接收日志）
show database STBY_CASCADE recovery progress;

预期输出（级联备库）：

Media Recovery Status: Active
Applied Redo Log File: +DATA/STBY_CASCADE/REDO01.LOG
Recovery Progress: 100% (applied all received redo from STBY_LOCAL)

步骤 7：测试兜底策略（可选）

模拟本地备库故障，验证主库是否自动向级联备库直接传输日志：

-- 1. 关闭本地备库实例
sqlplus sys/Orcl123456@STBY_LOCAL as sysdba
shutdown abort;
exit;

-- 2. 在主库再次生成 Redo 日志
sqlplus sys/Orcl123456@PRIMARY_DB as sysdba
insert into test.t_user (id, name) values (2, 'test_failover_redo');
commit;
exit;

-- 3. 查看级联备库的日志来源（确认从主库直接接收）
dgmgrl sys/Orcl123456@PRIMARY_DB
show database STBY_CASCADE redoRoutes;
show database STBY_CASCADE recovery progress;

预期输出（级联备库）：

Recovery Progress: 100% (applied all received redo from PRIMARY)

（说明主库已自动切换日志来源，直接向级联备库传输）

4.3 案例补充：主库同时向多备库直接传输

若需求为 “主库同时向本地备库和异地备库直接传输日志，无级联”，则简化配置如下：

-- 主库 RedoRoutes 配置
edit database PRIMARY_DB set property RedoRoutes = 
'(
  STBY_LOCAL : (PRIMARY, PRIORITY=1),
  STBY_REMOTE : (PRIMARY, PRIORITY=2)
)';

-- 无需配置备库的 RedoRoutes（备库不转发日志）
show database STBY_LOCAL RedoRoutes;  -- 默认为空

五、RedoRoutes 在案例中的核心作用解析

在本案例的 “主库→本地备库→级联备库” 架构中，RedoRoutes 承担了以下关键角色：

明确日志流向优先级：通过 PRIORITY=1 定义 “本地备库优先接收主库日志”“级联备库优先从本地备库接收日志”，确保核心灾备节点（本地备库）优先获得日志，保障故障切换的快速性；
实现级联传输，降低主库压力：级联备库（异地）不直接占用主库的网络带宽，而是通过本地备库转发日志，尤其适合跨地域、低带宽场景，避免主库因多备库传输导致性能下降；
兜底容错：配置 STBY_CASCADE : (STBY_LOCAL, PRIMARY) 后，当本地备库故障时，主库自动切换为日志来源，确保异地备库仍能接收日志，无数据丢失风险；
简化配置管理：无需手动配置主库的 LOG_ARCHIVE_DEST_2（指向本地备库）、LOG_ARCHIVE_DEST_3（指向异地备库），也无需配置本地备库的 LOG_ARCHIVE_DEST_2（转发到级联备库），通过一个 RedoRoutes 属性即可统一管理；
动态适配角色转换：若发生故障切换（如主库故障，本地备库升级为主库），DG Broker 会自动调整新主库（原 STBY_LOCAL）的 RedoRoutes，使其向原主库（降级为备库）和级联备库传输日志，无需人工干预。

六、常见问题与排查

6.1 配置后级联备库无法接收日志

排查 1：本地备库是否启用日志转发（LogXptMode 是否为 SYNC 或 ASYNC），执行 show database STBY_LOCAL LogXptMode; 验证；
排查 2：本地备库与级联备库之间网络是否连通，测试 tnsping STBY_CASCADE（从本地备库服务器执行）；
排查 3：RedoRoutes 语法是否错误（如备库名称拼写错误、括号不匹配），执行 show configuration 确认备库名称；
排查 4：级联备库是否处于 MOUNTED 状态，执行 show database STBY_CASCADE status; 验证。

6.2 主库日志传输延迟

排查 1：RedoRoutes 中是否配置了 LAG_LIMIT 参数，若延迟超过阈值，可调整为 LAG_LIMIT=60（允许 60 秒延迟）；
排查 2：网络带宽是否不足，级联传输场景下优先检查本地备库与异地备库的网络速度；
排查 3：备库日志应用是否卡顿，执行 show database <备库名称> recovery progress; 查看应用进度。

6.3 故障切换后 RedoRoutes 失效

排查 1：故障切换后是否重新激活配置，执行 enable configuration; 重新应用配置；
排查 2：新主库的 RedoRoutes 是否自动更新，执行 show database <新主库名称> RedoRoutes; 验证，若未更新可手动修改。

七、总结

RedoRoutes 是 DG Broker 中简化 Redo 日志传输配置的核心属性，通过集中化、灵活化的路由定义，适配从简单（1 主 1 备）到复杂（1 主 N 备 + 级联）的各类 Data Guard 架构。

本案例通过 “主库→本地备库→级联备库” 的配置，充分体现了 RedoRoutes 在降低主库压力、保障数据一致性、容错兜底等方面的价值。实际配置时，需根据业务场景（如灾备级别、网络条件、性能要求）调整路由策略，核心原则是：优先保障核心备库（故障切换目标）的日志传输，再考虑级联或异地备库的路由优化。

通过 DGMGRL 工具可实时修改和验证 RedoRoutes，无需重启数据库，极大提升了 Data Guard 架构的可维护性和灵活性，是 Oracle 高可用灾备架构中的关键配置项。