誤區 #1：在服務(wù)器故障轉移后，正在運行的事務(wù)繼續執行
這當然是錯誤的!
每次故障轉移都伴隨著(zhù)某種形式的恢復。但是如果當正在執行的事務(wù)沒(méi)有Commit時(shí)，由于服務(wù)器或實(shí)例崩潰導致連接斷開(kāi)，SQL Server可沒(méi)有辦法在故障轉移后的服務(wù)器重新建立事務(wù)的上下文并繼續執行事務(wù)-無(wú)論你使用的故障轉移方式是集群，鏡像，日志傳送或是SAN復制。
對于故障轉移集群來(lái)說(shuō)，當故障轉移發(fā)生后，一個(gè)SQL Server實(shí)例在另一個(gè)故障轉移集群的節點(diǎn)啟動(dòng)。所有實(shí)例上的數據庫都要經(jīng)歷Recovery階段-也就是所有沒(méi)有Commit的事務(wù)都要被回滾。
對于數據庫鏡像來(lái)說(shuō)，來(lái)自主體服務(wù)器的日志不斷傳送到鏡像服務(wù)器進(jìn)行Redo操作。當鏡像服務(wù)器被切換作為主體服務(wù)器時(shí)，原鏡像服務(wù)器的事務(wù)日志將會(huì )變?yōu)镽ecovery模式，這使得好像原鏡像服務(wù)器經(jīng)歷了一次崩潰那樣，在這之后所有的連接都會(huì )導向原鏡像服務(wù)器。
對于事務(wù)日志傳送來(lái)說(shuō)，事務(wù)日志被定期備份并傳送到輔助服務(wù)器.當主服務(wù)器崩潰時(shí),DBA按照恢復順序將輔助服務(wù)器恢復后上線(xiàn).但最終步驟都是要執行recovery步驟，也就是將沒(méi)有提交的事務(wù)進(jìn)行回滾。
對于SAN復制來(lái)說(shuō)，本地SAN的I/O被復制到遠程SAN上進(jìn)行重放，當故障轉移發(fā)生后,系統將會(huì )連接到遠端SAN但數據庫仍然需要執行recovery步驟，這和故障轉移集群極其類(lèi)似。
“唯一”使得正在執行的事務(wù)在故障轉移發(fā)生后仍然得以繼續執行的技術(shù)使用帶有實(shí)時(shí)遷移功能的虛擬化技術(shù)，因為這時(shí)連接本身并不知道其連接的對象已經(jīng)變?yōu)榱硪慌_物理服務(wù)器。
但是無(wú)論使用那種技術(shù)，如果”連接”失效，正在執行的事務(wù)將會(huì )丟失，所以處理這類(lèi)問(wèn)題的這部分工作就需要在程序中用代碼實(shí)現某種“重新執行”的功能。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
