今天处理的OGG问题比较另类,在此记录下。
早上开发人员反馈近期没看到kafka端的消息,来咨询是否ogg状态是否正常。
我检查了源端和目标端,没发现什么问题,仔细查看发现目标端的复制进程没了,开发确认说一直用的是这台服务器,猜测可能是测试环境,有人把进程删了。
开始恢复吧,因为是kafka,还是测试环境,只需要接上同步就行。
下边就开始了痛苦的恢复过程:
1、两端版本不一致
新增复制进程,指定了trail文件和起始位置
报错说版本不对,源端trail文件比目标端要高,导致无法复制
在源端抽取和投递进程都加上format release 12.2后启动
EXTTRAIL <trail file>, FORMAT RELEASE 12.2
RMTTRAIL <trail file>, FORMAT RELEASE 12.2
源端提示
ERROR OGG-01232 Receive TCP params error: TCP/IP error 104 (Connection reset by peer), endpoint: xx.xxx.xxx.xxx:7810.
需要前滚trail文件
alter extract 投递进程名, etrollover
2、mgr故障
OGG-00543 Unexpected Threading Library Failure. Error Code 16 (Device Or Resource Busy)
查询mos文档,得到以下处理方法
1. Stop ALL GoldenGate processes using GoldenGate Grid Infra Bundled Agent or stop manually via ggsci prompt
2. Make sure there are no left over processes/pid for GoldenGate by running
"ps -ef |grep $OGG_HOME" (use/check full path to GoldenGate home)
If there are any left over pids then "kill -9 <pid>"
3. Log to ggsci prompt on any of the nodes and run
delete datastore
create datastore mmap
4. Start GoldenGate processes using Grid Infrastructure bundled agent
5. "Test" GoldenGate "relocation" to a different node using the bundled agent
-----------
OGG-00543 Oracle GoldenGate Manager for Oracle, mgr.prm: Unexpected threading library failure. Error code 16 (Device or resource busy).
-----------
error in ggserr.log should be resolved
3、启动投递进程后发现并未正常投递
新增的投递进程需要指定trail文件号才行,否则默认从第一个trail编号的文件开始投递,找不到就不投递
alter extract 投递进程名,extseqno 抽取进程产生的编号, extrba 0
4、新建的复制进程不能正常复制
检查发现复制进程在找之前的trail文件,指定当前trail文件
ALTER REPLICAT 复制进程名, EXTSEQNO trail文件编号, EXTRBA 0