mariadb主從複製

背景

最近擼了一個騰訊雲的服務器，可是看着是kvm的架構，有點不放心，因此把博客數據庫在阿里雲上面作了一個主從複製的災難備份

主從複製原理

mariadb自己就是和mysql基本同樣，因此mysql和mariadb的方法是能夠通用的，可是注意，maraidb因爲自己版本號高於mysql，因此不要將mysql和mariadb混用作主從複製，同時注意主數據庫版本必須低於或者等於從數據庫。

mysql支持的複製類型：

1. 基於語句的複製：在主服務器上執行的SQL語句，在從服務器上執行一樣的語句。MySQL默認採用基於語句的複製，效率比較高。一旦發現無法精確複製時，會自動選着基於行的複製。

2. 基於行的複製：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持

3. 混合類型的複製: 默認採用基於語句的複製，一旦發現基於語句的沒法精確的複製時，就會採用基於行的複製。

總體上來講，複製有3個步驟：

1. master將改變記錄到二進制日誌(binary log)中（這些記錄叫作二進制日誌事件，binary log events）

2. slave將master的binary log events拷貝到它的中繼日誌(relay log)；

3. slave重作中繼日誌中的事件，將改變反映它本身的數據。

也就是說，總共有三個線程被啓動來作主從複製，主服務器一個線程，從服務器兩個線程

• 第一部分就是master記錄二進制日誌。在每一個事務更新數據完成以前，master在二日誌記錄這些改變。MySQL將事務串行的寫入二進制日誌，即便事務中的語句都是交叉執行的。在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。

• 下一步就是slave將master的binary log拷貝到它本身的中繼日誌。首先，slave開始一個工做線程——I/O線程。I/O線程在master上打開一個普通的鏈接，而後開始binlog dump process。Binlog dump process從master的二進制日誌中讀取事件，若是已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。

• SQL slave thread（SQL從線程）處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌一般會位於OS的緩存中，因此中繼日誌的開銷很小。

此外，在master中也有一個工做線程：和其它MySQL的鏈接同樣，slave在master中打開一個鏈接也會使得master開始一個線程。複製過程有一個很重要的限制——複製在slave上是串行化的，也就是說master上的並行更新操做不能在slave上並行操做。

配置步驟

主服務器配置

在Master的數據庫中創建一個備份賬戶：每一個slave使用標準的MySQL用戶名和密碼鏈接master。進行復制操做的用戶會授予REPLICATION SLAVE權限。用戶名的密碼都會存儲在文本文件master.info中
命令以下：

mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* 
TO backup@’10.100.0.200’ 
IDENTIFIED BY ‘1234’;

關停Master服務器，將Master中的數據拷貝到B服務器中，使得Master和slave中的數據同步，而且確保在所有設置操做結束前，禁止在Master和slave服務器中進行寫操做，使得兩數據庫中的數據必定要相同！
（假如是你徹底新安裝mysql主從服務器，這個一步就不須要。由於新安裝的master和slave有相同的數據）
注意：必定要複製全部的數據庫，而不能單單複製須要主從複製的數據庫，建議冷備份，經過tar命令打包。

---

接下來對master進行配置，包括打開二進制日誌，指定惟一的servr ID。例如，在配置文件加入以下值：
server-id=1
log-bin=mysql-bin
server-id：爲主服務器A的ID值
log-bin：二進制變動日值
重啓master，運行SHOW MASTER STATUS，
記錄file和position參數，

配置從服務器

Slave的配置與master相似，你一樣須要重啓slave的MySQL。以下：

log_bin           = mysql-bin
server_id         = 2
relay_log         = mysql-relay-bin
log_slave_updates = 1
read_only         = 1

server_id是必須的，並且惟一。slave沒有必要開啓二進制日誌，可是在一些狀況下，必須設置，例如，若是slave爲其它slave的master，必須設置bin_log。在這裏，咱們開啓了二進制日誌，並且顯示的命名(默認名稱爲hostname，可是，若是hostname改變則會出現問題)。
relay_log配置中繼日誌，log_slave_updates表示slave將複製事件寫進本身的二進制日誌(後面會看到它的用處)。
有些人開啓了slave的二進制日誌，卻沒有設置log_slave_updates，而後查看slave的數據是否改變，這是一種錯誤的配置。因此，儘可能使用read_only，它防止改變數據(除了特殊的線程)。可是，read_only並是很實用，特別是那些須要在slave上建立表的應用。
接下來就是讓slave鏈接master，並開始重作master二進制日誌中的事件。你不該該用配置文件進行該操做，而應該使用CHANGE MASTER TO語句，該語句能夠徹底取代對配置文件的修改，並且它能夠爲slave指定不一樣的master，而不須要中止服務器。以下：

mysql> CHANGE MASTER TO MASTER_HOST='server1',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='p4ssword',
    -> MASTER_LOG_FILE='mysql-bin.000001',
    -> MASTER_LOG_POS=0;

master_log_pos就是剛纔記錄的position參數
你能夠用SHOW SLAVE STATUS語句查看slave的設置是否正確：

mysql> SHOW SLAVE STATUS\G

代表slave尚未開始複製過程。日誌的位置爲4而不是0，這是由於0只是日誌文件的開始位置，並非日誌位置。實際上，MySQL知道的第一個事件的位置是4。
爲了開始複製，你能夠運行：

mysql> START SLAVE;

運行SHOW SLAVE STATUS查看輸出結果：

mysql> SHOW SLAVE STATUS\G

在這裏主要是看:

Slave_IO_Running=Yes
               Slave_SQL_Running=Yes

slave的I/O和SQL線程都已經開始運行，並且Seconds_Behind_Master再也不是NULL。日誌的位置增長了，意味着一些事件被獲取並執行了。若是你在master上進行修改，你能夠在slave上看到各類日誌文件的位置的變化，一樣，你也能夠看到數據庫中數據的變化。你可查看master和slave上線程的狀態。