資訊專欄INFORMATION COLUMN
最近工作中又遇到因時(shí)間問題導(dǎo)致的故障，這讓本新四有好青年想起了N年前的一個(gè)案例，今天整理分享一下。當(dāng)時(shí)是應(yīng)用反應(yīng)主機(jī)時(shí)間與正確的時(shí)間相差有8分多鐘，影響了正常的業(yè)務(wù)，登錄發(fā)現(xiàn)主機(jī)的NTP服務(wù)是開啟的，查看NTP同步狀態(tài)：
可以看到offset是0.051s,基本沒有延遲，那么問題就出在Ntpserver時(shí)間存在不準(zhǔn)確的可能，通過主機(jī)側(cè)查看，果然server端存在延遲的情況。
為盡快恢復(fù)業(yè)務(wù)，通過以下方式來處理時(shí)間延遲，停止NTP服務(wù)更改服務(wù)端到一個(gè)正常的NTP服務(wù)器，在不停庫(kù)的情況下，手工微調(diào)時(shí)間，來追平發(fā)生的延遲，步驟如下：
1.停止NTP服務(wù)修改服務(wù)器地址
#/etc/init.d/ntpd stop
#vi /etc/ntp.conf
# Enable writing of statisticsrecords.
#statistics clockstats cryptostatsloopstats peerstats
#server 172.72.20.131 prefer minpoll6 maxpoll 6
server 10.19.244.52 prefer minpoll 6maxpoll 6
logfile /var/log/dsware_ntp.log.0
2.每半分鐘調(diào)一次，等半分鐘，再調(diào)一次
date -s "10:41:002017-01-06";clock -w
date -s "10:42:002017-01-06";clock -w
date -s "10:43:002017-01-06";clock -w
date -s "10:44:002017-01-06";clock -w
date -s "10:45:002017-01-06";clock -w
date -s "10:46:002017-01-06";clock -w
date -s "10:47:002017-01-06";clock -w
date -s "10:48:002017-01-06";clock -w
date -s "10:49:002017-01-06";clock -w
date -s "10:50:002017-01-06";clock -w
date -s "10:51:002017-01-06";clock -w
date -s "10:52:002017-01-06";clock -w
date -s "10:53:002017-01-06";clock -w
date -s "10:54:002017-01-06";clock -w
date -s "10:55:002017-01-06";clock -w
date -s "10:56:002017-01-06";clock -w
date -s "10:57:002017-01-06";clock -w
date -s "10:58:002017-01-06";clock -w
3. 啟動(dòng)NTP服務(wù)
#/etc/init.d/ntpd start
以上操作在一個(gè)數(shù)據(jù)庫(kù)主機(jī)上正常執(zhí)行后，數(shù)據(jù)庫(kù)沒有發(fā)生任何異常的情況。
由于某種不便明說原因，在調(diào)整另一臺(tái)數(shù)據(jù)庫(kù)主機(jī)服務(wù)器時(shí)間時(shí)，主機(jī)工程師手動(dòng)調(diào)整server時(shí)間到正確時(shí)間，然后又通過ntpdate調(diào)整數(shù)據(jù)庫(kù)服務(wù)器時(shí)間追平服務(wù)端。結(jié)果是數(shù)據(jù)庫(kù)主機(jī)調(diào)整了8分多鐘的時(shí)間跨度，當(dāng)調(diào)整完成后，悲劇就發(fā)生了，數(shù)據(jù)庫(kù)宕機(jī)，如下：
ALERT報(bào)錯(cuò)：
Fri Jan 06 11:33:30 2017
Errors in file/oracle_log/diag/rdbms/orcl/orcl2/trace/orcl2_asmb_67035.trc:
ORA-15064: communication failurewith ASM instance
ORA-03113: end-of-file oncommunication channel
Process ID:
Session ID: 90 Serial number: 56760
Fri Jan 06 11:33:30 2017
Errors in file/oracle_log/diag/rdbms/orcl/orcl2/trace/orcl2_asmb_67035.trc:
ORA-15064: communication failurewith ASM instance
ORA-03113: end-of-file oncommunication channel
Process ID:
Session ID: 90 Serial number: 56760
USER (ospid: 67035): terminating theinstance due to error 15064
Fri Jan 06 11:33:30 2017
opiodr aborting process unknownospid (22340) as a result of ORA-1092
Fri Jan 06 11:33:30 2017
ORA-1092 : opitsk aborting process
報(bào)錯(cuò)無法與ASM實(shí)例發(fā)生通信，那么接下來我們查看ASM的ALERT日志。
2016-12-27 23:05:53.756000 +08:00
Warning: VKTM detected a time drift.
Time drifts can result in anunexpected behavior such as time-outs. Please check trace file formore details.
2017-01-06 11:33:30.143000 +08:00
WARNING: client[+ASM1:+ASM:c5ogx2-cluster] not responsive for 494s;state=0x1. pid 121601
NOTE: umbilicus traces dumped to/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
WARNING: client[orcl2:orcl:c5ogx2-cluster] not responsive for 494s; state=0x1.killing pid 67039
NOTE: umbilicus traces dumped to/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
WARNING: fencing client[orcl2:orcl:c5ogx2-cluster] after 494 seconds (mbr 1)
WARNING: ASMB has not responded for494 seconds
NOTE: ASM umbilicus running slowerthan expected, ASMB diagnostic requested after 494 seconds
NOTE: ASMB process state dumped totrace file /oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
ERROR: terminating instance becauseASMB is stuck for 494 seconds
System State dumped to trace file/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
2017-01-06 11:33:32.261000 +08:00
報(bào)錯(cuò)，客戶端-cluster在494s內(nèi)無法響應(yīng)，導(dǎo)致ASMB阻塞終止了ASM實(shí)例，順理成章的，DB實(shí)例無法連接ASM實(shí)例，之后宕機(jī)。
查看指定TRACE文件內(nèi)容如下：
*** 2017-01-06 11:33:32.261
GEN0 (ospid: 97907): terminating theinstance due to error 15082
ksuitm: waiting up to [5] secondsbefore killing DIAG(97913)
查看錯(cuò)誤官方解釋：
[/home/oracle] oerr ora 15082
15082, 00000, "ASM failed tocommunicate with client"
// *Cause: There was a failureor time out when ASM tried to communicate with
// aconnected RDBMS or Oracle ASM Dynamic Volume Manager
// (OracleADVM) client.
// *Action: Check the accompanyingerror messages and alert logs
// formore information on the reason for the failure.
// Checksystem specific logs (/var/log/messages on Linux,
// EventLog on Windows) for Oracle ADVM messages.
通過錯(cuò)誤提示，表明是ASM無法與客戶端通信，或超時(shí)，檢查相關(guān)日志，包括網(wǎng)絡(luò)層面，OS層面等日志。
Jan 6 11:21:34 c5ogx2bntpd[18672]: ntpd 4.2.6p5@1.2349-o Fri Oct 11 03:18:05 UTC 2013 (1)
當(dāng)然也就是主機(jī)工程師做的ntpupdate操作。
發(fā)現(xiàn)日志中的超時(shí)494s,換算成分鐘，也就是8.33分鐘，正好是修改的時(shí)間跨度。基本可以確診是大跨度修改主機(jī)時(shí)間導(dǎo)致的宕機(jī)。按照本好青年理解，這里正常的timeout時(shí)間，應(yīng)該是<1秒的時(shí)間，當(dāng)時(shí)由于時(shí)間調(diào)整，兩次獲取操作系統(tǒng)的時(shí)間大于了允許的超時(shí)時(shí)間，導(dǎo)致ASM誤認(rèn)為有問題，為了數(shù)據(jù)一致性等考慮，選擇宕機(jī)保護(hù)。
所以，當(dāng)我們需要調(diào)整數(shù)據(jù)庫(kù)主機(jī)時(shí)間，還是建議微調(diào)，禁止一次跨度太大，以上證明以半分鐘為調(diào)整跨度是比較合理方式之一。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/130191.html
摘要：分析師們預(yù)測(cè)，從年至年，零售主機(jī)托管的增長(zhǎng)率將達(dá)到，批發(fā)數(shù)據(jù)中心市場(chǎng)的增長(zhǎng)率將達(dá)到零售主機(jī)托管服務(wù)目前占有的市場(chǎng)份額，批發(fā)服務(wù)占據(jù)剩余的份額。據(jù)預(yù)測(cè)，這兩個(gè)因素的結(jié)合會(huì)促使亞太區(qū)的主機(jī)托管數(shù)據(jù)中心市場(chǎng)份額到年有望超過北美。 超大規(guī)模云提供商正從傳統(tǒng)數(shù)據(jù)中心提供商那里搶占越來越多的客戶工作負(fù)載，同時(shí)在獲取越來越多的數(shù)據(jù)中心容量，以托管運(yùn)行那些工作負(fù)載，因而大幅改變?nèi)蛑鳈C(jī)托管數(shù)據(jù)中心市場(chǎng)的格局...
摘要：在年，數(shù)據(jù)中心以及公共云和私有云將會(huì)有什么樣的變化以下是我們的一些猜測(cè)。下面是我對(duì)數(shù)據(jù)中心和云的個(gè)預(yù)測(cè)。然而，這意味著數(shù)據(jù)中心也正在被重新調(diào)整其用途。數(shù)據(jù)中心正在發(fā)生變化，變得更加通用和強(qiáng)大。在2019年，數(shù)據(jù)中心以及公共云和私有云將會(huì)有什么樣的變化？以下是我們的一些猜測(cè)。又到了一年中做度假計(jì)劃的時(shí)候了，去購(gòu)物中心看起來就像是《勇敢的心》當(dāng)中的場(chǎng)景，在門口臺(tái)階上偷錢包的行為猖獗，而人們則努力...
摘要：相反，它曾無人看好困難重重，整個(gè)團(tuán)隊(duì)甚至數(shù)度瀕臨解散。從危在旦夕到浴火重生，這十年經(jīng)歷了什么今天，我們一起了解它背后不為人知的故事。在陽(yáng)振坤看來，如果一件事情幾乎所有的人都認(rèn)為它很重要需要做，這件事情就已經(jīng)不是創(chuàng)新了。 showImg(https://segmentfault.com/img/remote/1460000019001650); 阿里妹導(dǎo)讀：談及國(guó)產(chǎn)自研數(shù)據(jù)庫(kù)，就不得不...
摘要：類是一個(gè)抽象類，由安排為一次執(zhí)行或重復(fù)執(zhí)行的任務(wù)。也是自帶的一個(gè)基于線程池設(shè)計(jì)的定時(shí)任務(wù)類。問題，則可以直接使用類實(shí)現(xiàn)自定義的定時(shí)調(diào)度規(guī)則。 定時(shí)調(diào)度作為后端開發(fā)人員，我們總會(huì)遇到這樣的業(yè)務(wù)場(chǎng)景：每周同步一批數(shù)據(jù)；每半個(gè)小時(shí)檢查一遍服務(wù)器運(yùn)行狀況；每天早上八點(diǎn)給用戶發(fā)送一份包含今日待辦事項(xiàng)的郵件，等等。 這些場(chǎng)景中都離不開定時(shí)器，就像一個(gè)定好時(shí)間規(guī)則的鬧鐘，它會(huì)在指定時(shí)間觸發(fā)，執(zhí)行我們...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2748·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
