问题描述:
1. 数据库实例突然crash,原因是ASMB有200多秒没有响应:
Mon Sep 04 15:07:47 2017 WARNING: ASMB has not responded for 200 seconds <<<<<<<<<<<
2. 从system state dump上看,ASMB看起来没有什么问题:
Current Wait Stack: Not in wait; last wait ended 3.321392 sec ago <<<<<<<<<<<<<<
3. 但是从OSW上看,没有发现明显的资源匮乏情况,但是中间却缺了三分多钟的断档:
zzz ***Mon Sep 4 15:04:13 CST 2017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 0 529160192 19412 31514216 0 0 82 48 0 0 1 0 99 0 0 0 0 0 529124032 19412 31514784 0 0 1545 23119 36620 37705 1 1 99 0 0 2 0 0 529126784 19412 31514712 0 0 1601 9056 28083 30263 1 0 99 0 0 zzz ***Mon Sep 4 15:04:23 CST 2017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 529095360 19412 31514996 0 0 82 48 0 0 1 0 99 0 0 3 0 0 529118368 19412 31515228 0 0 1517 4540 20402 27856 1 1 98 0 0 52 0 0 529107936 19412 31515400 0 0 1206 3961 21105 31254 1 0 98 0 0 zzz ***Mon Sep 4 15:07:51 CST 2017 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
看到这里,一般的思考是OSW中间断档了3分多钟,是不是系统性能太差导致OSW没法生成?但是一般来讲,在断档之前一般都能看到一些先兆,比如block queue 剧增。但是这个案例里面没有此现象。 继续看OS log:
4. 在OSlog中看到关键性的一句话:
Sep 4 15:04:01 hnpb05nc crond: /usr/sbin/postdrop: /lib64/libssl.so.10: no version information available (required by /usr/lib64/mysql/libmysqlclient.so.18) Sep 4 15:04:21 hnpb05nc init.tfa: Checking/Starting TFA.. Sep 4 15:07:47 hnpb05nc systemd: Time has been changed <<<<<<<<<<<<<<<<<<
5. 继续看看CTSSD 的trace:
2017-09-04 15:04:25.799241 : CTSS:3933169408: ctssslave_swm19: The offset is [2311562070 usec] and sync interval set to [4]<<
2017-09-04 15:04:26.800845 : CTSS:3933169408: ctssslave_swm19: The offset is [2311562609 usec] and sync interval set to [4]<<
2017-09-04 15:04:27.802328 : CTSS:3933169408: ctssslave_swm19: The offset is [2311563057 usec] and sync interval set to [4]<<
2017-09-04 15:07:47.065051 : CTSS:3933169408: ctssslave_swm19: The offset is [2509824742 usec] and sync interval set to [4]<<
很明显,偏移量在问题期间发生了200秒左右的增长,而在之前,我们可以看到偏移量是相对稳定的!这个也间接说明了系统时间的调整。
这个故事:
事情是这样的,系统配置了ntp,由于一些问题ntp没有启动,但是由于已经配置了ntp,ctssd发现了ntp的配置文件所以ctssd只运行在观察者的角色。造成的结果就是系统时间不断出现偏差,直到系统管理员发现了这个问题并手工把系统时间往前调了200秒。。。 然后ASMB通过系统时间判断有200秒没有响应(当然情况不是这样了),然后就。。。
建议:
当然我们应该尽可能monitor系统并确保NTP的正常运行。如果我们确实需要手工大幅度调整系统时间,那么我们也应该先把RAC数据库关闭以后在做调整。