Oracle Data Guard Broker RedoRoutes 属性配置文档

一、文档概述

1.1 核心说明

RedoRoutes 是 Oracle Data Guard Broker(以下简称 DG Broker)中的关键路由配置属性 ,用于替代传统 Data Guard 中复杂的 LOG_ARCHIVE_DEST_nLOG_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)处于 MOUNTEDOPEN READ ONLY 状态;
  • 主备库之间网络连通:监听服务正常,tnsnames.ora 中已配置所有数据库的连接串;
  • 主库日志模式:已启用 ARCHIVELOG 模式,且 FORCE LOGGING 已开启(确保所有数据变更生成 Redo 日志)。

二、RedoRoutes 核心作用

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

三、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 物理级联备库 异地灾备库,从本地备库接收日志(减少主库带宽占用)

需求

  1. 主库(PRIMARY_DB)优先向本地备库(STBY_LOCAL)直接传输 Redo 日志;
  2. 异地级联备库(STBY_CASCADE)不直接接收主库日志,而是从本地备库(STBY_LOCAL)级联接收日志;
  3. 若本地备库不可用,主库直接向异地备库传输日志(兜底策略)。

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 承担了以下关键角色:

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

六、常见问题与排查

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

  • 排查 1:本地备库是否启用日志转发(LogXptMode 是否为 SYNCASYNC),执行 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 高可用灾备架构中的关键配置项。

相关推荐
JIngJaneIL2 小时前
远程在线诊疗|在线诊疗|基于java和小程序的在线诊疗系统小程序设计与实现(源码+数据库+文档)
java·数据库·vue.js·spring boot·小程序·毕设·在线诊疗小程序
川石课堂软件测试2 小时前
自动化过程中验证码的解决思路
数据库·python·功能测试·测试工具·单元测试·tomcat·自动化
IT利刃出鞘3 小时前
WordPress插件--Redis Object Cache对象缓存插件的用法
数据库·redis·缓存
面向星辰3 小时前
sql通配符(大量查找搜索索引)
数据库·sql
斐硕人3 小时前
SQL滚动求和
数据库·sql·mysql·maxcompute
爬山算法3 小时前
Redis(135)Redis的网络模型是什么?
网络·数据库·redis
L.EscaRC3 小时前
Redis大Key与内存不足问题深度解析与应对策略
数据库·redis·缓存
雲烟4 小时前
Qt SQLite在I.mx8上使用问题
数据库·qt·i.mx8
TDengine (老段)4 小时前
TDengine 转换函数 CAST 用户手册
java·大数据·数据库·物联网·时序数据库·tdengine·涛思数据