MariaDB是MySQL的一個主要的開源分支。由于oracle收購MySQL之后，擔心將其閉源，MySQL之父monty主導開發了MariaDB，用自己小女兒的名字命名。Maria DB完全兼容MySQL，可以輕松切換。在存儲引擎方面，MariaDB 10.1及之前版本均使用Percona XtraDB做為默認引擎，從10.2開始使用MySQL官方的InnoDB做為默認引擎。XtraDB是 InnoDB 存儲引擎的增強版，用來更好地發揮最新的計算機硬件系統性能，同時還包含一些在高性能環境下的新特性。在MySQL 5.1和5.5版本上有很好的性能表現。但是后來MySQL官方幾乎把所有的優秀特性都實現了，所以MariaDB 10.2開始又切換到了InnoDB。在新功能特性方面，MariaDB優化了子查詢，增加了多源復制(基于表的并行復制)，Galera Cluster集群等。雖然MySQL 5.7以后也增加了相關特性，比如基于表的并行復制，但MySQL社區版畢竟一個閹割版本，企業版又是閉源收費的。此外MariaDB在高并發環境下穩定性比MySQL好很多，壓測的時候隨著連接數的增大性能曲線不會大幅抖動，很平穩。

安裝MariaDB

我是在虛擬機在中安裝了centos6.9，數據庫版本選擇是mariadb10.2。通過yum的方式進行安裝，在線查找安裝源：在線源信息

新建MariaDB.repo文件：

選擇自己將安裝版本，將源信息復制到MariaDB.repo中。在安裝的過程中可能因為網絡或者缺少庫文件而造成安裝失敗。在這里推薦大家使用國內的鏡像：http://mirrors.ustc.edu.cn/mariadb/yum/。選擇合適的操作系統合適數據庫版本。

# MariaDB 10.2 CentOS repository list -created 2018-06-22 02:15 UTC

# http://downloads.mariadb.org/mariadb/repositories/

[mariadb]

name = MariaDB

baseurl = http://mirrors.ustc.edu.cn/mariadb/yum/10.2/centos/6.9/x86_64

gpgkey=http://mirrors.ustc.edu.cn/mariadb/yum/RPM-GPG-KEY-MariaDB

gpgcheck=1

(↑國內源信息內容)

安裝MariaDB：sudo yum install MariaDB-server MariaDB-client

啟動MariaDB：service mysql start

開機啟動：chkconfig mysql on

初始設置MariaDB：mysql_secure_installation

設置一下root用戶密碼，其他設置全部按回車就可以了。

通過客戶端訪問數據庫：mysql -u root -p

接下來設置權限，允許遠程機器通過root用戶訪問數據庫。

GRANT ALL PRIVILEGES ON *.* to 'root'@'%' identified by 'root';(可以指定特定IP訪問，如果是%表示任意IP訪問)

別忘了刷新權限：flush privileges;

如果防火墻處于開啟狀態，先關閉掉。service iptables stop

MariaDB主從同步原理

先說一下，數據庫主從同步復制能解決的問題，我能想到就是數據備份和負載均衡。數據備份自然不用說，負載均衡讀寫分離的前提就是主從同步復制，然后通過數據庫代理(比如：mycat、mysql router等)分流應用的讀寫請求，降低數據庫的壓力，提高訪問性能。至于高可用和容錯性，我認為主從單向同步無法解決。首先，如果主庫宕機，數據庫代理會把從庫也變為不可用，或者只能讀不能寫。而且，寫操作只能在主庫上進行，如果在從庫也不小心寫入操作，那么就會造成數據不一致或者同步狀態異常等問題。

a) MariaDB的數據變化會記錄在二進制日志中(bing log)，我們需要在主庫的配置文件中開啟這個日志功能。

b) 從庫有一個I/O線程會監聽主庫的二進制日志改變事件，把事件內容記錄到中繼日志(Relay log)中。我們需要在從庫中開啟這個日志功能。

c) 從庫的SQL線程會從中繼日志中讀取事件，并重放事件更新到從庫中。

Binglog的復制類型分為三種：

基于sql語句的復制(statement)，每一條會修改數據的?SQL?都會記錄到?master?的?bin-log?中。slave?在復制的時候?SQL?進程會解析成和原來?master?端執行過的相同的?SQL?再次執行。

基于行內容的復制(row)，日志中會記錄成每一行數據被修改的形式，然后在?slave?端再對相同的數據進行修改。

混合復制模式(mixed)，就是前兩種模式的結合。在?Mixed?模式下，MySQL?會根據執行的每一條具體的?SQL?語句來區分對待記錄的日志形式，也就是在?statement?和?row?之間選擇一種。

statement的方式產生的binglog日志文件量小，節省了I/O和存儲資源。但在執行一些特定函數比如now()、?last_insert_id()在主庫和從庫上會產生不一樣的結果。而且復制的時候相對于row的模式會產生更多的行級鎖表。row的方式任何情況都可以被復制，這對復制來說是最安全可靠的。最大的一個問題是產生的日志量太大，因為要記錄數據改動的內容。尤其是對一個大表執行了alert tbale產生的日志量是驚人的。新版的MySQL和MariaDB對row模式進行的優化，并不是所有的修改都會以?row?模式來記錄，比如遇到表結構變更的時候就會以?statement?模式來記錄。

默認情況下復制都是異步進行的，這樣的性能最佳。但問題在于，異步情況下，如果從庫沒有接受到主庫發過來的二級制事件日志，而且主庫并沒有感知到這個情況的發生，這樣就會出現主從數據不一致的情況發生，造成數據丟失。為了解決異步復制數據丟失的問題，從MySQL5.5開始的數據庫引入了半同步的復制模式。該模式下從庫接受到主庫的日志信息，并寫入到自己的中繼日志中，然后會給主庫一個反饋，主庫接受到這個反饋才會告知當前會話操作完成。主庫確認從庫反饋有一個超時時間(rpl_semi_sync_master_timeout)，默認是10秒。如果超出這個時間，從還沒有反饋的話，就會切換到異步模式，不再等待slave從庫。如果主庫再次探測到slave從庫恢復，則會自動回到半同步復制模式。

注：半同步復制模式必須在主從節點同時啟用，否則主節點默認使用異步復制模式。

MariaDB主從同步復制配置

本文采用的半同步復制模式。首先查找MariaDB的安裝包中是否存在半同步復制插件：find / -name semisync*

在主庫中安裝插件：install plugin rpl_semi_sync_master soname 'semisync_master.so';

開啟主庫半同步復制：SET GLOBAL rpl_semi_sync_master_enabled =1;

在從庫中安裝插件：install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

開啟從半同步復制：SET GLOBAL rpl_semi_sync_slave_enabled =1;

配置主庫的server.cnf：vi /etc/my.cnf.d/server.cnf

skip_name_resolve = ON

innodb_file_per_table = ON

server-id = 10001? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #主庫唯一標識

log-bin=master-bin? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #開啟二級制日志

log-bin-index=master-bin.index

rpl_semi_sync_master_enabled=1? ? ? ? ? ? #開啟半同步復制，需要先安裝插件

rpl_semi_sync_master_timeout=10000? ? ?#主庫半同步復制模式等待從庫反回信息的超時時間

expire_logs_days = 5? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #日志的有效天數

binlog_format = row? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #基于行內容的復制

binlog_row_image = minimal? ? ? ? ? ? ? ? ? ? #行內容復制時，只保存修改過列。

重啟主庫：service mysql restart

查看主庫配置：show variables like 'rpl%';

rpl_semi_sync_master_enabled=ON 表示在master主庫上開啟半同步復制模式。

配置從庫的server.cnf：vi /etc/my.cnf.d/server.cnf

skip_name_resolve = ON

innodb_file_per_table = ON

server_id=10002? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #從庫唯一標識

relay_log_index = slave_relay_bin.index

relay_log = slave_relay_bin? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#開啟中繼日志

rpl_semi_sync_slave_enabled =1? ? ? ? ? ? ? ? ? ?#開啟半同步復制，需要先安裝插件

重啟從庫，并查看從庫配置：show variables like 'rpl%';

rpl_semi_sync_slave_enabled=ON 表示在slave從庫上開啟半同步復制模式。

查看主庫master狀態：show master status;

記錄File和Position，然后在主庫創建同步復制用戶：GRANT REPLICATION CLIENT,REPLICATION SLAVE ON? *.*? TO 'repluser'@'%' IDENTIFIED BY '123456';

登錄到從庫中執行下面的操作：

CHANGE MASTER TOMASTER_HOST='192.168.1.56',

MASTER_USER='repluser',

MASTER_PASSWORD='123456',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000004',

MASTER_LOG_POS=621;

啟動從庫同步狀態：start slave;

查看從庫同步狀態：show slave status \G

只要Slave_IO_Running和Slave_SQL_Runing這兩個參數為YES，證明主從同步已經開始正常工作了。

異常情況

Slave_IO_Running為No的情況一般是網絡問題或者讀取主機binglog文件位置不對。重新查看主庫狀態，記錄FIle和Position。然后stop slave；修改從庫指向的File和Position：

CHANGE MASTER TOMASTER_LOG_FILE='master-bin.000004', MASTER_LOG_POS=621;

啟動同步：start slave;

Slave_SQL_Running為NO的情況是有可能在主從同步之前沒有把主庫中完整數據導入到從庫中,這時候如果刪除一個從庫中沒有的數據，會造成Slave_SQL_Running狀態不可用。

同樣先停止同步：stop slave;

set global sql_slave_skip_counter=1;? //從庫直接跳過

啟動同步：start slave;

不管遇到同步的什么問題，我們都可以先通過last_errno和last_error信息來進行定位。

我們可以通過在從庫配置文件中設置：read_only=on，或則在從庫客戶端運行：set global read_only=1;來開啟從庫只讀模式，防止在從庫中寫入數據。這種方式不影響主從復制，只是禁止用戶在從庫上寫操作。但是對于super權限(ALL PRIVILEGES)的用戶這個設置是無效的，比如root用戶，所以我們要保證擁有super權限的用戶只能本機訪問。如果之前授權了root用戶遠程訪問的權限，那么先撤銷授權。修改或刪除myql庫中user表的對應數據。創建一個新的用戶并授予增刪查改的權限：GRANT select,insert,update,delete ON *.* to 'myuser'@'%' identified by '123456';

這時候我們用這個myuser遠程登錄到從庫，雖然授予了該用戶寫的權限，但執行寫操作的時候就會提示從庫是只讀的。這樣就可以保證從庫不會被意外寫入造成同步數據不一致。

如果想要禁止super權限的用戶也不能寫入，需要設置全局鎖：flush tables with read lock;但是這樣會造成從庫復制操作也無法進行。

一般會在主庫進行數據遷移的時候執行：flush tables with read lock;set global read_only=1;禁止所有用戶修改數據庫，等待數據遷移完成后，通過unlock tables;set global read_only=0;恢復主庫的寫入功能。

至此，關于MariaDB的主從同步就描述完成。在我學習的過程中參考了很多來自網絡的相關資料，由于來源很多，就不一一列舉了，感謝大家的分享。我也希望我的這個總結能對其他人有一點幫助。還有就是認真寫一點東西真的很耗時間，但這些時間上的投入我認為是很有必要的。

總結

以上是生活随笔為你收集整理的mariadb 和mysql主从_MariaDB主从同步的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。