Other day I was setting up a high availability cluster
environment and ran into to an interesting problem. I followed all necessary
instruction for setup a RSS server. However, RSS stuck in recovery process and
message log on primary serer reported error that could not send log. For
example, when executed following command on RSS server to set data replication
type:
onmode -d RSS <primary server name>
The
RSS server stuck in recovery mode and message log on primary server showing
following messages:
RSS Server <RSS server name> -
state is now connected
Can not send log <log
number>
The log
number mentioned in error message was not close to the current log on primary
or RSS server. For example, current log on primary was 7438 and
on RSS 7436 but message log stating ‘Can not send log 825241904’. So, from
where server getting a out of sequence log number?
Initially I though it some kind of corruption. However, after some investigation
figured out, I was using delayed
application (DELAY_APPLY) on RSS server
and the directory specified with LOG_STAGING_DIR configuration parameter holding
some unwanted file(s). For example, file 'ifmxUniqueLog_825241904' in LOG_STAGING_DIR.
So, during recovery RSS server requested to primary for log number 825241904
but that log not exists on primary server.
Once I removed all files from the LOG_STAGING_DIR
directory on RSS server
able to successfully set the high availability cluster
environment. Conclusion, next
time you try to setup a RSS with DELAY_APPLY, make sure nothing is in the LOG_STAGING_DIR on RSS server.
-Sanjit Chakraborty
100
0
