11gR2 RAC time with exception causes node down problem handling

   in the experimental environment 11204 ofRACenvironment, a node has appeared Downthe problem is lost. After you check the log information, OTCSSD The log information finds the following information:

2016-01-17 23:15:20.564: [ctss][1175029504]ctsscomm_recv_cb2:receive incoming Message event. Msgtype [3].

2016-01-17 23:15:20.564: [ctss][1175029504]ctsscomm_recv_cb4_2:receive Active version Change MSG. Old Active version [186647552] New active version [186647552].

2016-01-17 23:15:20.564: [ctss][1175029504]ctsscomm_recv_cb2:receive incoming Message event. Msgtype [2].

2016-01-17 23:15:20.564: [ctss][1175029504]ctssslave_msg_handler4_1:waiting for Slave_sync_with_master to finish sync Process. SYNC_STATE[3].

2016-01-17 23:15:20.564: [ctss][1168725760]ctssslave_swm2_3:received time Sync message from master.

2016-01-17 23:15:20.565: [ctss][1168725760]ctssslave_swm:sendtime{sec[1453043718], usec[550689]}, receivetime{sec[ 1453043720], usec[564960]}.

2016-01-17 23:15:20.565: [ctss][1168725760]ctssslave_swm:the RTT of Sync msg [2014271] is too large for time sync to Be accurate. Recommends retry. Returns [17].

2016-01-17 23:15:20.565: [ctss][1168725760]ctssslave_swm:received from Master (mode [0x8c] nodenum [1] hostname [JASO N1])

2016-01-17 23:15:20.565: [Ctss][1168725760]ctsselect_monitor_steysync_mode:failed in Clsctssslave_sync_with_master [Retries]. [0/3].

2016-01-17 23:15:20.565: [ctss][1168725760]ctssslave_swm1_1:waiting for last time sync process to finish. SYNC_STATE[6].

2016-01-17 23:15:20.565: [Ctss][1175029504]ctssslave_msg_handler4_3:slave_sync_with_master finished sync process. Exiting Clsctssslave_msg_handler

2016-01-17 23:15:20.565: [Ctss][1168725760]ctssslave_swm1_2:ready to initiate new time sync process.

2016-01-17 23:15:20.565: [Ctss][1168725760]ctssslave_swm2_1:waiting for TIME sync message from master. SYNC_STATE[2].

2016-01-17 23:15:20.566: [ctss][1175029504]ctsscomm_recv_cb2:receive incoming Message event. Msgtype [2].

2016-01-17 23:15:20.566: [ctss][1175029504]ctssslave_msg_handler4_1:waiting for Slave_sync_with_master to finish sync Process. SYNC_STATE[3].

2016-01-17 23:15:20.566: [ctss][1168725760]ctssslave_swm2_3:received time Sync message from master.

2016-01-17 23:15:20.566: [ctss][1168725760]ctssslave_swm:the magnitude [733548803120 usec] of the offset [73354880312 0 USEC] is larger than [86400000000 usec] sec which is the CTSS limit

.

2016-01-17 23:15:20.566: [Ctss][1168725760]ctsselect_monitor_steysync_mode:failed in Clsctssslave_sync_with_master []: Time offset is too much to be corrected

2016-01-17 23:15:20.566: [Ctss][1175029504]ctssslave_msg_handler4_3:slave_sync_with_master finished sync process. Exiting Clsctssslave_msg_handler

2016-01-17 23:15:21.287: [CTSS][1190360832]CTSS_CHECKCB:CLSDM requested check alive. CHECKCB_DATA{MODE[0XD0], offset[733548803 MS]}, length=[8].

2016-01-17 23:15:21.287: [ctss][1168725760]ctsselect_monitor_steysync_mode:ctss daemon exiting [12].

2016-01-17 23:15:21.287: [Ctss][1168725760]ctss Daemon aborting

2016-01-17 23:15:22.290: [CTSS][1190360832]CTSS_CHECKCB:CLSDM requested check alive. CHECKCB_DATA{MODE[0XD0], offset[733548803 MS]}, length=[8].

View two server times as follows:

jason1:~ # Date

Sat Jan 9 11:37:18 CST 2016

jason2:~ # Date Date

Sun Jan 23:23:12 CST 2016

Two server time difference 8 days,OracleThe time adjustment limit is1days. Time difference 8 days, far more than Oracle the maximum allowable limit for the time synchronization service. so one of the nodes was kicked outCLUSTER, due to a time synchronization problem that caused the node to restart after attempting to join the cluster againin the error. Therefore, adjusting the time of the two servers is the same , it can solve the problem of node down . Close the cluster first, and then align the two node time adjustment current Timestart the cluster again or restart both servers, problem solving.

Reference: http://blog.itpub.net/4227/viewspace-695164/

This article is from "Technical achievement dream!" "Blog, be sure to keep this provenance http://dreamsanqin.blog.51cto.com/845412/1737280

11gR2 RAC time with exception causes node down problem handling