環境：

實驗環境：
rhel6.5 , selinux和iptables均為disabled狀態，mysql均為5.7.17，或者slave比master版本高
實驗主機：
172.25.254.2 server2:master
172.25.254.3 server3:slave

一.mysql主從複製

*1*mysql主從複製原理:
1.從庫生成兩個執行緒，一個i/o執行緒，一個SQL執行緒
2.i/o執行緒去請求主庫的binlog，並且得到的binlog日誌寫道relay log(中繼日誌)檔案中
3.主庫會生成一個log dump執行緒，用來給從庫的i/o執行緒傳binlog
4.SQL執行緒，會讀取中繼日誌檔案，並解析成具體的操作執行，這樣主從的操作就一致了，而最終的資料也就一直存在了
*2*主從複製用途及條件
1.實時災備，用於故障切換
2.讀寫分離，提供查詢服務
3.備份，避免影響業務
*3*主從部署的必要條件
1.主庫可誒其binlog日誌（設定log-bin引數）
2.主從server-id不同
3.從庫伺服器能連線到主庫
*4*主從複製存在的問題及解決方法
問題：
1.主機宕機之後，資料可能會丟失
2.從庫只有一個sql Thread,主庫寫壓力大，複製很可能會延時
解決方法：
1.半同步複製解決--解決資料丟失的問題
2.並行複製--解決從庫複製延時的問題
&&主從複製分類：
主從複製分為同步複製和非同步複製
1.非同步複製：非同步複製意味著在把資料從一臺機器拷貝到另一臺機器時有一個延時，最重要的是這意味著當應用系統的事務提交已經確認時資料並不能在同一時刻拷貝（應用）到從機。通常這個延時是由網路寬頻、資源可用性和系統負載決定的，然而使用正確的元件並且調優，複製能做到接近瞬間完成。
2.同步複製：同步複製可以定義為資料在同一時可被提交到一臺或多臺機器，通常這是通過眾所周知的“兩階段提交”做到的。雖然這確定給你在多系統中保持一致性，但也由於增加了額外的訊息交換而造成效能下降。
（本次實驗只介紹非同步複製）
主從複製中非同步複製的工作原理：
在主節點上執行完命令後生成一個日誌檔案，然後將日誌檔案傳送給從節點，最後提交，從節點收到日誌檔案後，開始同步裡面的資料（事物），最後得到與主節點一致的資料
實驗過程：
在兩臺主機上安裝服務

在server2上

下載安裝包，並進行解壓與安裝

改寫配置檔案

vim /etc/my.cnf

server-id=1  

/etc/init.d/mysqld start  ##開啟服務

grep password /var/log/mysql.log   ##檢視mysql的初始密碼

mysql_secure_installation   ##修改密碼，本實驗中修改密碼為Zhang+007

mysql -p    ##登陸資料庫，確保密碼修改正確

在server3上

下載並安裝資料庫所需包（與server2一致）

解壓並下載

server3也需要更改密碼，登陸mysql，檢測是否成功

mysql_secure_installation  ##更改密碼，本實驗中更改密碼為westos

mysql -p   ##登陸，檢查是否更改成功

然後編寫檔案

在server2上

grant replication slave on *.* to [email protected]'172.25.254.%' identified by 'Zhang+007'  ##設定slave,且設定master（即server2）名稱為zhang ,密碼為Zhang+007

在server3上mysql -u zhang -p -h 172.25.254.2   ##zhang為master名稱，172.25.254.2為master的ip

然後在server3上，mysql -p  登陸自己的資料庫

start slave;     ##開啟slave (若slave開啟報錯，則要SHOW VARIBLES LIKE 'server_id',檢視Value值是否為當初設定的server_id的值，若不是，則說明還不能同步)

（若要重置slave或master,則先stop slave,然後reset slave）

show slave status\G;    ##檢視slave資訊

若 Slave_IO_Running:YES 並且Slave_SQL_Rrunning:YES,則說明master和slave可以同步資料庫資料

測試：

在server2上重新新增資料

在server3上就會同步過來

二：基於GTID模式

1.概念：GTID（Global Transaction Identifier）稱為全域性事務標示符， 是由mysql伺服器自動管理的在原始master上提交事務時被建立。 GTID需要在全域性的主-備拓撲結構 中保持唯一性，每一個 GTID 代表一個數據庫事務。 GTID由兩部分組成： GTID = source_id：transaction_id source_id： 用於標示源伺服器，用server_uuid來表示 transaction_id： 則是根據在源伺服器上第幾個提交的事務來確定。 transaction_id 是一個從 1 開始的自增計數，表示在這個主庫上執行的第 n 個事務。 MySQL 會保證事務與 GTID 之間的 1 : 1 對映。 工作原理：前面在slave端配置，進行change master to操作時， 使用的是日誌號(指定position），當master端的服務down掉了， 就會在slave端選擇一個日誌號與原來的master最接 近的作為master， 但是，在另一個slave上，並沒有指定新的master的資訊， 因此還要手動去指定，而使用gtid的話，slave通過尋找 next的值， 並不用指定master的二進位制日誌檔案和日誌號，所以使用gtid更能保證資料的完整性。

1.在server2上，編寫檔案

重新啟動服務

2.在server3中編寫檔案，並重啟服務

在server3中，登陸資料庫，修改引數，檢視slave

測試：

在server2中，刪除某些資料

則在server3中，就會發現資料同步更新了

三：半同步複製（修改IO執行緒）

MySQL預設的複製即是非同步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主機如果crash掉了，此時主機上已經提交的事務可能並沒有傳到從機上，如果此時，強行將從機提升為主機，可能導致新主機上的資料不完整。

指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步複製的效能必然會收到嚴重的影響。

介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於非同步複製，半同步複製提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步複製最好在低延時的網路中使用。  

io執行緒是slave中主要負責將master傳過來的資料存放在relay log中的執行緒，relay log是不斷追加內容的。

半同步原理：master和slave本來是非同步複製，這樣有可能造成兩邊資料不一致，因為master只負責傳資料給slave，而半同步則時在一定時間段中，master傳完資料後就會等待slave的迴應，這樣資料一致性的可能性會更大，若在這段時間段內，master收不到slave的迴應，那麼會由半同步變為非同步。

其中半同步在master中表示為'semi_sync',在slave中表示為'semi'

在master中：設定半同步複製,設定引數，檢視半同步狀態

在slave中 ：設定半同步複製，設定引數，檢視半同步狀態

show status like '%rpl%';      ##顯示半同步複製狀態

在master中，新增資料，以便檢測

show status like '%semi_sync%';     ##檢視semi狀態

其中rpl_semi_sync_master_yes_tx     ##使用半同步成功的次數，資料一致性能提高

其中rpl_semi_sync_master_no_tx   ##使用半同步失敗的次數，10s後沒有得到反饋資訊，則會轉為非同步複製

在slave中

關閉半同步複製

在master中，當把從機的I/O執行緒關掉後，主資料庫在進行對複製資料庫的庫進行更改時，再進行操作會等待10s，增加了一次半同步傳輸的失敗次數

並行複製（修改sql執行緒）：

sql是slave中回放日誌的單執行緒。

mysql中的時間延遲原因有兩個，在slave中，有io執行緒的非同步複製和sql單執行緒，一個mysql只有一個sql執行緒，故如果再多加sql執行緒，對mysql一點作用都沒有，好在，可以實現對mysql中的組進行並行複製，在5.7版本中，提高了80%速度。

在slave(server3)中，編寫配置檔案，並重啟服務

vim /etc/mycnf

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=16     ##設定的執行緒為16個執行緒

master_info_repository=TABLE   ##更新原master_info檔案，提高50%-80%的速度

relay_log_info_repository=TABLE

relay_log_recovery=ON

進入slav的mysql,檢視processlist,會發現有16個執行緒在工作

不管是在slave或是master中，show processlist 都可以檢視到現在所有程序的狀態

其中 slave has read all relay log;waitingfor more updates ##顯示的是sql執行緒的狀態

其中waiting for master to send event   ##顯示的是io執行緒的狀態