MySQL 複製、擴展性、高可用、備份

注:本篇是《高性能Mysql》第三版的讀書筆記

 

複製

MySQL支持兩種複製方式:基於行的複製和基於語句的複製。

在主庫記錄二進制日誌,然後在備庫重放日誌的方式來實現異步的數據複製,可想而知,從庫數據一致性是有延遲的。

複製解決的問題:數據分佈、負載均衡、備份、高可用和故障切換、MySQL升級測試。

基於語句複製模式下:

主庫會記錄那些造成數據更改的查詢,當備庫讀取並重放這些事件時,實際上是把主庫上執行過的SQL在執行一遍。

缺點:

對於那些使用時間戳的數據肯定不百分百準,更新必須是串行的,就需要很多鎖開銷。

優點:

出現問題好定位。

基於行的複製下:

將實際數據記錄到二進制日誌中。  數據準確,但是相當於一個黑盒,不知道服務器幹了啥,不好排查問題。

 

注:log_slave_updates可以讓備庫成爲主庫

 

可擴展的MySQL

擴展性包括水平擴展和垂直擴展。水平擴展就是集羣,垂直擴展就是服務器更加牛逼了(或者分庫分表),主要是硬件上的提升。垂直擴展的瓶頸點很輕易被捕獲。

對於有限的服務器,例如一個服務器,對數據的擴展就是分區了。將數據按月分表是很普遍的解決方式。

 

  • 當讀操作比較多就  主從複製-讀寫分離。讓從庫也可以被讀取。  分表
  • 當寫操作比較多就  分庫  這樣互不影響、分庫有多重原因:不同業務的拆分,多個MySQL實例導致的水平分庫操作。

可以多服務器多實例擴展。這樣能更好的利用硬件資源。

對於多實例的自增id重複問題:可以使用redis的incr函數。

 

對於負載均衡來說,需要一個負載均衡器來均勻分配請求到MySQL集羣。

基於查詢分離:對於讀寫分離,肯定想的是重要&不能髒的數據從主庫讀寫,其餘數據在從庫讀取。但是這樣往往導致從庫利用率不高。所以都會使用負載均衡器來控制。

 

高可用

高可用實際上意味着“更少的宕機時間”

高可用實際上是在宕機造成的損失與降低宕機時間所花費的成本之間取一個平衡。

 

備份與恢復

備份解決的問題:災難恢復,審計等。

對於大數據庫來說,物理備份是必須的,邏輯備份太慢並受到資源的限制。從邏輯備份恢復需要很長的時間。

保存二進制日誌可以用於基於故障時間點的恢復。expire_logs_days 參數應該設置的足夠長。

有兩種主要的方法來備份MySQL數據:

  1. 邏輯備份和直接複製原始文件的物理備份。原始文件是指存在與硬盤上的文件。
  2. 邏輯備份將數據包含在一種MySQL能夠解析的格式中,要麼是SQL要麼是以某個符號分隔的文本。

邏輯備份理解爲複製的是sql文件,而物理備份是直接將磁盤上面的文件  dump出去了。

邏輯備份  mysqldump  

物理備份  XtraBackup  

物理備份非常容易誇平臺、對於innodb來說,物理備份的方式文件要比邏輯備份的文件大得多。

邏輯備份,相對更加輕便,文件更小,但是需要佔用MySQL服務器的資源。

服務器的二進制文件是備份的重要因素之一,它們對於基於時間點的恢復是必需的,並且通常比數據更小,所以更容易頻繁的備份

二進制日誌文件存放的內容大概是,事件的時間和日期,服務器的ID,執行的SQL類型,SQL語句。

 

mysqldump

mysqldump 屬於邏輯備份。加入–single-transaction 選項可以進行一致性備份。後臺進程會先設置 session 的事務隔離級別爲 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ),之後顯式開啓一個事務(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */),這樣就保證了該事務裏讀到的數據都是事務事務時候的快照。之後再把表的數據讀取出來。如果加上–master-data=1 的話,在剛開始的時候還會加一個數據庫的讀鎖(FLUSH TABLES WITH READ LOCK),等開啓事務後,再記錄下數據庫此時 binlog 的位置(showmaster status),馬上解鎖,再讀取表的數據。等所有的數據都已經導完,就可以結束事務

Xtrabackup:

xtrabackup 屬於物理備份,直接拷貝表空間文件,同時不斷掃描產生的 redo 日誌並保存下來。最後完成 innodb 的備份後,會做一個 flush engine logs 的操作(老版本在有 bug,在5.6 上不做此操作會丟數據),確保所有的 redo log 都已經落盤(涉及到事務的兩階段提交概念,因爲 xtrabackup 並不拷貝 binlog,所以必須保證所有的 redo log 都落盤,否則可能會丟最後一組提交事務的數據)。這個時間點就是 innodb 完成備份的時間點,數據文件雖然不是一致性的,但是有這段時間的 redo 就可以讓數據文件達到一致性(恢復的時候做的事情)。然後還需要 flush tables with read lock,把 myisam 等其他引擎的表給備份出來,備份完後解鎖。這樣就做到了完美的熱備。
 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章