IT中的閏秒問題

雖然閏秒的考驗已經結束了，不少IT人都為這一秒付出了很大的代價。
我也是在週末知道閏秒的說法，自己聽到時也是一知半解，原本以為是個很新鮮的名詞，看著微信朋友圈和微信群裡大家都在熱烈討論，因為都是oracle圈子的，大家討論的更多關注點都在資料庫層面了。
 討論比較多的說法是：
這個問題將影響部分開啟ntp服務的Linux作業系統——會導致Linux核心Crash！Linux kernel是在2.6.18-164.e15之後的版本中解決了這個問題。換句話說，Linux kernel低於2.6.18-164的Linux系統，無論是什麼公司的Linux都將受到影響。閏秒產生後，由於NTP同步時間，則對於10.2.0.4 （不包括）之前的RAC系統, 存在BUG 5015469 和BUG 6022204 可能在一定場景下會導致節點重啟。
參考oracle 官方文件，          Leap seconds (extra second in a year) and impact on the Oracle database. (文件 ID 730795.1)
建議解決辦法：在6月30日停掉所有Linux及Oracle版本在上述影響範圍內的Oracle RAC資料庫伺服器的NTP網路時間同步服務，到7月1日零點以後再重新開啟。該方法對應用系統無影響（只是短時間內不自動校時罷了，伺服器自己的時間精度短時間內足夠應付一般應用）。

自己也潮了一把。也順便看看公司是否也有相應的防範措施，結果一檢視郵件歷史，真是讓人大跌眼鏡。公司早在今年1月份就已經明確發出郵件，而且討論的郵件列表已經很長了。著實讓我感慨了一把。
官方結構的宣佈是在1月5日左右。

To authorities responsible for the measurement and distribution of time                                         


                                   UTC TIME STEP
                            on the 1st of July 2015
                      

 A positive leap second will be introduced at the end of June 2015.
 The sequence of dates of the UTC second markers will be:		
		
                          2015 June 30,     23h 59m 59s
                          2015 June 30,     23h 59m 60s
                          2015 July  1,      0h  0m  0s

所以可以很明顯的看到，時間會多出一秒來。關於閏秒，也簡單說幾句，因為自己確實是文化水平不夠：）。閏秒是指為保持協調世界時接近於世界時時刻，由國際計量局統一規定在年底或年中（也可能在季末）對協調世界時增加或減少1秒的調整。由於地球自轉的不均勻性和長期變慢性（主要由潮汐摩擦引起的），會使世界時（民用時）和原子時之間相差超過到±0.9秒時，就把世界時向前撥1秒（負閏秒，最後一分鐘為59秒）或向後撥1秒（正閏秒，最後一分鐘為61秒）
當然還有一些資料來看看，可能還有點意思。
下面是閏秒實施的一些時間情況，都是正閏秒。看到這我就在想，下一次是什麼時候呢，結果百度了一大圈，沒有任何收穫，最後又認真讀了讀閏秒的百科，才發現閏秒的新增頻率是不固定的，有時一年新增兩次閏秒，有時7年新增一次閏秒，而這一次新增閏秒的時間是4年，如此“漂浮不定”，大體意思應該是說取決於地球的轉速了。這樣來看以後可能還有一些這種補丁要做。

實施年份	6月30日23:59:60	12月31日23:59:60	實施年份	6月30日23:59:60	12月31日23:59:60
1972年	+1秒	+1秒	1989年	——	+1秒
1973年	——	+1秒	1990年	——	+1秒
1974年	——	+1秒	1992年	+1秒	——
1975年	——	+1秒	1993年	+1秒	——
1976年	——	+1秒	1994年	+1秒	——
1977年	——	+1秒	1995年	——	+1秒
1978年	——	+1秒	1997年	+1秒	——
1979年	——	+1秒	1998年	——	+1秒
1981年	+1秒	——	2005年	——	+1秒
1982年	+1秒	——	2008年	——	+1秒
1983年	+1秒	——	2012年	+1秒	——
1985年	+1秒	——	2015年	+1秒	——

大概瞭解了一下閏秒，當然從IT層面來看，是不是隻有2.6.18-164.e15之後的才不會有影響呢。以redhat為例，在不同的版本中，其實還是有一些不同。

Required Kernel Updates 

RHEL 4

RHEL 4 Update 8  - kernel-2.6.9-89.EL

建議升級為RHEL 4 update 9 – kernel-2.6.9-100
RHEL 5.x

5.x: Kernel must be updated to a release >=kernel-2.6.18-164.el5

RHEL 6.x minimum required patch levels:

6.1: kernel-2.6.32-131.30.2

6.2: kernel-2.6.32-220.25.1.el6

6.3: kernel-2.6.32-279.5.2

6.4 and later already contain the patch.

7.x: currently not affected
各大廠商都會或多或少的影響到，在2012年很多網際網路公司就受到很大的影響。
所以這次的閏秒時間應該是格外重視。
redhat官方的討論文章。       
                                 
HP 官方的討論。    

IBM的官方討論     

從資料庫層面，在Oracle RAC 11.1.0.7版本基於AIX和Solaris時，如果使用了叢集，在閏秒問題發生時，很可能會出現莫名其妙的重啟情況，所以還是強烈建議打上對應的補丁。metalink的文章還是很值得推薦的。Leap seconds (extra second in a year) and impact on the Oracle database. (文件 ID 730795.1)
從這一點來看，很多問題和我們都是緊密相關的，處理問題也需要與時俱進，能夠前瞻的預見問題和分析排查，就能在出現的問題的時候更加從容一些。