前言
一次原以來很簡單的pika升級（關掉slave，替換可執行文件，重啟，然后主從切換，完成升級），兩三個小時搞定，前后竟然折騰了一周，有必要總結下。
pika升級遇到問題
- pika運行環境帶來的問題
線上環境pika使用的操作系統是centos6，gcc版本是4.4.7，而pika編譯安裝的環境要求gcc不能低于4.8，與運維同事溝通后，得知在centos6上升級gcc到新版本很麻煩，而且會有坑，建議直接在centos7上部署完整的環境。就選定用centos7部署新的版本pika，加入slave，切換master方式升級。
這個過程又遇到兩個問題:
(1). 以為pika的安裝運行環境的依賴庫只需要在編譯環境安裝即可，后發現運行環境也必須按照相應的要求安裝。
(2). 在一臺機器編譯并能夠運行成功，但拷貝到其他機器上就報illegal instruction，定位為指令集不兼容的問題，使用的云環境不想再具體定位為啥指令集不兼容（同樣的操作系統），就將代碼拉到運行環境編譯運行，然后拷貝到其他機器解決。 - 舊版本pika 卡死
開始升級pika時，遇到舊版本pika卡死的請求，后來和360的pika開發小伙伴溝通后，被告知這是pika 2.1版本的一個bug，在新版本pika 2.2.3已經fix，也正是這個bug，促使了我們在后面遇到問題時，也要嘗試解決問題進行升級。一個數據庫運行著卡死，這雷真心受不了。。還好卡死不是畢現的，遇到了一次 - pika同步不成功
在進行pika主從數據同步時，運維同事發現一直在進行全量數據同步，后來分析了下是由于binlog保留的太少了，導致在pika寫數據量多時，全量同步完無法進行增量同步，重復全量同步，后來看了下相關實現及與pika開發小伙伴交流，通過在線 config set expire-logs-nums 500解決，這個設置這么大耗費硬盤還是比較多的，應該設置200左右就可以了～ - pika的主從互換后無法建立主從關系
這個問題分析了下是由于斷開舊的主從關系時，舊的master上一些數據（binlog）還沒有同步到舊slave上，而舊slave切換為新master后，舊的master作為新master的slave進行同步，會因為binlog的offset問題無法正常建立主從關系，INFO查看同步狀態碼為5，即錯誤狀態。另一個導致不能進行主從同步的問題，有時在進行主從同步時，報某個binlog不存在，解決辦法就是把那個binlog touch出來～～。在交流群里大家討論了下，目前pika在Gracefully shutdown時，還是不夠足夠的graceful，應該是先將停寫，然后將數據同步完，再shutdown比較合適。這個主從同步問題目前的解決辦法是可以來一次全同步。。 - 新版本pika做為master掛掉
進行新舊版本切換時發現，把新版本的pika切為master，過幾分鐘后，新版本的master會掛掉，相關log看不出問題所在，后與360 pika的小伙伴溝通后，他們判斷為那個pika進程的文件句柄被寫滿了，導致掛掉，后來查看了下pika進程的文件描述符限制遠小于系統設定的。后定位到原因是由于啟動pika的monit進程的最大文件描述符的限制是4095，導致pika最大文件描述符的限制是4095，導致too many open files而掛掉pika。
總結
pika在線上穩定運行快10個月了，這個過程沒有出現明顯的異常，還是很贊的。根據pika實現（將數據存在磁盤中，還有主從）及這么長時間的穩定運行，覺得這次升級還是比較容易，風險不大的，但還是發現了上面的這些問題。這次是在一個資深運維協助下進行的升級，不然估計還會有不少其他的問題。。
這次升級持續這么長時間，我在想這中間是有哪些是可以在升級前做的更多的嗎，第一個問題中的編譯運行環境可以提前測試確定出來，第三個問題在單機環境測試出來，不知道電腦能不能扛的住。。第四個問題如果測試覆蓋夠也可以發現這個問題（雖然這個問題發現了，也沒太好的解決，只是避免了不必要的問題查看定位），其他的依然比較難發現出來。
對一個長時間沒有進行升級的組件進行升級需要慎重，應對方案要考慮全，尤其是基礎組件，應對失敗，回退方案及可行步驟一定要提前準備好，僥幸要不得。
最終升級成功，祝大家玩的愉快～
