實驗環境：rhel7.3 selinux and firewalld disabled

主機環境：

• 主庫端： server3:172.25.19.3
• 從庫端： server4:172.25.19.4

一、mysql5.7主從復制

• 主從復制的要求：
  （1）主庫開啟binlog日志（設置log-bin參數）
  （2）主從server-id不同
  （3）從庫服務器能連同主庫

• 主從復制原理：
  　　mysql的主從配置又叫replication，AB復制，基于binlog二進制日志，主數據庫必須開啟binlog二進制日志才能進行復制。

（1）主數據庫將更改操作記錄到binlog二進制日志（主數據庫有log dump線程和從數據庫的i/o線程傳遞binlog）。
（2）從庫生成兩個線程，一個i/o線程，一個SQL線程
（3）i/o線程去請求主庫的binlog，并且得到的binlog日志寫到relay log(中繼日志)文件中
（4）然后主庫會生成一個log dump線程，用來給從庫的i/o線程傳binlog；SQL線程，會讀取中繼日志文件，并解析成具體的操作執行，這樣主從的操作就一致了，而最終的數據也就一致了。
　　作為異步復制，其主庫將事件寫入binlog二進制文件，dump線程將binlog文件發送出去，不保證其他從節點是否會收到binlog二進制文件。

• 部署過程：

配置主庫端：
1.在主庫中安裝mysql

[root@server3 ~]# ls
mysql-community-client-5.7.24-1.el7.x86_64.rpm 
mysql-community-common-5.7.24-1.el7.x86_64.rpm 
mysql-community-libs-5.7.24-1.el7.x86_64.rpm 
mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm 
mysql-community-server-5.7.24-1.el7.x86_64.rpm
[root@server3 ~]# yum install *

2.打開數據庫

[root@server3 ~]# systemctl start mysqld

3.查看密碼

[root@server3 ~]# cat /var/log/mysqld.log | grep password
 ![在這里插入圖片描述](https://img-blog.csdnimg.cn/20190225094744512.png)

4.進行初始化，修改密碼否則進入數據庫也無法操作

• 注意：密碼需要有數字 大小寫字母 特殊字符 三者構成 缺一不可！ 密碼位數大于8

[root@server3 ~]# mysql_secure_installation 

Securing the MySQL server deployment.

Enter password for user root:   ##剛才找出的密碼

The existing password for the user account root has expired. Please set a new password.      ##設置新的密碼

New password: 

Re-enter new password: 
The 'validate_password' plugin is installed on the server.
The subsequent steps will run with the existing configuration
of the plugin.
Using existing password for root.

Estimated strength of the password: 100 
Change the password for root ? ((Press y|Y for Yes, any other key for No) : 

Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.
Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.
Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.

All done! 

5. 編輯配置文件

[root@server3 ~]# vim /etc/my.cnf
最后面添加：
 29 log-bin=mysql-bin     ##開啟二進制日志
 30 server-id=1           服務器ID

6. 重啟服務，則配置文件生效

[root@server3 ~]# systemctl restart mysqld

7. 創建用戶并授權
   
   參數解釋：
   replication 　　　表示授權復制的權限　　
*.* 　　　　　　　　表示所有數據庫可以進行同步　
Hui 　　　　 　　　表示授權名，可以隨意填寫　
'172.25.19.%' 　　表示授權172.25.19.0/24的網段所有服務器可以同步， %表示任意

• 查看二進制日志是否打開
  
• 查看主庫的狀態
  
  配置從庫端：

1. 安裝mysql

[root@server4 ~]# ls
mysql-community-client-5.7.24-1.el7.x86_64.rpm 
mysql-community-common-5.7.24-1.el7.x86_64.rpm 
mysql-community-libs-5.7.24-1.el7.x86_64.rpm 
mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm 
mysql-community-server-5.7.24-1.el7.x86_64.rpm　

2. 能夠登陸視為授權成功

[root@server4 ~]# mysql -u hui -p -h 172.25.19.3

3. 打開mysql

[root@server4 ~]# systemctl start mysqld

4. 查看密碼

[root@server4 ~]# cat /var/log/mysqld.log | grep password

5. 初始化，和主庫端一樣

[root@server4 ~]# mysql_secure_installation 同3

6. 編寫配置文件

[root@server4 ~]# vim /etc/my.cnf
 29 server-id=2          ##填寫server-id和主端不同即可

7. 重啟服務

[root@server4 ~]# systemctl restart mysqld

8. 設定從設備并開啟從設備

• 注意：master_log_file 和master_log_pos 的值都要依照主設備狀態中的值來設定，因為會變化
  
  

測試：

1. 在主庫端創建庫，創建表，并插入數據
   
   
   

• 注意：主庫的狀態信息中的Position 一直在變更
  

2. 在從庫中查看是否復制到 （可以查到代表復制成功）
   
   

二、基于GDIT主從復制

• mysql數據庫從5.6.5開始新增一種基于GDIT的復制方式。GTID (Global Transaction ID) 是對于一個已提交事務的編號，并且是一個全局唯一的編號。 GTID 實際上 是由 UUID+TID 組成的。其中 UUID 是一個 MySQL 實例的唯一標識。

• 主從復制,默認是通過pos復制(postion),就是說在日志文檔里,將用戶進行的每一項操作都進行編號(pos),每一個event都有一個起始編號,一個終止編號,我們在配置主從復制時從節點時,要輸入master的log_pos值就是這個原因,要求它從哪個pos開始同步數據庫里的數據,這也是傳統復制技術。

• MySQL5.6增加了GTID復制,GTID就是類似于pos的一個作用,不過它是整個mysql復制架構全局通用的,就是說在這整個mysql冗余架構中,它們的日志文件里事件的GTID值是一致的.

• GTID (Global Transaction ID) 是對于一個已提交事務的編號，并且是一個全局唯一的編號。 GTID 實際上 是由 UUID+TID 組成的。其中 UUID 是一個 MySQL 實例的唯一標識。TID 代表了該實例上已經提交的事務數量，并且隨著事務提交單調遞增。

• 通過GDIT保證每個主庫上提交的事務在集群中有一個唯一的ID.這種方式強化了數據庫的主備一致性，故障恢復以及容錯能力。

pos與GTID有什么區別?

• 兩者都是日志文件里事件的一個標志,如果將整個mysql集群看作一個整體,pos就是局部的,GTID就是全局的.

部署過程：

1.主從端都修改配置文件

[root@server3 ~]# vim /etc/my.cnf
 32 gtid_mode=ON            開啟gtid模式
 33 enforce-gtid-consistency=true    強制gtid一直性，用于保證啟動gitd后事務的安全

[root@server4 ~]# vim /etc/my.cnf
 32 gtid_mode=ON      
 33 enforce-gtid-consistency=true

2. 主從端都重啟服務

[root@server3 ~]# systemctl restart mysqld
[root@server4 ~]# systemctl restart mysqld

3. 在從庫端先停掉slave，然后重新創建連接

• 如果進行change master to時使用MASTER_AUTO_POSITION = 1， slave連接master將使用基于GTID的復制協議。
  
  

測試：

1. 在主庫表中添加新的信息
   

2. 從庫查看是否復制成功
   
   以上，同步成功

三、基于GDIT的半同步

• MySQL默認的復制即是異步的，主庫在執行完客戶端提交的事務后會立即將結果返給給客戶端，并不關心從庫是否已經接收并處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能并沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數據不完整。
• 半同步復制就是為了解決數據丟失的問題。

部署過程：

1.主庫安裝服務插件，并且開啟半同步復制

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.35 sec)

mysql> set global rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.01 sec)

mysql> select plugin_name,plugin_status
    -> from information_schema.plugins
    -> where plugin_name like '%semi%';
+----------------------+---------------+
| plugin_name          | plugin_status |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+
1 row in set (0.00 sec)

mysql> show variables like '%semi%';    #環境變量
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
| rpl_semi_sync_master_timeout              | 10000      |     ## ##默認10000毫秒（10秒），生產環境中建議設置為無窮大
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.00 sec)

mysql> show status like '%rpl_semi_sync%';   #狀態變量
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 0     |
| Rpl_semi_sync_master_net_avg_wait_time     | 0     |
| Rpl_semi_sync_master_net_wait_time         | 0     |
| Rpl_semi_sync_master_net_waits             | 0     |
| Rpl_semi_sync_master_no_times              | 0     |
| Rpl_semi_sync_master_no_tx                 | 0     |
| Rpl_semi_sync_master_status                | ON    |
| Rpl_semi_sync_master_timefunc_failures     | 0     |
| Rpl_semi_sync_master_tx_avg_wait_time      | 0     |
| Rpl_semi_sync_master_tx_wait_time          | 0     |
| Rpl_semi_sync_master_tx_waits              | 0     |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
| Rpl_semi_sync_master_wait_sessions         | 0     |
| Rpl_semi_sync_master_yes_tx                | 0     |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)

2. 在從端也安裝插件，開啟半同步復制

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.10 sec)

mysql> set global rpl_semi_sync_slave_enabled=ON;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%semi%';    
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | ON    |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.00 sec)

- 注意：要重啟從上的IO線程,如果沒有重啟，則默認還是異步復制，重啟后，slave會在master上注冊為半同步復制的slave角色

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.35 sec)

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

測試： 半同步失敗的情況

1. 先測試一個沒有通過半同步復制的

• 從端關掉IO線程：

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.63 sec)

• 再在主端表中插入數據，會等待10秒中,10s后會變為異步復制

mysql> use westos;

mysql> insert into userlist values ('user5','555');
Query OK, 1 row affected (10.38 sec)

• 此時在主端發現半同步失敗次數+1
  （1）Rpl_semi_sync_master_no_tx
  表示沒有成功接收slave提交的次數，也就是使用半同步失敗的次數，10s后沒有得到反饋信息，會轉為異步復制
  （2）Rpl_semi_sync_master_yes_tx
  使用半同步成功的次數，數據的一致性能提高

• 然后從端會發現沒有同步過來，再次打開IO線程后，數據才能同步過來，此時復制過來的是異步復制的結果

測試2：半同步正常情況

• 從端打開IO：

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

• 主端插入新數據：

mysql> use westos;
Database changed
mysql> insert into userlist values ('user6','666');
Query OK, 1 row affected (0.53 sec)

mysql> show status like '%rpl%';  ##發現Rpl_semi_sync_master_yes_tx 變為1，成功了一次

• 從端驗證同步結果：

##user6用戶信息被成功復制到
mysql> select * from userlist;
+----------+----------+
| username | password |
+----------+----------+
| user1    | 123      |
| user2    | 356      |
| user3    | 789      |
| user4    | 444      |
| user5    | 555      |
| user6    | 666      |
+----------+----------+
6 rows in set (0.00 sec)

四、MySQL5.7基于組提交的并行復制

并行復制的原理：

• 在普通的主從復制架構中，slave服務器上有兩個線程：IO線程和SQL線程。IO線程負責接收master的二進制日志（準確的說是二進制日志的event），SQL線程負責應用二進制日志（準確的說是relay-log）。
• 在MySQL5.6版本中的并行復制中（需開啟并行復制功能），SQL線程變為coordinator線程，判斷是否可以并發執行：
  • 如可以并行執行，選擇worker線程執行二進制日志
  • 如不可并行執行，是DDL或是跨schema的操作，則等待所有的worker線程執行完成之后再執行當前日志
• coordinator線程不僅僅可以將日志發送給worker線程，也可以回放日志，但是并行的操作都會交給worker線程來完成
• 5.7中引入了slave-parallel-type參數，用來控制并發復制的方式，可用的值為DATABASE和LOGICAL_CLOCK
  • DATABASE：默認值，基于庫的并行復制方式
  • LOGICAL_CLOCK：基于組提交的并行復制方式（LOGICAL_CLOCK是一個全局遞增的64位長整型數字，主要通過它來判斷哪些事務能夠并發）

并行復制：解決延遲的問題
如何判斷延遲：

• show master status\G
  （1）Seconds_Behind_Master: 0 ##數字0代表沒有延遲
  （2）對比一下后面的數字是否一樣，一樣則沒有延遲
  Read_Master_Log_Pos: 2664
  Exec_Master_Log_Pos: 2664

配置：只需要在slave上設置

1. 編寫配置文件

[root@server4 ~]# vim /etc/my.cnf

 34 slave-parallel-type=LOGICAL_CLOCK     基于組提交的并行復制方式 
 35 slave-parallel-workers=5             
 36 master_info_repository=TABLE        以表的形式記錄，如果是file（默認），則會進行刷盤的動作，對mysql的性能會有很大的影響
 37 relay_log_info_repository=TABLE
 38 relay_log_recovery=ON       開啟日至恢復

• slave-parallel-workers=5
  開啟5個線程，如果設置為0，則退化成原來的單線程，如果設置為1，則SQL線程功能轉化為coordinator線程，但是只有一個worker線程回放（也就是單線程復制），但是因為多了一次coordinator線程的轉化，因此=1的性能反而比=0的還差。

2. 重啟服務

[root@server4 ~]# systemctl restart mysqld

3. 查看工作進程

mysql> show tables;
mysql> select * from slave_master_info;
mysql> select * from slave_relay_log_info
mysql> show processlist;            ##就發現有5個worker進程