运维管理7 分钟阅读
写了一个 OGG MA 同步监控脚本
2026年10月20日阅读—点赞—收藏—
OGGMA
内容阅读
在知识库中专注阅读，并随时返回相关工具与课程
前言
最近处理了一套 Oracle GoldenGate 同步故障，目标端 Replicat 报错：
1Error mapping from2app_schema.business_table3to APP_SCHEMA.BUSINESS_TABLE刚开始看到 Error mapping，第一反应还是表结构、字段映射或者元数据不一致。
结果继续检查，发现是目标端表空间满了。
表空间的问题倒是不难处理，后面也补上了自动扩容任务。但这次故障让我发现另一个问题：这套 OGG 没有完善的同步状态告警，出了问题还得人工登录页面查看。
于是顺手写了一个 OGG MA 同步监控脚本，把进程状态、同步延迟和邮件告警都加了进去，文末也分享给大家！
一、先看看这次的 OGG 环境
这套环境使用的是 Oracle GoldenGate Microservices Architecture，版本为 21.20.0.0.0。
源端和目标端分别部署了 OGG 微服务，通过 Administration Server 管理 Extract 和 Replicat。
与传统 OGG 不同，MA 架构可以直接通过 REST API 获取进程状态，不一定需要登录服务器执行 GGSCI。
例如查询目标端 Replicat：
1curl --digest -sS -u ogg_monitor \2 "http://192.0.2.20:7810/services/v2/replicats"再查询具体进程：
1curl --digest -sS -u ogg_monitor \2 "http://192.0.2.20:7810/services/v2/replicats/R_APP/info/status"这里使用 Digest 认证，密码交互输入。
接口返回的内容大致如下，以下数据保留了本次故障的延迟和检查点数值，进程名称及路径已脱敏：
1{2 "response": {3 "status": "running",4 "processId": 12345,5 "lag": 172899,6 "sinceLagReported": 8,7 "position": {8 "name": "rt",9 "sequence": 2228,10 "offset": 19807024911 }12 }13}注意这里的两个值：
1status = running2lag = 172899进程确实在运行，但同步延迟已经达到 172899 秒，也就是 48 小时 1 分 39 秒。
这也是我觉得最有必要监控的地方：
OGG 进程正常，不代表数据同步正常。
二、表空间恢复以后，数据还要慢慢追
处理完表空间问题后，我又连续查了几次 Replicat。
结果如下：
从这些数据能看出来，Replicat 一直在追赶积压。
虽然进程状态都是 RUNNING，但前面几次的同步延迟仍然很高。
直到最后一次检查：
1E_APP status=running lag=1s2R_APP status=running lag=0s这次积压才算基本消化完成。
当然，Lag 恢复到 0，并不等于所有业务表的数据一致性都已经校验过。这里只能说明 OGG 报告的同步延迟已经恢复正常。
三、写个脚本监控起来
这套环境使用 OGG MA 21.20，可以直接调用 REST API，所以没有必要再去解析 GGSCI 输出。
主要检查以下几项：
其中检查点需要特别注意：
不能简单地认为 Sequence 或 Offset 不变化就是故障。如果源端没有新的业务事务，检查点不推进也可能是正常现象。
所以脚本会结合 Lag 和检查点变化进行判断，出现疑似停滞时仍然需要 DBA 进一步确认。
四、脚本部署与使用
考虑到每个人的 OGG 环境不一样，最后把脚本整理成了通用版本。
主脚本负责调用 REST API、解析状态、判断异常和发送邮件，监控地址、告警阈值以及 SMTP 信息都放在独立配置文件里。
以后换一套环境，基本只需要修改配置，不用再动主脚本。
修改监控配置
脚本主要包含两个文件：
1ogg_ma_monitor.sh # 监控主脚本2ogg_ma_monitor.conf # 配置文件先修改 ogg_ma_monitor.conf：
1ENDPOINTS=(2 '生产源端|http://192.0.2.10:7810|extract'3 '生产目标端|http://192.0.2.20:7810|replicat'4)56AUTH_FILE=/home/oracle/.ogg_monitor_curl.conf7STATE_DIR=/home/oracle/jobs/.ogg_monitor_state89WARN_LAG=30010CRIT_LAG=90011STALE_SECONDS=90012REMIND_SECONDS=36001314CURL_TIMEOUT=201516SMTP_HOST=192.0.2.3017SMTP_PORT=2518SMTP_TIMEOUT=151920MAIL_FROM=ogg-alert@example.com21MAIL_TO=dba@example.com这里主要修改三部分：OGG REST API 地址、同步延迟阈值和 SMTP 邮件配置。
ENDPOINTS 支持配置多个监控端点，每个端点分别指定名称、地址和进程类型。脚本会自动查询对应的 Extract 或 Replicat，不需要把进程名称写死。
WARN_LAG 和 CRIT_LAG 分别是警告和严重告警阈值，单位为秒。这里设置为 300 秒和 900 秒，可以根据业务对同步实时性的要求调整。
REMIND_SECONDS 是重复告警间隔，默认 3600 秒，也就是持续异常每小时提醒一次。
以上 IP 和邮箱均为示例，实际部署时替换成自己的环境信息即可。
配置 REST API 认证
OGG MA 的 REST API 需要身份认证。
为了避免把账号密码直接写在主脚本里，我单独创建了一个 curl 配置文件，用来保存 OGG 的认证信息。
1cat > /home/oracle/.ogg_monitor_curl.conf <<'EOF'2user = "ogg_monitor:YOUR_OGG_PASSWORD"3digest4EOF将账号和密码替换成自己的 OGG REST API 账号信息。这里的 digest 表示使用 HTTP Digest 认证。
由于文件保存了明文密码，记得限制权限：
1chmod 600 /home/oracle/.ogg_monitor_curl.conf配置完成以后，可以先用 curl 测试一下：
1curl -sS --fail-with-body \2 --config /home/oracle/.ogg_monitor_curl.conf \3 "http://192.0.2.20:7810/services/v2/replicats"如果服务器的 curl 版本较老，不支持 --fail-with-body，可以换成 -f。
正常情况下，接口会返回 Replicat 列表的 JSON 数据。这样可以先确认 REST API 地址、账号密码和网络访问都没有问题，再运行监控脚本。
执行监控脚本
配置完成后，先手动执行一次：
1cd /home/oracle/jobs2chmod 750 ogg_ma_monitor.sh3./ogg_ma_monitor.sh正常情况下，会输出类似下面的结果：
1生产源端 extract E_APP2status=running lag=1s seq=NA offset=NA OK34生产目标端 replicat R_APP5status=running lag=0s seq=2287 offset=307538150 OK这里的进程名称已经脱敏。部分 Extract 接口没有返回可解析的检查点位置时，脚本会显示 NA，不代表进程异常。
除了正常检查，脚本还提供了两个测试参数。
测试 HTML 邮件：
1./ogg_ma_monitor.sh --test-mail强制发送当前真实异常告警：
1./ogg_ma_monitor.sh --force-mail其中 --force-mail 主要用于跳过重复告警限制，方便测试当前异常通知。如果进程已经恢复正常，并且历史状态中记录过异常，也可能触发恢复邮件。
确认检查结果和邮件发送都正常以后，再加入 crontab：
1* * * * * /home/oracle/jobs/ogg_ma_monitor.sh >/dev/null 2>&1每分钟检查一次，监控日志和历史告警状态保存在 STATE_DIR 目录下。
查看最近的检查记录：
1tail -50 /home/oracle/jobs/.ogg_monitor_state/monitor.log最后说一下邮件告警的规则。
脚本不会每检查一次就发一封邮件，而是记录每个监控对象的历史状态。首次发现异常立即通知，异常级别发生变化时重新通知，持续异常默认每小时提醒一次，恢复正常以后再发送一封恢复邮件。
正常情况下不发邮件。
这也是我最初写这个脚本的目的，平时让它自己检查就行，真正出现同步异常时，再通知 DBA 处理。
脚本已经上传到 ORA100：https://ora100.com/script-library/ogg-ma-monitor
页面里有完整源码，也支持直接复制和下载。
六、最后
这次故障从表空间满开始，后面又经历了 OGG 积压、同步追赶、脚本监控和邮件告警配置。最后一次检查，Extract 和 Replicat 都是 RUNNING，同步延迟也恢复到了正常水平。
这套脚本不算复杂，主要是解决一个实际问题：不能只知道 OGG 进程有没有运行，还要知道数据有没有及时同步。
之前需要登录页面人工检查，现在可以交给定时任务。正常的时候不用管，真正出问题了再发邮件提醒。
对于日常 DBA 运维来说，这样就够用了。