將主數(shù)據(jù)庫中的DDL和DML操作通過二進制日志傳輸?shù)綇臄?shù)據(jù)庫上，然后將這些日志重新執(zhí)行（重做）；從而使得從數(shù)據(jù)庫的數(shù)據(jù)與主數(shù)據(jù)庫保持一致。
基本原理：
MySQL支持單向、異步復(fù)制，復(fù)制過程中一個服務(wù)器充當(dāng)主服務(wù)器，而一個或多個其它服務(wù)器充當(dāng)從服務(wù)器。
MySQL復(fù)制是基于主服務(wù)器在二進制日志中跟蹤所有對數(shù)據(jù)庫的更改。因此，要進行復(fù)制，必須在主服務(wù)器上啟用二進制日志。每個從服務(wù)器從主服務(wù)器接收主服務(wù)器已經(jīng)記錄到日志的數(shù)據(jù)。
當(dāng)一個從服務(wù)器連接主服務(wù)器時，它通知主服務(wù)器從服務(wù)器在日志中讀取的最后一次成功更新的位置。從服務(wù)器接收從那時起發(fā)生的任何更新，并在本機上執(zhí)行相同的更新。然后封鎖并等待主服務(wù)器通知新的更新。從服務(wù)器執(zhí)行備份不會干擾主服務(wù)器，在備份過程中主服務(wù)器可以繼續(xù)處理更新。
1、主數(shù)據(jù)庫出現(xiàn)問題，可以切換到從數(shù)據(jù)庫。
2、可以進行數(shù)據(jù)庫層面的讀寫分離。
3、可以在從數(shù)據(jù)庫上進行日常備份。
Binary log：主數(shù)據(jù)庫的二進制日志。
Relay log：從服務(wù)器的中繼日志。
第一步：master在每個事務(wù)更新數(shù)據(jù)完成之前，將該操作記錄串行地寫入到binlog文件中。
第二步：salve開啟一個I/O Thread，該線程在master打開一個普通連接，主要工作是binlog dump process。如果讀取的進度已經(jīng)跟上了master，就進入睡眠狀態(tài)并等待master產(chǎn)生新的事件。I/O線程最終的目的是將這些事件寫入到中繼日志中。
第三步：SQL Thread會讀取中繼日志，并順序執(zhí)行該日志中的SQL事件，從而與主數(shù)據(jù)庫中的數(shù)據(jù)保持一致。
我是在同一個windows上不同的路徑下安裝兩個msyql實例。建議這里主從兩個mysql的安裝版本一致，盡管我自己的是不一致的。
1、分別修改主從數(shù)據(jù)庫的配置文件my.ini
master
3306是mysql默認(rèn)端口號，這里master實例中可以不用修改；server-id用來指定唯一id，不同的mysql實例不重復(fù)即可；binlog-do-db指定需要復(fù)制的數(shù)據(jù)庫；log-bin用來開啟二進制日志文件。
salve
由于主從數(shù)據(jù)庫待會兒都是在通一臺電腦上運行，所以端口需要設(shè)置成不一樣，這里是3307
replicate-do-db：需要同步的數(shù)據(jù)庫名稱，與master上的配置保持一致。
2、在master上創(chuàng)建一個專門用于復(fù)制的賬戶：weidai/123456
這個新增的賬戶可以在表mysql.user中進行查詢：
我第一次操作的時候，到這里就完成了這個賬號的創(chuàng)建，但是到真正復(fù)制的時候，卻發(fā)現(xiàn)復(fù)制沒有成功，排查錯誤的時候發(fā)現(xiàn)master生成的binlong沒有問題，然后查看slave的狀態(tài)：
在結(jié)尾處有這樣一行錯誤：
使用weidai這個賬號無法連接到master，所以應(yīng)該是沒有獲取到master的binlog，導(dǎo)致中繼日志無法生成。
我反復(fù)檢查了賬號和密碼都沒有發(fā)現(xiàn)問題，然后查找相關(guān)資料，才發(fā)現(xiàn)是因為在master創(chuàng)建新用戶的時候少了一步操作：
新設(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ù)的起始位置，但是在獲取這個狀態(tài)值之前，主數(shù)據(jù)庫就不能再有數(shù)據(jù)的修改操作，所以需要先設(shè)置讀鎖定有效
4、主庫進行數(shù)據(jù)備份，備份的手段有很多種，這里不展開介紹，可以參考我上一篇文章，備份結(jié)束后可以釋放讀鎖，主庫就可以進行寫操作
5、啟動從數(shù)據(jù)庫，對剛才備份的數(shù)據(jù)進行還原，這個時候主從數(shù)據(jù)庫在備份那個時間點的數(shù)據(jù)是一致的。
6、在從數(shù)據(jù)庫上進行復(fù)制行為的相關(guān)配置
7、這個時候配置完成，但是從數(shù)據(jù)庫還不能進行同步，需要啟動slave線程
8、在master中創(chuàng)建表和新增數(shù)據(jù)，在slave中觀察：
可以看出，我在master中進行的操作，都能在slave中體現(xiàn)出來，這個時候slave就如同是master的鏡子一樣。
五、主從同步狀態(tài)解讀
在slave上使用命令進行查看：
由于排版太過于難看，我整理如下：
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
這兩個線程前面有提到，是slave上參與復(fù)制過程中兩個很重要的線程。YES表示正常，NO表示異常。
Slave_IO線程主要是將master上的binlong日志內(nèi)容復(fù)制到slave的中繼日志中（Relay_log），一般出現(xiàn)問題的概率不大， 出現(xiàn)問題大多數(shù)是因為權(quán)限或者網(wǎng)絡(luò)等問題，導(dǎo)致連接不上master。如同前面提到的那個錯誤。
Slave_SQL線程負(fù)責(zé)將中繼日志中的SQL執(zhí)行一遍，相對來說出錯的概率大些。如有人手動的在從庫中插入一些記錄，導(dǎo)致主從同步的時候出現(xiàn)主鍵沖突。
Slave_IO_STATE:Waiting for master to send event—這個狀態(tài)表示中繼日志同步完成，等待master有新的事件產(chǎn)生。
轉(zhuǎn)自：微信公眾號-java知音
