一、mysql 主從複製

1.主從形式

mysql主從複製 靈活

• 一主一從
• 主主複製
• 一主多從---擴充套件系統讀取的效能，因為讀是在從庫讀取的；
• 多主一從---5.7開始支援
• 聯級複製---

2.主從複製的用途及部署條件

mysql主從複製用途

• 實時災備，用於故障切換
• 讀寫分離，提供查詢服務
• 備份，避免影響業務

主從部署必要條件：

• 主庫開啟binlog日誌（設定log-bin引數）
• 主從server-id不同
• 從庫伺服器能連通主庫

3.主從原理

mysql主從複製的原理

其通過三個執行緒來完成，在master節點上執行的binlogdump執行緒以及在slave節點上執行的I/O執行緒和SQL執行緒。 1. master節點上的binlogdump執行緒，在slave與其正常連線的情況下，將binlog傳送到slave上。 2.slave節點上的I/O執行緒，通過讀取master節點發送的內容，並將資料複製到本地的relaylog中。 3.slave節點上的SQL執行緒，讀取relaylog中的日誌，並解析成具體操作，來實現主從的操作一致，而最終資料一致；

二、主從複製--非同步複製

實驗環境：

Mysql5.7版

linux系統版本：Redhat 6.5版

系統防火牆關閉

server2:(Master)

server3:(Slave)

1.master和 slave 資料庫的搭建

安裝以下軟體包

mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-devel-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm

2.master 的部署

[[email protected] ~]# vim /etc/my.cnf

server-id=1
log-bin=mysql-bin

server-id 為伺服器的預設id ,master 和 slave 不能相同，只要是整數即可

log-bin 表示二進位制日誌

[[email protected] ~]# /etc/init.d/mysqld start

在日誌裡查詢資料庫的原始密碼

[[email protected] ~]# mysql_secure_installation    初始化資料庫，並設定新密碼

密碼格式為：字母大小寫+符號+數字 (大於8位）

檢視資料庫是否搭建成功

[[email protected] ~]# mysql -p  

可以檢視master 的id

授權slave 以 repl 的身份從master的網段登陸，密碼為自己設定的mysql 密碼

mysql> grant replication slave on *.* to [email protected]'172.25.254.%' identified by 'WESTOS.com123';

授權後檢視 master id  會發生變化

3.slave 的部署

測試剛才master的授權是否成功

登陸密碼為授權的密碼

測試後要退出mysql

[[email protected] ~]# vim /etc/my.cnf

server-id =2  

[[email protected] ~]# /etc/init.d/mysqld start

[[email protected] ~]# grep password /var/log/mysqld.log   檢視初始密碼 2018-09-28T01:39:56.901926Z 1 [Note] A temporary password is generated for [email protected]: GwrgWQ0o=0ak

[[email protected] ~]# mysql_secure_installation   初始化資料庫，設定mysql密碼

[[email protected] ~]# mysql -p

開啟selave 並檢視其狀態

若io 執行緒和sql 執行緒都已開啟，則表示成功

4.測試是否同步

在master 中

建立一個庫和表，並在表裡寫入資料

在selave 中檢視是否有master 中所建立的資料

證明mysql 的同步複製成功

三、基於GTID的同步複製

1.GTID工作原理

• master更新資料時，會在事務前產生GTID，一同記錄到binlog日誌中。
• slave端的i/o 執行緒將變更的binlog，寫入到本地的relay log中。
• sql執行緒從relay log中獲取GTID，然後對比slave端的binlog是否有記錄。
• 如果有記錄，說明該GTID的事務已經執行，slave會忽略。
• 如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。
• 在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。

2. GTID的優點：

• 一個事務對應一個唯一ID，一個GTID在一個伺服器上只會執行一次
• GTID是用來代替傳統複製的方法，GTID複製與普通複製模式的最大不同就是不需要指定二進位制檔名和位置
• 減少手工干預和降低服務故障時間，當主機掛了之後通過軟體從眾多的備機中提升一臺備機為主機

3.同步部署

1）在master 和 selave 中的/etc/my.cnf同時新增引數

vim /etc/my.cnf

表示開啟gtid模組

/etc/init.d/mysqld restart

2）在selave 中

4.測試

在master 中

進入所建立的庫中，在其所建立的表中寫入資料

在selave 中 檢視是否同步資料

資料完全一致，說明搭建成功

四、半同步複製

非同步複製即是master資料庫把binlog日誌傳送給slave資料庫，然後就沒有了然後了。在此暴露一個問題，當slave伺服器發生故障了，那麼肯定會導致主從資料庫伺服器的資料不一致。

　　為了解決上面的問題，MySQL5.5以上引入一種叫做半同步複製模式。開啟這種模式，可以保證slave資料庫接收完master資料庫傳送過來的binlog日誌並寫入自己的中繼日誌中，然後反饋給master資料庫，告知已經複製完畢。

　　開啟這種模式後，當出現超時，主資料庫將會自動轉為非同步複製模式，直到至少有一臺從伺服器接受到主資料庫的binlog，並且反饋給主資料庫。這時主資料庫才會切換回半同步複製模式。

1.master 部署

部署半同步模組 安裝外掛

設定臨時同步

永久設定同步

vim /etc/my.cnf  設定變數，啟用半同步複製

/etc/init.d/mysqld restart

2.在selave 中 安裝外掛

設定變數 啟用半同步模式

重新連線主伺服器（半同步才會生效）

3.master 上檢視是否啟用了半同步

主要看 Rpl_semi_sync_master_clients 是否為1，

Rpl_semi_sync_master_status               是否為ON  

若符合則表示半同步複製機制已經正常工作，如果Rpl_semi_sync_master_status   為OFF，說明出現了網路延遲或selave io 執行緒延遲

4.測試

slave上關閉io_thread

然後在master上執行資料庫操作，比如插入等，結果就是操作會等待10s返回結果，這時候退回非同步複製，slave上沒有接收到資料，這時候我們去檢視master上的相關狀態：

在 master 上建立資料

此時插入資料會有一個10s的timeout，所以會卡頓一會，有些引數的值也變了：

在selave 中檢視是否同步

在selave 開啟io_thread再去檢視資料庫的變化，發現數據同步了

五、並行複製

1.並行複製的簡介

• 一般主從複製，有三個執行緒參與，都是單執行緒：Binlog Dump（主） —–>IO Thread （從） —–> SQL Thread（從）。複製出現延遲一般出在兩個地方 1）SQL執行緒忙不過來（可能需要應用資料量較大，可能和從庫本身的一些操作有鎖和資源的衝突；主庫可以併發寫，SQL執行緒不可以；主要原因） 2）網路抖動導致IO執行緒複製延遲（次要原因）。 　　MySQL從5.6開始有了SQL Thread多個的概念，可以併發還原資料，即並行複製技術。
• MySQL5.6中，設定引數slave_parallel_workers=4(>1)，即可有4個SQL Thread（coordinator執行緒）來進行並行複製，其狀態為：Waiting for an evant from Coordinator。 但是其並行只是基於Schema的，也就是基於庫的。如果資料庫例項中存在多個Schema，這樣設定對於Slave複製的速度可以有比較大的提升。通常情況下單庫多表是更常見的一種情形， 那基於庫的併發就沒有卵用。其核心思想是：不同schema下的表併發提交時的資料不會相互影響，即slave節點可以用對relay log中不同的schema各分配一個類似SQL功能的執行緒，來重放relay log中主庫已經提交的事務，保持資料與主庫一致。
• 在MySQL 5.7中，引入了基於組提交的並行複製（Enhanced Multi-threaded Slaves），設定引數slave_parallel_workers>0並且global.slave_parallel_type＝‘LOGICAL_CLOCK’，即可支援一個schema下，slave_parallel_workers個的worker執行緒併發執行relay log中主庫提交的事務。其核心思想：一個組提交的事務都是可以並行回放（配合binary log group commit）； slave機器的relay log中 last_committed相同的事務（sequence_num不同）可以併發執行。 其中，變數slave-parallel-type可以有兩個值：DATABASE 預設值，基於庫的並行複製方式；LOGICAL_CLOCK：基於組提交的並行複製方式

2. 部署

新增一臺selave (server4)

1)在 第一臺 selave 上

vim /etc/my.cnf

/etc/init.d/mysqld restart

2)部署新的selave

安裝mysql

mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-devel-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm

vim /etc/my.cnf

server-id=3

/etc/init.d/mysqld  start

[[email protected] mysql]# grep password /var/log/mysqld.log

[[email protected] mysql]# mysql_secure_installation

3）在第一臺 selave 上

4）在新的selave 中測試授權是否成功

5)在master 中

vim /etc/my.cnf

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=16

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

/etc/init.d/muysqld restart

將庫的內容匯入到westos.sql檔案中，並傳到server4上

[[email protected] ~]# mysqldump -p westos > westos.sql

[[email protected] ~]# scp westos.sql server4:

6）在新slave 中

因為server4中沒有westos庫，在檔案中先建立庫

[[email protected] ~]# vim westos.sql

恢復westos庫

[[email protected] ~]# mysql -p < westos.sql

3.測試

在master 中寫入資料

在server3（selave）中檢視是否同步

在server4(selave)中檢視是否同步

兩臺selave都同步了master的資料，說明達到了並行複製的效果