建站
咨詢
售后
建站咨詢
新聞中心
微軟子公司GitHub近日就上個月底持續(xù)時間超過8個小時的一連串故障發(fā)表了完整的事后分析報告，詳細說明了數(shù)據(jù)庫基礎架構導致GitHub遭遇故障的確切原因，GitHub數(shù)據(jù)庫出岔子不是第一次了。
創(chuàng)新互聯(lián)服務項目包括波密網(wǎng)站建設、波密網(wǎng)站制作、波密網(wǎng)頁制作以及波密網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，波密網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到波密省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
GitHub工程高級副總裁Keith Ballinger撰寫的這篇報告稱，2月份的故障是“多次服務中斷，導致在四起獨立的事件中服務降級持續(xù)時間共長達8小時14分鐘?！?/p>
簡短的解釋就是：“數(shù)據(jù)庫負載突然出現(xiàn)變化，加上因日常的規(guī)模擴展改進而帶來的意外配置問題，共同導致了我們的mysql1數(shù)據(jù)庫集群出現(xiàn)資源爭奪現(xiàn)象?！彪m然這家代碼存儲庫公司一直在擴大數(shù)據(jù)運維的規(guī)模，但“我們的大部分核心數(shù)據(jù)集”仍駐留在其原始集群中。
第一次故障發(fā)生在2月19日，當時“一個意外的資源密集型查詢開始在我們的mysql1數(shù)據(jù)庫集群上運行。”雖然原計劃是以低得多的頻次在讀取副本池上運行該負載，但“我們不小心將該流量發(fā)送到了集群的主節(jié)點（master），給該主機加大了壓力，超出了剩余容量的服務范圍?！?/p>
這一切使ProxySQL不堪重負，“ProxySQL負責連接池，因而導致無法一致地執(zhí)行查詢。”
兩天后，“計劃中的主數(shù)據(jù)庫升級再次引發(fā)了ProxySQL故障?！?/p>
2月25日的第三次事件再次涉及ProxySQL，當時“活動數(shù)據(jù)庫連接超過了臨界值，從而改變了這個新基礎架構的行為。由于連接在修復后仍保持在臨界值之上，因此系統(tǒng)回退到了降級狀態(tài)?！?/p>
然后在2月27日，GitHub遭到了重大故障，停運了整整4小時23分鐘。這是由于“應用程序邏輯對數(shù)據(jù)庫查詢模式的更改迅速加大了我們mysql1數(shù)據(jù)庫集群的主節(jié)點所面臨的負載。負載猛增的這種情況使集群性能大幅下降，以至于影響了所有相關服務的可用性?！?/p>
Ballinger聲稱，GitHub進行了更改，以便更迅速地檢測和解決問題。“一旦我們查明了系統(tǒng)之間的相互關系，解決這些問題就很簡單?！盙itHub還抽出“更多的精力”，在不影響用戶的情況下，了解大規(guī)模運行的ProxySQL的性能特征及其對其他服務造成的影響。
Ballinger補充說：“就在這些事件發(fā)生幾天后，我們?yōu)槠渲幸粋€比較重要的MySQL表域（“abilities”表）完成了工作量相當大的數(shù)據(jù)分區(qū)任務。這些更改將mysql1集群主節(jié)點上的負載減少了20%，將每秒查詢次數(shù)減少了15%。”
該公司還致力于減少主數(shù)據(jù)庫的讀取操作，并將它們轉(zhuǎn)移至副本數(shù)據(jù)庫，并完成“mysql1集群的在途（in-flight）功能分區(qū)，并確定要分區(qū)的其他域。它還在完善儀表板，并對最大的模式集進行分片（sharding）?！?/p>
如果GitHub沒有在更好地報告故障或引入混亂工程技術方面做得更到位讓你覺得很奇怪，那是由于它早在2018年的時候就已經(jīng)保證會做那些事情。2018年，在短暫的連接中斷導致其數(shù)據(jù)庫集群在美國東西岸地區(qū)不同步后，GitHub遭遇了長達24小時的故障。
而且遭遇故障的并非只有GitHub。運行云平臺很……難。母公司微軟本周發(fā)現(xiàn)其Azure平臺出了問題，而就在撰寫本文時，谷歌在谷歌云平臺（GCP）服務大范圍出問題后正發(fā)布修復程序。
當前文章：Github 8 小時一連串故障的元兇是：數(shù)據(jù)庫基礎架構
文章源于：http://m.fisionsoft.com.cn/article/dhjpsce.html
