mysql主從複製、讀寫分離

1、MySql介紹

MySQL做爲世界上使用最爲普遍的數據庫之一,免費是其緣由之一。但不可忽略的是它自己的功能的確很強大。隨着技術的發展,在實際的生產環境中,由單臺MySQL數據庫服務器不能知足實際的需求。mysql

此時數據庫集羣就很好的解決了這個問題了。採用MySQL分佈式集羣,可以搭建一個高併發、負載均衡的集羣服務器。在此以前咱們必需要保證每臺MySQL服務器裏的數據同步。sql

數據同步咱們能夠經過MySQL內部配置就能夠輕鬆完成,主要有主從(master slave )複製和主主複製。數據庫

2、主從複製介紹

在MySQL集羣環境中,能夠分爲主節點與從節點,經過主從複製能夠實現數據備份、故障轉移、MySQL集羣、高可用、讀寫分離等。服務器

MySQL的主從複製是MySQL自己自帶的一個功能,不須要額外的第三方軟件就能夠實現,其複製功能並非copy文件來實現的,而是藉助binlog日誌文件裏面的SQL命令實現的主從複製,能夠理解爲我再Master端執行了一條SQL命令,那麼在Salve端一樣會執行一遍,從而達到主從複製的,同步數據的效果。網絡

理解圖:併發

3、主從複製原理

Mysql 中有一種日誌叫作 bin 日誌(二進制日誌)。這個日誌會記錄下全部修改了數據庫的SQL 語句(insert,update,delete,create/alter/drop table, grant 等等)。負載均衡

MySQL的主從複製是MySQL自己自帶的一個功能,不須要額外的第三方軟件就能夠實現,其複製功能並非copy文件來實現的,而是藉助binlog日誌文件裏面的SQL命令實現的主從複製,異步

能夠理解爲我再Master端執行了一條SQL命令,那麼在Salve端一樣會執行一遍,從而達到主從複製的效果。分佈式

從庫生成兩個線程,一個I/O線程,一個SQL線程; i/o線程去請求主庫 的binlog,並將獲得的binlog日誌寫到relay log(中繼日誌) 文件中;高併發

主庫會生成一個 log dump 線程,用來給從庫 i/o線程傳binlog; SQL 線程,會讀取relay log文件中的日誌,並解析成具體操做,來實現主從的操做一致,而最終數據一致;

複製流程圖(來自網絡):

本身理解畫圖:

 複製過程:

一、主節點必須啓用二進制日誌,記錄任何修改了數據庫數據的事件。
二、從節點開啓一個線程(I/O Thread)把本身扮演成 mysql 的客戶端,經過 mysql 協議,請求主節點的二進制日誌文件中的事件
三、主節點啓動一個線程(dump Thread),檢查本身二進制日誌中的事件,跟對方請求的位置對比,若是不帶請求位置參數,則主節點就會從第一個日誌文件中的第一個事件一個一個發送給從節點。
四、從節點接收到主節點發送過來的數據把它放置到中繼日誌(Relay log)文件中。並記錄該次請求到主節點的具體哪個二進制日誌文件內部的哪個位置(主節點中的二進制文件會有多個,在後面詳細講解)。
五、從節點啓動另一個線程(sql Thread ),把 Relay log 中的事件讀取出來,並在本地再執行一次。

複製中線程的做用:

從節點:

I/O Thread: 從 Master 節點請求二進制日誌事件,並保存於中繼日誌中。
Sql Thread: 從Relay log 中讀取日誌事件並在本地完成重放。

主節點:

Dump Thread:爲每一個 Slave 的 I/O Thread 啓動一個 dump 線程,用於向從節點發送二進制事件。
**思考:**從節點須要創建二進制日誌文件嗎?
看狀況,若是從節點須要做爲其餘節點的主節點時,是須要開啓二進制日誌文件的。這種狀況叫作級聯複製。若是隻是做爲從節點,則不須要建立二進制文件。

Mysql複製特色:

一、異步複製:主節點中一個用戶請求一個寫操做時,主節點不須要把寫的數據在本地操做完成同時發送給從服務器並等待從服務器反饋寫入完成,再響應用戶。

主節點只須要把寫入操做在本地完成,就響應用戶。可是,從節點中的數據有可能會落後主節點,可使用(不少軟件來檢查是否落後)
二、主從數據不一致。

主從複製配置過程:

主服務器節點 

  1. 啓用二進制日誌。
  2. 爲當前節點設置一個全局惟一的server_id。
  3. 建立有複製權限的用戶帳號 REPLIACTION SLAVE ,REPLIATION CLIENT。

 vi  /etc/my.cnf  新增如下內容

server_id=177 ###服務器id log-bin=mysql-bin   ###開啓日誌文件

重啓mysql服務 service mysqld restart

驗證是否已經配置成功

show variables like '%server_id%';

可以查詢對應配置文件中的server_id 說明已經配置成功,以下圖:

show master status;

可以看到同步的文件,和行數 說明已經配置成功。如圖

 

從服務節點:

            一、克隆服務器

            二、啓動中繼日誌。

           三、爲當前節點設置一個全局惟一的server_id。

           四、使用有複製權限的用戶帳號鏈接至主節點,並啓動複製線程。

vi /etc/my.cnf server_id=178 ###從服務器server_id log-bin=mysql-bin ###日誌文件同步方式 binlog_do_db=test   ###同步數據庫

 

重啓mysql服務 service mysqld restart

驗證是否已經配置成功

show variables like '%server_id%';

可以查詢對應配置文件中的server_id 說明已經配置成功

從服務器同步主服務器配置

CHANGE MASTER TO MASTER_HOST='192.168.80.135',MASTER_USER='root',MASTER_PASSWORD='root', MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=415

參數詳解: 
master_host: 主服務器的IP 
master_user: 主服務器上新建立的用戶名 
master_password: 用戶的密碼 
master_port: 主服務器的端口,若是不曾修改,默認便可。 
master_log_file: 主服務器二進制日誌文件的名稱,填寫查看主服務器的master狀態時顯示的File的值 
master_log_pos: 日誌的位置,填寫查看主服務器的master狀態時顯示的Position的值

開始同步 

start slave

檢查從服務器複製功能狀態

SHOW SLAVE STATUS

主要看這Slave_IO_Running、Slave_SQL_Running狀態,爲Yes則代表設置成功。

Slave_IO_Running:鏈接到主庫,並讀取主庫的日誌到本地,生成本地日誌文件

Slave_SQL_Running:讀取本地日誌文件,並執行日誌裏的SQL命令。

 若是以下錯誤:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

解決辦法

由於服務器克隆的時候交UUID產生了重複 ,解決辦法

Cat  /etc/my.cnf

cd /var/lib/mysql

rm -rf auto.cnf

重啓服務器便可

service mysqld restart

相關文章
相關標籤/搜索