跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

如何部署Far Sync实例_零数据丢失与长距离传输的结合

Far Sync部署前必须满足三个前提:主库开启FORCE LOGGING;LOG_ARCHIVE_DEST_n配置SYNC AFFIRM与NET_TIMEOUT≤30并指向Far Sync的DB_UNIQUE_NAME;Far Sync主机能稳定访问主库传输端口且时间偏差≤5秒。 Far Sync 实例部署前必须确认的 3 个前提 far sync 不是加台机器就能用的“插件”,它本质是 oracle data guard 架构中一个特殊角色的物理 standby,依赖主库的实时归档(archivelog + force logging)和网络低延迟同步能力。没满足这三点,部署完也起不来,或者起得来但不生效。
FORCE LOGGING
必须在主库开启:否则 DML 操作可能绕过重做记录,Far Sync 收不到完整变更流 主库
LOG_ARCHIVE_DEST_n
配置必须包含
SYNC AFFIRM
+
NET_TIMEOUT
(建议 ≤30),且目标指向 Far Sync 的
DB_UNIQUE_NAME
Far Sync 实例所在主机必须能稳定访问主库的
standby redo logs
传输端口(默认 1521),且时间偏差 ≤5 秒(
ntpd
或
chronyd
必须跑着) 创建 Far Sync 实例时最容易配错的参数 Far Sync 不开实例进程、不挂数据文件、不启 MRP,但它对
init.ora
参数极其敏感。常见错误是照搬普通 standby 的配置,结果启动报
ORA-16664: unable to retrieve the result from a database
或反复断连。
FAL_SERVER
和
FAL_CLIENT
必须设为空(
''
):Far Sync 不参与归档缺失拉取,设了反而触发无意义重试
DB_UNIQUE_NAME
必须与
LOG_ARCHIVE_DEST_n
中指定的一致,大小写敏感;主库配置里写的是
far_sync_01
,这里就不能写成
FarSync01
STANDBY_FILE_MANAGEMENT
必须为
MANUAL
:Far Sync 不管理数据文件,设
AUTO
会导致启动卡在控制文件验证阶段
LOG_ARCHIVE_CONFIG
要显式列出所有参与节点,例如:
'DG_CONFIG=(primary_db,far_sync_01,physical_standby_01)'
,漏掉任意一个,
DGMGRL
就认不出拓扑 Far Sync 启动后立刻要验证的 2 个关键状态 启动
SQL*Plus
连上去看到
OPEN MODE = READ ONLY WITH APPLY
并不表示 Far Sync 在工作——它压根不该 open。真正有效的状态藏在后台日志和 DG 视图里。 查
V$DATAGUARD_STATS
:重点关注
transport lag
和
apply lag
,二者都应稳定在
+00 00:00:00
;若 transport lag 持续增长,说明主库归档没成功推到 Far Sync 的 standby redo log 查
V$ARCHIVE_DEST_STATUS
:对应 Far Sync 的
DEST_ID
行,
STATUS
必须是
VALID
,
ERROR
列为空,
TRANSMIT_MODE
是
SYNC
,
DELAY_MINS
是
0
别信
SELECT DATABASE_ROLE FROM V$DATABASE
:Far Sync 返回
PHYSICAL STANDBY
是对的,不是 bug;但它不会显示
FAR SYNC
字样——这个角色只在
DGMGRL SHOW CONFIGURATION
里体现 主库切换后 Far Sync 自动失效的典型表现与修复 Far Sync 在 switchover 后不会自动重连新主库,这是设计使然,不是故障。现象是原主库变 standby 后,Far Sync 日志里持续刷
ORA-16778: redo transport error
,DG Broker 显示
Warning: ORA-16778
,但不报错也不告警。 必须手动在新主库上执行:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=far_sync_01 SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=far_sync_01';
(注意
DEST_2
编号要和原配置一致) Far Sync 本体不需要重启,但需在新主库上执行
ALTER SYSTEM SWITCH LOGFILE
触发一次归档推送,之后观察
V$ARCHIVE_DEST_STATUS
是否恢复
VALID
如果用了
DGMGRL
,切完后立即运行
EDIT DATABASE 'far_sync_01' SET PROPERTY 'LogXptMode'='SYNC';
,否则 Broker 可能沿用旧模式缓存 Far Sync 的“零丢失”保障完全依赖主库归档流的完整性校验,而这个校验只发生在主库侧。任何网络抖动、防火墙策略变更、甚至临时 DNS 解析失败,都会让 transport lag 突然跳升——监控不能只看是否连接,得盯住秒级 lag 值本身。

相关文章