OMS增量同步组件不稳定(已开启日志归档)

【 使用环境 】生产环境
【 OB or 其他组件 】OB、OMS
【 使用版本 】4.2.1.7、4.2.6
【问题描述】
1、增量同步不稳定
2、重启OMS之后依旧不行
【附件及日志】
1、增量同步不稳定


2、重启OMS之后依旧不行


![1ac76afeddd33cf450646ad7bdbf3f2|690x276]

重启OMS之后依旧不行的日志
connector.log (40.7 KB)
error.log (117 字节)
libobcdc.7z (1.2 MB)

1 个赞

你查一下 这个进程ps -ef|grep oms-supervisor

1 个赞
[root@localhost ~]# ps -ef|grep oms-supervisor
1000     17056 15715  4 14:00 pts/0    00:03:44 java -server -Xms2g -Xmx2g -Xmn1g -Xss1024k -verbose:gc -Xloggc:./log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:MetaspaceSize=256m -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:HeapDumpPath=/home/ds/supervisor -XX:+HeapDumpOnOutOfMemoryError -Dsun.reflect.inflationThreshold=0 -Dserver.port=9000 -DconfigDir=/u01/ds/supervisor/config/ -Dspring.main.allow-circular-references=true -Ddb2.jcc.charsetDecoderEncoder=3 -Doracle.jdbc.javaNetNio=false -jar ./bin/oms-supervisor.jar
1000     18420 15715  2 14:01 pts/0    00:02:06 java -server -Xms2g -Xmx2g -Xmn1g -Xss1024k -verbose:gc -Xloggc:./log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:MetaspaceSize=256m -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:HeapDumpPath=/home/ds/supervisor -XX:+HeapDumpOnOutOfMemoryError -Dsun.reflect.inflationThreshold=0 -Dserver.port=9000 -DconfigDir=/u01/ds/supervisor/config/ -Dspring.main.allow-circular-references=true -Ddb2.jcc.charsetDecoderEncoder=3 -Doracle.jdbc.javaNetNio=false -jar ./bin/oms-supervisor.jar
root     19785 22606  0 15:32 pts/0    00:00:00 grep --color=auto oms-supervisor
1000     30405 15715  2 14:04 pts/0    00:02:14 java -server -Xms2g -Xmx2g -Xmn1g -Xss1024k -verbose:gc -Xloggc:./log/gc.log -XX:+PrintGC -XX:+PrintGCDetails -XX:MetaspaceSize=256m -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:HeapDumpPath=/home/ds/supervisor -XX:+HeapDumpOnOutOfMemoryError -Dsun.reflect.inflationThreshold=0 -Dserver.port=9000 -DconfigDir=/u01/ds/supervisor/config/ -Dspring.main.allow-circular-references=true -Ddb2.jcc.charsetDecoderEncoder=3 -Doracle.jdbc.javaNetNio=false -jar ./bin/oms-supervisor.jar
1 个赞

你那这个几个进程 全部kill了
重新启的数据迁移项目 试一下

1 个赞

日志要是归档了,store设置的起始同步位点在已归档时间之前,是否影响增量同步拉取数据

1 个赞

系统租户oceanbase库下执行如下查询SQL
WITH palf_log_stat AS (
SELECT
tenant_id,
MAX(begin_scn) AS palf_available_start_scn,
MIN(end_scn) AS palf_available_latest_scn,
SCN_TO_TIMESTAMP(MAX(begin_scn)) AS palf_available_start_scn_display,
SCN_TO_TIMESTAMP(MIN(end_scn)) AS palf_available_latest_scn_display
FROM GV$OB_LOG_STAT
WHERE tenant_id & 0x01 = 0 or tenant_id = 1
GROUP BY tenant_id
),
archivelog_stat AS (
SELECT
a.tenant_id AS tenant_id,
MIN(b.start_scn) AS archive_start_scn,
a.checkpoint_scn AS archive_latest_scn,
a.checkpoint_scn_display AS archive_available_latest_scn_display
FROM CDB_OB_ARCHIVELOG a
LEFT JOIN CDB_OB_ARCHIVELOG_PIECE_FILES b
ON a.tenant_id = b.tenant_id AND a.round_id = b.round_id
AND b.file_status != ‘DELETED’ AND a.STATUS = ‘DOING’
GROUP BY a.tenant_id
)
SELECT
pls.tenant_id,
pls.palf_available_start_scn,
pls.palf_available_latest_scn,
pls.palf_available_start_scn_display AS palf_available_start_scn_display,
pls.palf_available_latest_scn_display AS palf_available_latest_scn_display,
als.archive_start_scn AS archive_available_start_scn,
als.archive_latest_scn AS archive_available_latest_scn,
CASE WHEN als.archive_start_scn IS NOT NULL THEN SCN_TO_TIMESTAMP(als.archive_start_scn) ELSE NULL END AS archive_available_start_scn_dispalay,
als.archive_available_latest_scn_display
FROM palf_log_stat pls
LEFT JOIN archivelog_stat als ON pls.tenant_id = als.tenant_id
GROUP BY pls.tenant_id, pls.palf_available_start_scn;
你查一下 位点的信息

*************************** 1. row ***************************
                           tenant_id: 1
            palf_available_start_scn: 1732678925779297135
           palf_available_latest_scn: 1734682376652291264
    palf_available_start_scn_display: 2024-11-27 11:42:05.779297
   palf_available_latest_scn_display: 2024-12-20 16:12:56.652291
         archive_available_start_scn: NULL
        archive_available_latest_scn: NULL
 archive_available_start_scn_display: NULL
archive_available_latest_scn_display: NULL
*************************** 2. row ***************************
                           tenant_id: 1002
            palf_available_start_scn: 1734596696792648935
           palf_available_latest_scn: 1734682376600194571
    palf_available_start_scn_display: 2024-12-19 16:24:56.792648
   palf_available_latest_scn_display: 2024-12-20 16:12:56.600194
         archive_available_start_scn: 1733967138158489085
        archive_available_latest_scn: 1734662195763027748
 archive_available_start_scn_display: 2024-12-12 09:32:18.158489
archive_available_latest_scn_display: 2024-12-20 10:36:35.763027
2 rows in set (0.023 sec)


启动位点以及距离启动位点最近的数据字典的snapshot_scn需要位于这个区间就可以 你看看是不是

如何拉取已归档的?
需求:增量同步起始位点 2024-12-18 22:22:00

问一下 相关的同学 后面给你答复

开始位点如果不在clog中,默认就会从归档中取,如果归档也没有就会报错

现在需要的开始位点【2024-12-18 22:22:00】,在已归档日志中

[root@localhost ~]# ll /data/nfs_server/backup/archive/
总用量 8
drwx------. 2 nfsnobody nfsnobody   53 12月 12 09:31 check_file
-rw-------. 1 nfsnobody nfsnobody  148 12月 12 09:31 format.obbak
drwx------. 5 nfsnobody nfsnobody  220 12月 13 09:34 piece_d1001r1p1
drwx------. 5 nfsnobody nfsnobody  220 12月 14 09:34 piece_d1001r1p2
drwx------. 5 nfsnobody nfsnobody  220 12月 15 09:34 piece_d1001r1p3
drwx------. 5 nfsnobody nfsnobody  220 12月 16 09:34 piece_d1001r1p4
drwx------. 5 nfsnobody nfsnobody  220 12月 17 09:34 piece_d1001r1p5
drwx------. 5 nfsnobody nfsnobody  220 12月 18 09:34 piece_d1001r1p6
drwx------. 5 nfsnobody nfsnobody  220 12月 19 09:35 piece_d1001r1p7
drwx------. 5 nfsnobody nfsnobody  220 12月 20 11:06 piece_d1001r1p8
drwx------. 5 nfsnobody nfsnobody  105 12月 20 11:06 piece_d1001r1p9
drwx------. 2 nfsnobody nfsnobody 4096 12月 20 11:06 pieces
drwx------. 2 nfsnobody nfsnobody   39 12月 12 09:32 rounds
[root@localhost ~]# ll /data/nfs_server/backup/archive/piece_d1001r1p7/*
-rw-------. 1 nfsnobody nfsnobody 39898 12月 19 09:35 /data/nfs_server/backup/archive/piece_d1001r1p7/file_info.obarc
-rw-------. 1 nfsnobody nfsnobody    76 12月 19 09:35 /data/nfs_server/backup/archive/piece_d1001r1p7/piece_d1001r1p7_20241218T093218_20241219T093217.obarc
-rw-------. 1 nfsnobody nfsnobody   179 12月 19 09:35 /data/nfs_server/backup/archive/piece_d1001r1p7/single_piece_info.obarc
-rw-------. 1 nfsnobody nfsnobody   855 12月 18 09:34 /data/nfs_server/backup/archive/piece_d1001r1p7/tenant_archive_piece_infos.obarc

/data/nfs_server/backup/archive/piece_d1001r1p7/checkpoint:
总用量 4
-rw-------. 1 nfsnobody nfsnobody 200 12月 18 09:34 checkpoint_info.0.obarc
-rw-------. 1 nfsnobody nfsnobody   0 12月 19 09:34 checkpoint_info.1734571937996434248.obarc

/data/nfs_server/backup/archive/piece_d1001r1p7/logstream_1:
总用量 4
-rw-------. 1 nfsnobody nfsnobody 132 12月 19 09:35 file_info.obarc
drwx------. 2 nfsnobody nfsnobody  57 12月 19 07:42 log
drwx------. 2 nfsnobody nfsnobody  39 12月 18 09:34 schema_meta

/data/nfs_server/backup/archive/piece_d1001r1p7/logstream_1001:
总用量 160
-rw-------. 1 nfsnobody nfsnobody 39803 12月 19 09:35 file_info.obarc
drwx------. 2 nfsnobody nfsnobody 77824 12月 19 09:31 log

我看明白了,谢谢分享!

求稳定