高效能MySQL.讀書筆記(六)高可用性
什麼是高可用性
每個應用對可用性的需求各不相同。在設定一個可用時間的目標之前,先問問自己,是不是確實需要達到這個目標。可用性每提高一點,所花費的成本都會遠超之前;可用性的效果和開銷的比例並不是線性的。需要保證多少可用時間,取決於能夠承擔多少成本。高可用性實際上是在宕機造成的損失與降低宕機時間所花費的成本之間取一個平衡。換句話說,如果需要花大量金錢去獲得更好的可用時間,但所帶來的收益卻很低,可能就不值得去做。總的來說,應用在超過一定的點以後追求更高的可用性是非常困難的,成本也會很高,因此我們建議設定一個更現實的目標並且避免過度設計。幸運的是,建立2個9或3個9的可用時間的目標可能並不困難,具體情況取決於應用。
有時人們將可用性定義成伺服器正在執行的時間段。我們認為可用性的定義還應該包括應用是否能以足夠好的效能處理請求。有許多方法可以讓一個伺服器保持執行,但服務並不是真正可用。對一個很大伺服器而言,重啟MySQL之後,可能需要幾個小時才能充分預熱以保證查詢請求的響應時間是可以接受的,即使伺服器只接收了正常流量的一小部分也是如此。
如果伺服器遭遇災難性故障,可能多少都會丟失一此資料,例如最近已經寫入二進位制日誌但尚未傳遞到備庫中的中繼日誌中的事務。你能夠容忍嗎?大多數應用能夠容忍;因為替代方案大多非常昂貴且複雜,或者有一些效能開銷。例如,可以使用同步複製,或是將二進位制日誌放到一個通過DRBD進行復制的裝置上,這樣就算伺服器完全失效也不用擔心丟失資料。(但整個資料中心也有可能會掉電。)
一個良好的應用架構通常可以降低可用性方面的需求,至少對部分系統而言是這樣的,良好的架構也更容易做到高可用。將應用中重要和不重要的部分進行分離可以節約不少工作量和金錢,因為對於一個更小的系統改進可用性會更容易。
如何實現高可用
提升平均失效時間(MTBF)
在分類整理宕機事件並追查導致宕機的根源時,我們發現,很多宕機本來是有一些方法可以避免的。我們發現大部分宕機事件都可以通過全面的常識性系統管理辦法來避免。
l 測試恢復工具和流程,包括從備份中恢復資料。
l 遵循最小許可權原則。
l 謹慎安排升級資料庫伺服器。
l 在升級前,使用諸如Percona Toolkit中的pt_uptrade之類的工具仔細檢查系統
l 除非能證明有效,否則禁用查詢快取。
l 避免使用複雜的特性,例如複製過濾和觸發器,除非確實需要。
l 定期檢查複製完整性。
l 歸檔並清理不需要的資料。
l 養成習慣,評估和管理系統的改變、狀態以及效能資訊。
降低平均恢復時間(MTTR)
可以通過減少恢復時間來獲得高可用性。事實上,一些人走得更遠,只專注於減少恢復時間的某個方面:通過在系統中建立冗餘來避免系統完全失效,並避免單點失效問題。
在降低恢復時間上進行投資是非常重要的,一個能提供冗餘和故障轉移能力的系統架構,則是降低恢復時間的關鍵環節。但實現高可用性不單單是一個技術問題,還有許多個人和組織的因素。組織和個人在避免宕機和從宕機事件中恢復的成熟度和能力層次各不相同。
團隊成員是最重要的高可用性資產,所以為恢復制定一個好的流程非常重要。擁有熟練技能、應變能力、訓練有素的員工,以及處理緊急事件的詳細文件和經過仔細測試的流程,對從宕機中恢復有巨大的作用。但也不能完全依賴工具和系統,因為它們並不能理解實際情況的細微差別,有時候它們的行為在一般情況下是正確的,但在某些場景下去是個災難。
避免單點失效
找到並消除的可能失效的單點,並結合切換到備用元件的機制,這是一種通過減少恢復時間(MTTR)來改善可用性的方法。如果你夠聰明,有時候甚至能將實際的恢復時間降低至0,但總的來說這很困難。(即使一些非常引人注目的技術,例如昂貴的負載均衡器,在發現問題並進行反饋時也會導致一定的延遲。)
共享儲存或磁碟複製
共享儲存通常使用的是SAN。如果主伺服器掛了,備用伺服器可以掛載相同的檔案系統,執行需要的恢復操作,並在失效伺服器上的資料上啟動MySQL。這個過程會更快,因為備用伺服器已經啟動,MySQL隨時可以執行。當開始做故障轉移時,檢查檔案系統、恢復InnoDB以及預熱(Percona Server提供了一個新特性,能夠把buffer pool儲存下來並在重啟後還原,在使用共享儲存時能夠很好地工作。MySQL5.6也有相似的特性)是最有可能遇到延遲的地方,但檢測失效本身在許多設定中也會花費很長時間。
共享儲存可以避免除儲存外的其他任何元件失效所引起的資料丟失,併為非儲存元件建立冗餘提供可能。不過,共享儲存本身仍是可能失效的單點。如果MySQL崩潰等故障導致資料檔案損壞,可能會導致備用伺服器也無法恢復。
主動-主動訪問模式的共享儲存怎麼樣?
在一個SAN、NAS或者叢集檔案系統上以主動-主動模式執行多個例項怎麼樣?MySQL不能這麼做。因為MySQL並沒有被設計成和其他MySQL例項同步對資料的訪問,所以無法在同一份資料上開啟多個MySQL例項。
MySQL中最普遍使用的磁碟複製技術是DRBD,並結合Linux-HA專案中的工具使用。
由於在備用DRBD裝置上的寫入必須要在主裝置上的寫入完成之前,因此備用裝置的效能至少要和主裝置一樣,否則就會限制主裝置的寫入效能。帶電池寫快取的RAID控制器對DRBD而言幾乎是必需的,因為在沒有這樣的控制器時效能可能會很差。
DRBD和SAN很相似,DRBD是獲得一份複製的資料,而SAN則是使用同一份資料副本,所以DRBD沒有單點問題,但這兩種情況下,當啟動備用機器時,MySQL伺服器的快取都是空的。
DRBD有一些很好的特性和功能,但也有缺點:
l DRBD故障轉移無法做到秒以內。它通常至少需要幾秒時間來將備用裝置提升成主裝置,這還不包括任何必須的檔案系統恢復和MySQL恢復。
l 它很昂貴,因為必須在主動-被動模式下執行。熱備伺服器的複製裝置因為處於被動模式,無法用於其他任務。連MySQL服務都是停用的。
l 對MyISAM表用處不大,因為MyISAM表崩潰後需要花費很長時間來檢查和修復。
l DRBD無法代替備份。如果磁碟由於蓄意的破壞、誤操作、BUG或者其他硬體故障導致資料損壞,DRBD將無濟於事。此時複製的資料只是被損壞資料的完美副本。你需要使用備份(或MySQL延時複製)來避免這些問題。
l 對寫操作而言增加了負擔。網路往返開銷增加了寫入延遲。使用DRBD導致伺服器變慢最常見的原因是MySQL使用InnoDB並採取了完全持久化模式(innodb_flush_log_at_trx_commit=1),這會導致許多小的寫入和fsync()呼叫,通過DRBD同步時會非常慢。
MySQL同步複製
當使用同步複製時,主庫上的事務只有在至少一個備庫上提交後才能認為其執行完成。
MySQL本身並不支援同步提製(MySQL5.5只支援半同步複製。)
這裡可以在應用中加一個模擬方式,應用的業務在主庫上提交後,馬上連線到備庫,呼叫函式MASTER_POS_WAIT檢查備庫是否同主庫同步,但是這樣會極大增加主庫上業務提交返回的延遲。
基於複製的冗餘
複製管理器是使用標準MySQL複製來建立冗餘的工具。儘管可以通過複製來改善可用性,但也有一些“玻璃天花板”會阻止MySQL當前版本的非同步複製和半同步複製獲得和真正的同步複製相同的結果。複製無法保證實時的故障轉移和資料零丟失,也無法將所有節點等同對待。
複製管理器通常監控管理三件事:應用和MySQL間的通訊、MySQL伺服器的健康度,以及MySQL伺服器間的複製關係。它們即可以修改負載均衡的配置,也可以在必要的時候轉移虛擬IP地址以使應用連線到合適的伺服器上。大體上操作並不複雜:只需要確定寫入不會發送到一個還沒有準備好提供寫服務的伺服器上,並保證當需要提升一臺備庫為主庫時記錄下正確的複製座標。
這聽起來在理論上是可行的,但實際經驗表明實際上並不總是能有效工作。事實上還很糟糕,有些時候最好有一些輕量級的工具集來幫助從覺的故障中恢復並以很低的開銷獲得較高的可用性。但很遺憾,到現在為止還沒有一個好的工具集可以可靠地完成這一點。
最好不要嘗試自己寫複製管理器。非同步元件有大量的故障形式,很多你從未親身經歷過,其中一些甚至無法理解,並且程式也無法適當處理,因此從這些非同步元件中得到正確的行為相當困難,並且可能遭遇資料丟失的危險。事實上,機器剛開始出現問題時,由一個經驗豐富的人來解決是很快的,但如果其他人做了一些錯誤的修復操作則可能導致問題更嚴重。
第一個複製管理器是MMM(http://mysql-mmm.org),但該工具集是否適用於生產環境部署的意見並不一致(儘管該工具的原作者也承認它並不可靠)。我們的許多客戶在自動故障轉移模式下使用該工具時確實遇到了許多嚴重的問題。它會導致健康的伺服器離線,也可能將寫入傳送到錯誤的地點,並將備庫移動到錯誤的座標。
另一個是比較新的工具是MHA工具集(http://code.google.com/p/mysql-master-ha/),MHA是很好的測試集,可以防止一些MMM遇到的問題,但是我們對該工具集還沒有更多的認識。
基於複製的冗餘最終來說好壞參半。只有在可用性的重要性遠比一致性或資料零丟失保證更重要時才推薦使用。例如,一些人並不會真正的從他們的網站功能中獲得,而是從它的可用性中賺錢。誰會在乎是否出現了故障導致一張照片丟失了幾條評論或其他什麼東西呢?只要廣告收益繼續滾滾而來,可能並不值得花更多成本去實現真正的高可用性。但是還是可以通過複製來建立“儘可能的”高可用性。,當遇到一些很難處理的嚴重宕機時可能會有所幫助。這是一個大賭注,並且可能對大多數人而言太過於冒險,除非是那些老成的使用者。
問題是許多使用者不知道如何去證明自己有資格並評估複製“輪盤賭”是否適合他們。這有兩個方面的原因。第一,他們並沒有看到“玻璃天花板”,錯誤地認為一組虛擬IP地址、複製以及管理指令碼能夠實現真正的高可用性。第二,他們低估了技術的複雜度,因此也低估了嚴重故障發生後從中恢復的難度。一些人認為他們能夠使用基於複製的冗餘技術,但隨後他們可能會更希望選擇一個有更強保障的簡單系統。
請不要認為我們將這些技術說得無所不能而把MySQL自身的複製貶得一團糟,那不是我們的本意。你可以為DRBD寫出低質量的故障轉移指令碼,這很簡單,就像為MySQL複製編寫指令碼一樣。主要的區別是MySQL複製非常複雜,有很非常細小的差別,並且不會阻止你幹壞事。
故障轉移和故障恢復
提升備庫或切換角色
虛擬IP地址或IP接管
中介軟體解決方案
可以使用代理、埠轉發、網路地址轉換(NAT)或者硬體負載均衡來實現故障轉移和故障恢復。這些都是很好的解決方案,不像其它方法可能會引入一些不確定性(所有系統元件認同哪一個是主庫嗎?它能夠及時並原子地更改嗎?),它們是控制應用和伺服器間連線的中樞。但是,它們自身也引入了單點失效,需要準備冗餘來避免這個問題。
使用這樣的解決方案,你可以將一個遠端資料中心設定成看起來好像和應用在同一個網路裡。這樣就可以使用諸如浮動IP地址技術讓應用和一個完全不同的資料中心開始通訊。你可以配置每個資料中心的每臺應用伺服器,通過它自己的中介軟體連線,將流量路由到活躍資料中心的機器上。如果活躍資料中心的MySQL崩潰了,中介軟體可以路由流量到另外一個數據中心的伺服器池中,應用無須知道這個變化。
MySQL代理,我推薦國內淘寶的Cobar,文件齊全,挺好用的。
在應用中處理故障轉移
有時候讓應用來處理故障轉移會更簡單或者更加靈活。例如,如果應用遇到一個錯誤,這個錯誤外部觀察者正常情況下是無法察覺的,例如關於資料庫損壞的錯誤日誌資訊,那麼應用可以自己來處理故障轉移過程。
雖然把故障轉移處理過程整合到應用中看起來比較吸引人,但可能沒有想象中那麼有效。大多數應用有許多元件,例如cron任務、配置檔案,以及用不同語言編寫的指令碼。將故障轉移整合到應用中可能導致應用變得太過笨拙,尤其是當應用增大並變得更加複雜時。
但是將監控構建到應用中是一個好主意,當需要時,能夠立刻開始故障轉移過程。應用應該也能夠管理使用者體驗,例如提供降級功能,並顯示給使用者合適的資訊。
總結
增加執行時間,就要嘗試去防止故障發生。悲劇的是,在預防故障發生時,它仍然會覺得你做的不夠多,所以預防故障的努力經常會被忽視掉。
縮短恢復時間可能更復雜並且代價很高。從簡單和容易的方面來說,可以通過監控來更快地發現問題,並記錄大量的度量值以幫助診斷問題。
相關推薦
高效能MySQL.讀書筆記(六)高可用性
什麼是高可用性 每個應用對可用性的需求各不相同。在設定一個可用時間的目標之前,先問問自己,是不是確實需要達到這個目標。可用性每提高一點,所花費的成本都會遠超之前;可用性的效果和開銷的比例並不是線性的。需要保證多少可用時間,取決於能夠承擔多少成本。高可用性實際上是在宕機造成的
高效能mysql讀書筆記(一)
1 mysql的架構與歷史: 1.1 mysql邏輯架構 mysql將查詢等處理與資料儲存相分離的,可以更加靈活的選取資料儲存的方式。mysql處理架構:連線處理->解析器->查詢快取->優化器->儲存引擎。 第一層:連線處理:包括主要的授權登入、安
高效能MySQL.讀書筆記(一)優化伺服器設定
MySQL有大量可以修改的引數——但不應該隨便去修改。通常只需要把基本的配置項配置正確(大部分情況下只有很少一些引數是真正重要的),應該將更多的時間花在schema的優化、索引,以及查詢設計上。 確保基本的配置是正確的,如果碰到了問題,並且問題是由於伺服器的某部分導致的,而這恰好可以通過某個配置項解決,那麼需
高效能mysql讀書筆記(四)
四,建立高效能的索引 索引也稱為鍵,索引是一種查詢資料有用的資料結構,索引優化是查詢優化中最優效的手段。 索引可以包含一列或者多列,mysql能夠高效的使用索引中的最左字首列,索引在儲存引擎層實現,不同的儲存引擎有不同的索引。B-tree索引作為大多數資料庫的索引資料結構,
高效能MySQL.讀書筆記(二)作業系統和硬體優化
使用Flashcache 雖然有很多因素需要在快閃記憶體、硬碟和RAM之間權衡,在儲存層次結構中,這些裝置沒有被當作一個整體處理。有時可以使用磁碟和記憶體技術的結合,這就是Flashcache。 Flashcache是一個Linux核心模組,使用Linux的裝置對映器(Device Mapper)。它在記憶體
MySQL學習筆記(六)—— MySQL自連接
概念 cor 子查詢 ron 表操作 例子 質量 _id order by 有的時候我們需要對同一表中的數據進行多次檢索,這個時候我們可以使用之前學習過的子查詢,先查詢出需要的數據,再進行一次檢索。 例如:一張products表,有產品id,供應商id(vend_
《可愛的Python》讀書筆記(六)
mkdir沒有完美的軟件,夠用並且容易使用的軟件已經算是完美的了。今天整理這幾天的代碼# -*- coding: utf-8 -*- import os import sys import cmd from cdctools import * class PyCDC(cmd.Cmd): def
軟件工程讀書筆記(六)——結對編程那些事
() 對數 tab 一起 什麽 關系 基本原則 got 得到 現代軟件產業經過幾十年的發展,已經形成了項目組合作的形式,幾乎不存在一個人完成所有工作的情況,一個團隊最少有兩個人組成,那麽兩人合作的過程中有什麽需要關註的地方呢? 一、
《Python網絡數據采集》讀書筆記(六)
CSV1、urllib.request.urlretrieve可以根據文件的URL下載文件:# -*- coding: utf-8 -*- from urllib.request import urlretrieve from urllib.request import urlopen from bs4 im
Mysql(六)---高可用
高可用 “高可用性”(High Availability)通常來描述一個系統經過專門的設計,從而減少停工時間,而保持其服務的高度可用性。 之前我們提到,主從複製,從叢集反向代理負載均衡,那麼從叢集在一定程度上實現了高可用,那麼至今為止我們的主節點(寫節點),還只是一
Java程式效能優化 讀書筆記(六)設計模式:觀察者模式
一、觀察者模式 觀察者模式定義了物件間的一種一對多依賴關係,使得每當一個物件改變狀態,則所有依賴於它的物件都會得到通知並被自動更新。它將觀察者和被觀察者的物件分離開。提高了應用程式的可維護性和重用性。觀察者模式又稱為釋出/訂閱(Publish/Subscribe)模式。 觀
《強化學習Sutton》讀書筆記(六)——n步Bootstrapping(n-step Bootstrapping)
此為《強化學習》第七章 n-step Bootstrapping 。 n n n步Bootstrapping是MC和TD(0)的綜合。隨著對引數 n
高效能 JavaScript 讀書筆記(四)
迴圈 1.減少迭代的工作量 2.倒序迴圈 條件語句 if-else && switch 大多數情況下,switch 比 if-else 執行的快。但只有條件數量很大的時候才明顯。 優化 if-else 1.把最可能出現的條件放在最前面。 2.巢
《實時碰撞檢測演算法技術》讀書筆記(六):最近點計算(下)
點至3D矩形的最近點 實際上等同於計算OBB上的最近點,其中3D矩形可看做是z向為0的OBB。 struct Rect { Point c; Vector u[2]; float e[2]; } 令z軸為0並重寫函式ClosestPtPointO
高效能 JavaScript 讀書筆記(五)
字串和正則表示式 字串連線 連線字串有很多方式,常見的有: 1.str = "a" + "b" + "c"; 2.str = "a"; str += "b"; str += "c"; 3.str = ["a","b","c"].join(""); 4.str = "
高效能 JavaScript 讀書筆記(三)
重繪與重排 概念 重排:當元素的寬和高發生改變的時候,就會重新排列元素,稱為重拍。 重繪:將重排的的元素重新繪製在瀏覽器中,稱為重繪。 在元素中新增段落、新增邊框、新增或者刪除元素、修改內外邊距等,一切改變現有元素的位置的操作都會導致重排的發生。相應的,新增背景色這一類沒有改變元素位
高效能 JavaScript 讀書筆記 (二)
資料存取 字面量、本地變數、陣列元素、物件成員 字面量只代表自身,不儲存在特定的位置。JavaScript 中的字面量有:字串、數字、布林值、物件、陣列、函式、正則表示式以及特殊的 null 和 undefined 值。 一般來說,訪問本地變數和字面量的事件較少,訪問陣列元素和物件成員花
java面試寶典讀書筆記(六)-作業系統
1、多使用者:容許同一時間有很多人使用同一部機器,多工:為了使很多程式可以一同執行,這個特點叫做多工。多工又分協同式和搶佔式。 2、只有具備執行許可權才允許使用者進入一個檔案的系統的目錄。 3、所有的
讀書筆記(六)--成交
讀書筆記--第6篇--《成交》 1.在IT企業,陌生人很容易一眼就能分辨出誰做銷售,誰做技術,誰做管理。 衝著陌生人微笑言語客氣的一般是銷售,一臉漠然甚至有些高傲的是技術,用探尋的眼光
AI聖經-深度學習-讀書筆記(六)-深度前饋網路
深度前饋網路(DFN) 0 簡介 (1)DFN:深度前饋網路,或前饋神經網路(FFN),或多層感知機(MLP) (2)目標 近似某個函式 f∗f∗。例如,定義一個對映y=f(x;θ)y=f(x;θ),並且學習θθ的值,使它能夠得到最佳的函式近似。