詳解MySQL實(shí)現(xiàn)主從復(fù)制過程

一、什么是主從復(fù)制

將主數(shù)據(jù)庫中的DDL和DML操作通過二進(jìn)制日志（BINLOG）傳輸?shù)綇臄?shù)據(jù)庫上，然后將這些日志重新執(zhí)行（重做）；從而使得從數(shù)據(jù)庫的數(shù)據(jù)與主數(shù)據(jù)庫保持一致。

二、主從復(fù)制的作用

1、主數(shù)據(jù)庫出現(xiàn)問題，可以切換到從數(shù)據(jù)庫。

2、可以進(jìn)行數(shù)據(jù)庫層面的讀寫分離，

3、可以在從數(shù)據(jù)庫上進(jìn)行日常備份

三、復(fù)制過程

Binary log：主數(shù)據(jù)庫的二進(jìn)制日志

Relay log：從服務(wù)器的中繼日志

第一步：master在每個(gè)事務(wù)更新數(shù)據(jù)完成之前，將該操作記錄串行地寫入到binlog文件中。

第二步：salve開啟一個(gè)I/O Thread，該線程在master打開一個(gè)普通連接，主要工作是binlog dump process。如果讀取的進(jìn)度已經(jīng)跟上了master，就進(jìn)入睡眠狀態(tài)并等待master產(chǎn)生新的事件。I/O線程最終的目的是將這些事件寫入到中繼日志中。

第三步：SQL Thread會讀取中繼日志，并順序執(zhí)行該日志中的SQL事件，從而與主數(shù)據(jù)庫中的數(shù)據(jù)保持一致。

四、主從復(fù)制的具體操作

我是在同一個(gè)windows上不同的路徑下安裝兩個(gè)msyql實(shí)例。建議這里主從兩個(gè)mysql的安裝版本一致，盡管我自己的是不一致的。

1、分別修改主從數(shù)據(jù)庫的配置文件my.ini

master

3306是mysql默認(rèn)端口號，這里master實(shí)例中可以不用修改；server-id用來指定唯一id，不同的mysql實(shí)例不重復(fù)即可；binlog-do-db指定需要復(fù)制的數(shù)據(jù)庫；log-bin用來開啟二進(jìn)制日志文件。

salve

由于主從數(shù)據(jù)庫待會都是在通一臺電腦上運(yùn)行，所以端口需要設(shè)置成不一樣，這里是3307

replicate-do-db：需要同步的數(shù)據(jù)庫名稱，與master上的配置保持一致。

2、在master上創(chuàng)建一個(gè)專門用于復(fù)制的賬戶：weidai/123456

這個(gè)新增的賬戶可以在表mysql.user中進(jìn)行查詢：

我第一次操作的時(shí)候，到這里就完成了這個(gè)賬號的創(chuàng)建，但是到真正復(fù)制的時(shí)候，卻發(fā)現(xiàn)復(fù)制沒有成功，排查錯誤的時(shí)候發(fā)現(xiàn)master生成的binlong沒有問題，然后查看slave的狀態(tài)：

在結(jié)尾處有這樣一行錯誤：

使用weidai這個(gè)賬號無法連接到master，所以應(yīng)該是沒有獲取到master的binlog，導(dǎo)致中繼日志無法生成。

我反復(fù)檢查了賬號和密碼都沒有發(fā)現(xiàn)問題，然后查找相關(guān)資料，才發(fā)現(xiàn)是因?yàn)樵趍aster創(chuàng)建新用戶的時(shí)候少了一步操作：

新設(shè)置用戶或更改密碼后需用flush privileges刷新MySQL的系統(tǒng)權(quán)限相關(guān)表，否則會出現(xiàn)拒絕訪問。這就是出現(xiàn)前面錯誤的原因。另外還有一種辦法是重新啟動mysql服務(wù)器，來使新設(shè)置生效。

3、獲取主數(shù)據(jù)庫中此刻數(shù)據(jù)的位置，主要用于從數(shù)據(jù)啟動后，復(fù)制數(shù)據(jù)的起始位置，但是在獲取這個(gè)狀態(tài)值之前，主數(shù)據(jù)庫就不能再有數(shù)據(jù)的修改操作，所以需要先設(shè)置讀鎖定有效

4、主庫進(jìn)行數(shù)據(jù)備份，備份的手段有很多種，這里不展開介紹，可以參考我上一篇文章，備份結(jié)束后可以釋放讀鎖，主庫就可以進(jìn)行寫操作

5、啟動從數(shù)據(jù)庫，對剛才備份的數(shù)據(jù)進(jìn)行還原，這個(gè)時(shí)候主從數(shù)據(jù)庫在備份那個(gè)時(shí)間點(diǎn)的數(shù)據(jù)是一致的。

6、在從數(shù)據(jù)庫上進(jìn)行復(fù)制行為的相關(guān)配置

7、這個(gè)時(shí)候配置完成，但是從數(shù)據(jù)庫還不能進(jìn)行同步，需要啟動slave線程

8、在master中創(chuàng)建表和新增數(shù)據(jù)，在slave中觀察：

可以看出，我在master中進(jìn)行的操作，都能在slave中體現(xiàn)出來，這個(gè)時(shí)候slave就如同是master的鏡子一樣。

五、主從同步狀態(tài)解讀

在slave上使用命令進(jìn)行查看：

由于排版太過于難看，我整理如下：

Slave_IO_STATE:Waiting for master to send event

Master_host:127.0.0.1

Master_user:weidai

Master_port:3306

connnect_retry:60

Master_log_file:mysql-bin.000005

Read_Master_log_pos:1662

Relay_log_file:AE6Z*****-relay-bin.000002

Relay_log_pos:1415

Slave_IO_Running:yes

Slave_SQL_Running:yes

----------------------------------------------------------華麗麗分割線-------------------------------------------

Slave_IO_Running:yes

Slave_SQL_Running:yes

這兩個(gè)線程前面有提到，是slave上參與復(fù)制過程中兩個(gè)很重要的線程。YES表示正常，NO表示異常。

Slave_IO線程主要是將master上的binlong日志內(nèi)容復(fù)制到slave的中繼日志中（Relay_log），一般出現(xiàn)問題的概率不大， 出現(xiàn)問題大多數(shù)是因?yàn)闄?quán)限或者網(wǎng)絡(luò)等問題，導(dǎo)致連接不上master。如同前面提到的那個(gè)錯誤。

Slave_SQL線程負(fù)責(zé)將中繼日志中的SQL執(zhí)行一遍，相對來說出錯的概率大些。如有人手動的在從庫中插入一些記錄，導(dǎo)致主從同步的時(shí)候出現(xiàn)主鍵沖突。

Slave_IO_STATE:Waiting for master to send event

這個(gè)狀態(tài)表示中繼日志同步完成，等待master有新的事件產(chǎn)生。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。