1. 程式人生 > >資料庫主從分離

資料庫主從分離

資料庫的讀寫分離的好處?

    1. 將讀操作和寫操作分離到不同的資料庫上,避免主伺服器出現效能瓶頸;

    2. 主伺服器進行寫操作時,不影響查詢應用伺服器的查詢效能,降低阻塞,提高併發;

    3. 資料擁有多個容災副本,提高資料安全性,同時當主伺服器故障時,可立即切換到其他伺服器,提高系統可用性;

讀寫分離的基本原理就是讓主資料庫處理事務性增、改、刪操作(INSERT、UPDATE、DELETE)操作,而從資料庫處理SELECT查詢操作。資料庫複製被用來把事務性操作導致的變更同步到其他從資料庫。以SQL為例,主庫負責寫資料、讀資料。讀庫僅負責讀資料。每次有寫庫操作,同步更新到讀庫。寫庫就一個,讀庫可以有多個,採用日誌同步的方式實現主庫和多個讀庫的資料同步。

 

 Replication原理 
Mysql 的 Replication 是一個非同步的複製過程,從一個MySQL節點(稱之為Master)複製到另一個MySQL節點(稱之Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個執行緒來完成,其中兩個執行緒(SQL 執行緒和 I/O 執行緒)在 Slave 端,另外一個執行緒(I/O 執行緒)在 Master 端。 
  www.2cto.com  
要實現 MySQL 的 Replication ,首先必須開啟 Master 端的 Binary Log,因為整個複製過程實際上就是 Slave 從 Master 端獲取該日誌然後再在自己身上完全順序的執行日誌中所記錄的各種操作。 

看上去MySQL的Replication原理非常簡單,總結一下: 
* 每個從僅可以設定一個主。 
  * 主在執行sql之後,記錄二進位制log檔案(bin-log)。 
  * 從連線主,並從主獲取binlog,存於本地relay-log,並從上次記住的位置起執行sql,一旦遇到錯誤則停止同步。 
 
從這幾條Replication原理來看,可以有這些推論: 
* 主從間的資料庫不是實時同步,就算網路連線正常,也存在瞬間,主從資料不一致。 
  * 如果主從的網路斷開,從會在網路正常後,批量同步。 
  * 如果對從進行修改資料,那麼很可能從在執行主的bin-log時出現錯誤而停止同步,這個是很危險的操作。所以一般情況下,非常小心的修改從上的資料。 
  * 一個衍生的配置是雙主,互為主從配置,只要雙方的修改不衝突,可以工作良好。 
  * 如果需要多主的話,可以用環形配置,這樣任意一個節點的修改都可以同步到所有節點。

主從設定 

因為原理比較簡單,所以Replication從MySQL 3就支援,並在所有平臺下可以工作,多個MySQL節點甚至可以不同平臺,不同版本,不同區域網。做Replication配置包括使用者和my.ini(linux下為my.cnf)兩處設定。 

首先在主MySQL節點上,為slave建立一個使用者: 

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave'; 

實際上,為支援主從動態同步,或者手動切換,一般都是在所有主從節點上建立好這個使用者。然後就是MySQL本身的配置了,這需要修改my.cnf或者my.ini檔案。在mysqld這一節下面增加: 

server-id=1
auto-increment-increment=2 
auto-increment-offset=1 
log-bin 
binlog-do-db=mstest 
binlog_format=mixed 

master-host=192.168.1.62
master-user=slave 
master-password=slave 
replicate-do-db=mstest 

上面這兩段設定,前一段是為主而設定,後一段是為從設定的。也就是說在兩個MySQL節點上,各加一段就好。binlog-do-db和 replicate-do-db就是設定相應的需要做同步的資料庫了,auto-increment-increment和auto- increment-offset是為了支援雙主而設定的(參考下一節),在只做主從的時候,也可以不設定。 

雙主的設定 

從原理論來看MySQL也支援雙主的設定,即兩個MySQL節點互為主備,不過雖然理論上,雙主只要資料不衝突就可以工作的很好,但實際情況中還 是很容發生資料衝突的,比如在同步完成之前,雙方都修改同一條記錄。因此在實際中,最好不要讓兩邊同時修改。即邏輯上仍按照主從的方式工作。但雙主的設定 仍然是有意義的,因為這樣做之後,切換主備會變的很簡單。因為在出現故障後,如果之前配置了雙主,則直接切換主備會很容易。 
  雙主在設定時,只需將上面的一段設定複製一份,分別寫入兩個MySQL節點的配置檔案,但要修改相應的server-id,auto- increment-offset和master-host。auto-increment-offset就是為了讓雙主同時在一張表中進行新增操作時不 會出現id衝突,所以在兩個節點上auto-increment-offset設定為不同的值就好。  另:不要忘了,在兩個節點上都為對方建立使用者。應用層的負載均衡  本文只介紹了MySQL自身的Repilication配置,在上面的圖中也可以看出,有了Replication,還需要應用層(或者中介軟體)做一個負載均衡,這樣才能最大程度發揮MySQL Replication的優勢,這些將在以後探討。

  Mysql的 Replication 是一個非同步的複製過程, 從一個 Mysql instace(我們稱之為 Master)複製到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個執行緒來完成,其中兩個執行緒(Sql執行緒和IO執行緒)在 Slave 端,另外一個執行緒(IO執行緒)在 Master 端。 要實現 MySQL 的 Replication ,首先必須開啟 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否則無法實現。因為整個複製過程實際上就是Slave從Master端獲取該日誌然後再在自己身上完全 順序的執行日誌中所記錄的各種操作。開啟 MySQL 的 Binary Log 可以通過在啟動 MySQL Server 的過程中使用 “—log-bin” 引數選項,或者在 my.cnf 配置檔案中的 mysqld 引數組([mysqld]標識後的引數部分)增加 “log-bin” 引數項。
  www.2cto.com     MySQL 複製的基本過程如下:   1. Slave 上面的IO執行緒連線上 Master,並請求從指定日誌檔案的指定位置(或者從最開始的日誌)之後的日誌內容;    2. Master 接收到來自 Slave 的 IO 執行緒的請求後,通過負責複製的 IO 執行緒根據請求資訊讀取指定日誌指定位置之後的日誌資訊,返回給 Slave 端的 IO 執行緒。返回資訊中除了日誌所包含的資訊之外,還包括本次返回的資訊在 Master 端的 Binary Log 檔案的名稱以及在 Binary Log 中的位置;

    1. 將讀操作和寫操作分離到不同的資料庫上,避免主伺服器出現效能瓶頸;

    2. 主伺服器進行寫操作時,不影響查詢應用伺服器的查詢效能,降低阻塞,提高併發;

    3. 資料擁有多個容災副本,提高資料安全性,同時當主伺服器故障時,可立即切換到其他伺服器,提高系統可用性;

讀寫分離的基本原理就是讓主資料庫處理事務性增、改、刪操作(INSERT、UPDATE、DELETE)操作,而從資料庫處理SELECT查詢操作。資料庫複製被用來把事務性操作導致的變更同步到其他從資料庫。以SQL為例,主庫負責寫資料、讀資料。讀庫僅負責讀資料。每次有寫庫操作,同步更新到讀庫。寫庫就一個,讀庫可以有多個,採用日誌同步的方式實現主庫和多個讀庫的資料同步。

 

 Replication原理 
Mysql 的 Replication 是一個非同步的複製過程,從一個MySQL節點(稱之為Master)複製到另一個MySQL節點(稱之Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個執行緒來完成,其中兩個執行緒(SQL 執行緒和 I/O 執行緒)在 Slave 端,另外一個執行緒(I/O 執行緒)在 Master 端。 
  www.2cto.com  
要實現 MySQL 的 Replication ,首先必須開啟 Master 端的 Binary Log,因為整個複製過程實際上就是 Slave 從 Master 端獲取該日誌然後再在自己身上完全順序的執行日誌中所記錄的各種操作。 

看上去MySQL的Replication原理非常簡單,總結一下: 
* 每個從僅可以設定一個主。 
  * 主在執行sql之後,記錄二進位制log檔案(bin-log)。 
  * 從連線主,並從主獲取binlog,存於本地relay-log,並從上次記住的位置起執行sql,一旦遇到錯誤則停止同步。 
 
從這幾條Replication原理來看,可以有這些推論: 
* 主從間的資料庫不是實時同步,就算網路連線正常,也存在瞬間,主從資料不一致。 
  * 如果主從的網路斷開,從會在網路正常後,批量同步。 
  * 如果對從進行修改資料,那麼很可能從在執行主的bin-log時出現錯誤而停止同步,這個是很危險的操作。所以一般情況下,非常小心的修改從上的資料。 
  * 一個衍生的配置是雙主,互為主從配置,只要雙方的修改不衝突,可以工作良好。 
  * 如果需要多主的話,可以用環形配置,這樣任意一個節點的修改都可以同步到所有節點。

主從設定 

因為原理比較簡單,所以Replication從MySQL 3就支援,並在所有平臺下可以工作,多個MySQL節點甚至可以不同平臺,不同版本,不同區域網。做Replication配置包括使用者和my.ini(linux下為my.cnf)兩處設定。 

首先在主MySQL節點上,為slave建立一個使用者: 

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave'; 

實際上,為支援主從動態同步,或者手動切換,一般都是在所有主從節點上建立好這個使用者。然後就是MySQL本身的配置了,這需要修改my.cnf或者my.ini檔案。在mysqld這一節下面增加: 

server-id=1
auto-increment-increment=2 
auto-increment-offset=1 
log-bin 
binlog-do-db=mstest 
binlog_format=mixed 

master-host=192.168.1.62
master-user=slave 
master-password=slave 
replicate-do-db=mstest 

上面這兩段設定,前一段是為主而設定,後一段是為從設定的。也就是說在兩個MySQL節點上,各加一段就好。binlog-do-db和 replicate-do-db就是設定相應的需要做同步的資料庫了,auto-increment-increment和auto- increment-offset是為了支援雙主而設定的(參考下一節),在只做主從的時候,也可以不設定。 

雙主的設定 

從原理論來看MySQL也支援雙主的設定,即兩個MySQL節點互為主備,不過雖然理論上,雙主只要資料不衝突就可以工作的很好,但實際情況中還 是很容發生資料衝突的,比如在同步完成之前,雙方都修改同一條記錄。因此在實際中,最好不要讓兩邊同時修改。即邏輯上仍按照主從的方式工作。但雙主的設定 仍然是有意義的,因為這樣做之後,切換主備會變的很簡單。因為在出現故障後,如果之前配置了雙主,則直接切換主備會很容易。 
  雙主在設定時,只需將上面的一段設定複製一份,分別寫入兩個MySQL節點的配置檔案,但要修改相應的server-id,auto- increment-offset和master-host。auto-increment-offset就是為了讓雙主同時在一張表中進行新增操作時不 會出現id衝突,所以在兩個節點上auto-increment-offset設定為不同的值就好。  另:不要忘了,在兩個節點上都為對方建立使用者。應用層的負載均衡  本文只介紹了MySQL自身的Repilication配置,在上面的圖中也可以看出,有了Replication,還需要應用層(或者中介軟體)做一個負載均衡,這樣才能最大程度發揮MySQL Replication的優勢,這些將在以後探討。

  Mysql的 Replication 是一個非同步的複製過程, 從一個 Mysql instace(我們稱之為 Master)複製到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個執行緒來完成,其中兩個執行緒(Sql執行緒和IO執行緒)在 Slave 端,另外一個執行緒(IO執行緒)在 Master 端。 要實現 MySQL 的 Replication ,首先必須開啟 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否則無法實現。因為整個複製過程實際上就是Slave從Master端獲取該日誌然後再在自己身上完全 順序的執行日誌中所記錄的各種操作。開啟 MySQL 的 Binary Log 可以通過在啟動 MySQL Server 的過程中使用 “—log-bin” 引數選項,或者在 my.cnf 配置檔案中的 mysqld 引數組([mysqld]標識後的引數部分)增加 “log-bin” 引數項。
  www.2cto.com     MySQL 複製的基本過程如下:   1. Slave 上面的IO執行緒連線上 Master,並請求從指定日誌檔案的指定位置(或者從最開始的日誌)之後的日誌內容;    2. Master 接收到來自 Slave 的 IO 執行緒的請求後,通過負責複製的 IO 執行緒根據請求資訊讀取指定日誌指定位置之後的日誌資訊,返回給 Slave 端的 IO 執行緒。返回資訊中除了日誌所包含的資訊之外,還包括本次返回的資訊在 Master 端的 Binary Log 檔案的名稱以及在 Binary Log 中的位置;