MySQL 主從同步,事務回滾的實現原理

2022-09-24 14:12:16 字數 2916 閱讀 3602

binlog是記錄所有資料庫表結構變更(例如create、alter table)以及表數icuwktzf據修改(insert、update、delete)的二進位制日誌,主從資料庫同步用到的都是binlog檔案。binlog日誌檔案有三種模式。

內容:binlog 只會記錄引起資料變更的 sql 語句

優勢:該模式下,因為沒有記錄實際的資料,所以日誌量和 io 都消耗很低,效能是最優的

劣勢:但有些操作並不是確定的,比如 uuid() 函式會隨機產生唯一標識,當依賴 binlog 回放時,該操作生成的資料與原資料必然是不同的,此時可能造成無法預料的後果。

內容:在該模式下,binlog 會記錄每次操作的源資料與修改後的目標資料,streamsets就要求該模式。

優勢:可以絕對精準的還原,從而保證了資料的安全與可靠,並且複製和資料恢復過程可以是併發進行的

劣勢:缺點在於 binlog 體積會非常大,同時,對於修改記錄多、字段長度大的操作來說,記錄時效能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取資料。

內容:是對上述statement 跟 row 兩種模式的混合使用。

細節:對於絕大部分操作,都使用 statement 來進行 binlog 的記錄,只有以下操作使用 row 來實現:表的儲存引擎為 ndb,使用了uuid() 等不確定函式,使用了 insert delay 語句,使用了臨時表

1、主節點必須啟用二進位制日誌,記錄任何修改了資料庫資料的事件。

2、從節點開啟乙個執行緒(i/o thread)把自己扮演成 mysql 的客戶端,通過 mysql 協議,請求主節點的二進位制日誌檔案中的事件 。

3、主節點啟動乙個執行緒(dump thread),檢查自己二進位制日誌中的事件,跟對方請求的位置對比,如果不帶請求位置引數,則主節點就會從第乙個日誌檔案中的第乙個事件乙個乙個傳送給從節點。

4、從節點接收到主節點傳送過來的資料把它放置到中繼日誌(relay log)檔案中。並記錄該次請求到主節點的具體哪乙個二進位制日誌檔案內部的哪乙個位置(主節點中的二進位制檔案會有多個)。

5、從節點啟動另外乙個執行緒(sql thread ),把 relay log 中的事件讀取出來,並在本地再執行一次。

mysql預設的複製方式是非同步的,並且複製的時候是有並行複製能力的。主庫把日誌傳送www.cppcns.com給從庫後不管了,這樣會產生乙個問題就是假設主庫掛了,從庫處理失敗了,這時候從庫公升為主庫後,日誌就丟失了。由此產生兩個概念。

主庫寫入binlog後強制同步日誌到從庫,所有的從庫都執行完成後才返回給客戶端,但是很顯然這個方式的話效能會受到嚴重影響。

半同步複製的邏輯是這樣,從庫寫入日誌成功後返回ack確認給主庫,主庫收到至少乙個從庫的確認就認為寫操作完成。

在mysql中如果每一次的更新操作都需要寫進磁碟,然後磁碟也要找到對應的那條記錄,然後再更新,整個過程io成本、查詢成本都很高。先寫日誌,再寫磁碟binlog,redolog。

1、 記錄更新時,innodb引擎就會先把記錄寫到redolog(裡面,並更新記憶體。同時,innodb引擎會在空閒時將這個操作記錄更新到磁碟裡面。

2、 如果更新太多redolog處理不了的時候,需先將redolog部分資料寫到磁碟,然後擦除redolog部分資料。

redolog有write pos 跟checkpoint

write pos :是當前記錄的位置,一邊寫一邊後移,寫到第3號檔案末尾後就回到0號檔案開頭。

checwww.cppcns.comk point:縮短資料庫的恢復時間,buffer poo程式設計客棧l空間不夠用時,將髒頁重新整理到磁碟,redolog不可用時,重新整理髒頁

redo log順序寫實際上是迴圈寫固定幾個檔案,寫滿一輪就要從頭開始覆蓋。它包括兩個位點,check point和write pos,write pos是寫到那個位置了,迴圈往後遞增,check point是當前要擦除的位置。二者中間的空間是可寫入的,當write pos追上check point時,就會先停下更新,覆蓋掉一些記錄,然後繼續寫入redo log。

mysql支援使用者自定義在commit時如何將log buffer中的日誌刷log file中。這種控制通過變數 innodb_flush_log_at_trx_commit 的值來決定。該變數有3種值:0、1、2,預設為1。但注意,這個變數只是控制commit動作是否重新整理log buffer到磁碟。

在主從複製結構中,要保證事務的永續性和一致性,需要對日誌相關變數設定為如下:

上述兩項變數的設定保證了:每次提交事務都寫入二進位制日誌和事務日誌,並在提交時將它們重新整理到磁碟中。

有了redo log,innodb就可以保證即使資料庫發生異常重啟,之前提交的記錄都不會丟失,這個能力稱為crash-safe。redolog兩階段提交`:為了讓binlog跟redolog兩份日誌之間的邏輯一致。提交流程大致如下:

1 prepare階段 --> 2 寫binlog --> 3 commit

1.當在2之前崩潰時,重啟恢復後發現沒有commit,回滾。備份恢復:沒有binlog 。一致

2.當在3之前崩潰時,重啟恢**現雖沒有commit,但滿足prepare和binlog完整,所以重啟後會自動commit。備份:有binlog. 一致

undo log有兩個作用:提供回滾和多個行版本控制(mvcc).主要分為兩種

在資料修改的時候,不僅記錄了redo,還記錄了相對應的undo,如果因為某些原因導致事務失敗或回滾了,可以借助該undo進行回滾。當delete一條記錄時,undo log中會記錄一條對應的insert記錄,反之亦然,當update一條記錄時,它記錄一條對應相反的update記錄。

當執行rollback時,就可以從undo log中的邏輯記錄讀取到相應的內容並進行回滾

代表事務在insert新記錄時產生的undo log, 只在事務回滾時需要,並且在事務提交後可以被立即丟棄

事務在進行update或delete時產生的undo log; 不僅在事務回滾時需要,在快照讀時也需要;所以不能隨便刪除,只有在快速讀或事務回滾不涉及該日誌時,對應的日誌才會被purge執行緒統一清除

mysql事務回滾

先收集網上的一些,待仔細測試研究 事務是資料庫更新操作的基本單位,事務回滾是指將該事務已經完成的對資料庫的更新操作撤銷。所謂事務是使用者定義的乙個資料庫操作序列,這些操作要麼全做要麼全不做,是乙個不可分割的工作 單位。例如,在關聯式資料庫中,乙個事務可以是一條sql語句 一組sql語句或整個程式。簡...

MySQL事務的回滾

在操作乙個事務時,如果,發現當前事務中的操作不合理,此時,只要還沒有提交事務,就可以通過回滾來取消當前事務 a賬號有1000元,b賬號有1000元 開啟乙個事務,使用update語句,將a賬號的100元,轉給b賬號 上述語句執行成功後,檢視a賬戶和b賬戶的金額 可以看出,a賬戶成功給b賬戶轉賬100...

MySQL事務和事務回滾

1 定義 一件事從開始發生到結束的整個過程 2 作用 確保資料一致性 3 事務和事務回滾應用 1 mysql中sql命令會自動commit到資料庫 show variables like autocommit 2 事務應用 1 開啟事務 mysql begin mysql 一條或多條sql語句 此時...