本文为您介绍旧的 Store 已经不可用，远端数据库增量日志未清理的前提下，增量同步任务在 OMS 进行断点续传的恢复过程。
背景信息
源库网络中断几个小时，网络恢复后，OMS 同步链路中有两条出现异常，其中一条在网络中断前已将源端 Store、目标端 Store、目标端 Writer 停止。网络恢复正常后，启动源端 Store 失败，报 0 store instance in memory。
另外一条在网络中断前未停止，网络恢复正常后同步位点一直卡住不刷新，get SCN 报错。
操作步骤
如果源库 Log 仍存在，您可以通过以下方式断点续传，恢复同步链路。
- 修复源端 Store。
- 执行以下命令，新增一个 Store。
curl ${CM_URL}/crawler/start -d “topic=${SUB_TOPIC_NAME}&checkpoint=::::${START_TIME}:&role=master&type=DELIVER2STORE”
说明
- ${CM_URL}的值通过 /home/ds/supervisor/package/config/drc.properties查看 cm.url获取。
- ${SUB_TOPIC_NAME}通过 /home/ds/storexxx/conf/crawler.conf查看 subTopic获取。
/home/ds/storexxx/conf/crawler.conf中的 storexxx指有问题的 Store。
- ${START_TIME}通过 /home/ds/storexxx/conf/crawler.conf查看 master.timestamp获取。
- 启动新增的 Store 后，请停止并删除错误的 Store。
curl ${CM_URL}/crawler/stop -d “crawler=${STORE_NAME}” curl ${CM_URL}/crawler/clear -d “crawler=${STORE_NAME}” curl ${CM_URL}/crawler/destroy -d “crawler=${STORE_NAME}”
-
恢复源端 Store 后，重新启动目标端 Writer。
-
确认重新启动的 Store 是否正常。
查看监控，重新启动的 Store 的起始位点早于指定的 START_TIME，最新位点在实时推进，则说明重新启动的 Store 正常。
- 查看源和目标位点是否已刷新增量数据。