1.最簡單的AB主從復制

• MySQL之間數據復制的基礎是二進制日志文件（binary log file）。一臺MySQL數據庫一旦啟用二進制日志后，其作為master，它的數據庫中所有操作都會以“事件”的方式記錄在二進制日志中，其他數據庫作為slave通過一個I/O線程與主服務器保持通信，并監控master的二進制日志文件的變化，如果發現master二進制日志文件發生變化，則會把變化復制到自己的中繼日志中，然后slave的一個SQL線程會把相關的“事件”執行到自己的數據庫中，以此實現從數據庫和主數據庫的一致性，也就實現了主從復制。

拓撲

 rhel6.5系統
 master:172.25.25.5
 slave:172.25.25.6
 mysql 版本：5.7.17-1.el6.x86_64

在master與slave節點都進行數據庫的安裝

1. master的配置

1. 編輯配置文件

 [root@server5 mnt]# vim /etc/my.cnf
 內容如下：
 [mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock

 # Disabling symbolic-links is recommended to prevent assorted security risks
 symbolic-links=0
 server-id=1 # 必須為 1 到 232–1 之間的一個正整數值
 log-bin=mysql-bin  # 啟動二進制日志系統
 # binlog-do-db=""
 # 二進制需要同步的數據庫名,如果需要同步多個庫,例如要再同步 halo庫,再添加一行“binlog-do-db=halo”,以此類推 
 # binlog-ignore-db="" # 禁止同步的數據庫

 編輯完成重啟服務
 [root@server5 mnt]# /etc/init.d/mysqld restart

執行如下：

2. 進行數據庫配置

創建授權用戶并查看master狀態
登錄數據庫，并進行如下操作：

 mysql> grant replication slave on *.* to bleach@'172.25.25.%' identified by 'Redhat_123';
        # 建立授權用戶
 mysql> Flush privileges;

 mysql> show master status;
        # 查看master狀態 
 +------------------+----------+--------------+------------------+-------------------+
 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set |
 +------------------+----------+--------------+------------------+-------------------+
 | mysql-bin.000003 |     1157 |              |                   |                   |
 +------------------+----------+--------------+------------------+-------------------+
 記住file 與 position，再對slave進行操作時需要用到

2. slave的配置

1. 編輯配置文件

 [root@server6 ~]# vim /etc/my.cnf
 添加如下內容即可:
 server-id=2

 添加完成重啟服務

2. 進行數據庫配置

為slave添加master

 登錄數據庫后執行如下：
 mysql> change master to master_host='172.25.25.5',
      > master_user='bleach',    # 授權用戶
      > master_password='Redhat_123',   # 授權用戶的密碼
      > master_log_file='mysql-bin.000003',  # master的二進制文件
      > master_log_pos=1157;
 mysql> start slave; # 啟動slave
 mysql> show slave status\G   # 查看slave狀態
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.25.25.5
                  Master_User: bleach
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 1157
               Relay_Log_File: server6-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes     #  yes 表示連接上
            Slave_SQL_Running: Yes     #  yes 表示連接上

slave上要開啟read_only，只讀，不然可能會因為不小心的操作導致數據不一致以及主從復制出現問題
這樣最簡單的mysql AB 主從復制就建立成功

3. 進行測試

在主庫進行新建數據庫與表的操作，可在從庫中看到相同的信息

 master 下執行：
 mysql> create database test;

slave中：

2.Mysql 基于GTID的主從復制

• GTID即全局事務ID（global transaction identifier），GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標識。TID代表了該實例上已經提交的事務數量，并且隨著事務提交單調遞增，所以GTID能夠保證每個MySQL實例事務的執行（不會重復執行同一個事務，并且會補全沒有執行的事務）。下面是一個GTID的具體形式：
  4e659069-3cd8-11e5-9a49-001c4270714e:1-77
  通過GTID來進行主從復制，不用進行二進制日志與master POS號的設定

基本環境與上述AB式復制相同，需要全新的實驗環境

 master:server5:172.25.25.5
 slave:server6:172.25.25.6

1. master的配置

1. 編輯配置文件

修改配置文件，添加GTID相關參數
 [root@server5 mnt]# vim /etc/my.cnf
 內容如下：
 [mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock

 # Disabling symbolic-links is recommended to prevent assorted security risks
 symbolic-links=0
 server-id=1 # 必須為 1 到 232–1 之間的一個正整數值
 log-bin=mysql-bin  # 啟動二進制日志系統
 gtid-mode=on   # 開啟GTID模式
 enforce-gtid-consistency=1

修改完成后，重啟數據庫服務

2. 進行數據庫操作

在數據庫中執行如下操作：

 mysql> grant replication slave on *.* to bleach@'172.25.25.%' identified by 'Redhat_123';
 Query OK, 0 rows affected, 1 warning (0.37 sec)

 mysql> Flush privileges;
 Query OK, 0 rows affected (0.13 sec)

 mysql> show master status;
 +------------------+----------+--------------+------------------+------------------------------------------+
 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set                        |
 +------------------+----------+--------------+------------------+------------------------------------------+
 | mysql-bin.000004 |      601 |              |                  |  005dab91-9ef4-11e8-8771-5254004e671f:1-2 |
 +------------------+----------+--------------+------------------+------------------------------------------+
 1 row in set (0.00 sec)

2. slave的配置

1. 編輯配置文件

啟用GTID

 [root@server6 mysql]# vim /etc/my.cnf
 編輯內容如下：
 server-id=2
 gtid-mode=on
 enforce-gtid-consistency=1

編輯完成重啟服務

2. 進行數據庫操作

在slave中進行如下操作

 mysql> change master to  master_host='172.25.25.5',master_user='bleach',master_password='Redhat_123',master_auto_position=1;
 Query OK, 0 rows affected, 2 warnings (0.57 sec)

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

 mysql> show slave status\G
 *************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 172.25.25.5
                   Master_User: bleach
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.000004
           Read_Master_Log_Pos: 601
                Relay_Log_File: server6-relay-bin.000002
                 Relay_Log_Pos: 814
         Relay_Master_Log_File: mysql-bin.000004
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
      ....................省略.....................   
                    Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 005dab91-9ef4-11e8-8771-5254004e671f:1-2
            Executed_Gtid_Set: 005dab91-9ef4-11e8-8771-5254004e671f:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

3.Mysql 的并行復制

• 一般主從復制，有三個線程參與，都是單線程：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：基于組提交的并行復制方式

MySQL 5.7開啟Enhanced Multi-Threaded Slave配置：

 slave配置文件中添加如下內容：
 slave-parallel-type=LOGICAL_CLOCK
 slave-parallel-workers=16
 master_info_repository=TABLE
 relay_log_info_repository=TABLE
 relay_log_recovery=ON

只需要在slave下進行操作
具體操作如下：

 編輯slave數據庫的配置文件，添加內容
 [root@server6 mysql]# vim /etc/my.cnf
 #
 server-id=2
 gtid-mode=on
 enforce-gtid-consistency=1
 slave-parallel-type=LOGICAL_CLOCK
 slave-parallel-workers=16
 master_info_repository=TABLE
 relay_log_info_repository=TABLE
 relay_log_recovery=ON

• master_info_repository解釋
  開啟MTS功能后，務必將參數master_info_repostitory設置為TABLE，這樣性能可以有50%~80%的提升。這是因為并行復制開啟后對于元master.info這個文件的更新將會大幅提升，資源的競爭也會變大。在之前InnoSQL的版本中，添加了參數來控制刷新master.info這個文件的頻率，甚至可以不刷新這個文件。因為刷新這個文件是沒有必要的，即根據master-info.log這個文件恢復本身就是不可靠的。在MySQL 5.7中，I可以將master_info_repository設置為TABLE，來減小這部分的開銷。
• slave_parallel_workers解釋
  若將slave_parallel_workers設置為0，則MySQL 5.7退化為原單線程復制，但將slave_parallel_workers設置為1，則SQL線程功能轉化為coordinator線程，但是只有1個worker線程進行回放，也是單線程復制。然而，這兩種性能卻又有一些的區別，因為多了一次coordinator線程的轉發，因此slave_parallel_workers=1的性能反而比0還要差

編輯完成，重啟服務
在slave中查看效果
執行：

 mysql> show processlist;

與修改前進行比較

結果增加了16條，就是配置slave-parallel-workers=16的作用，也就是開啟了并行復制的結果。

4.Mysql 的半同步復制

• 半同步復制的原理
  1、當Slave主機連接到Master時，能夠查看其是否處于半同步復制的機制。
  2、當Master上開啟半同步復制的功能時，至少應該有一個Slave開啟其功能。此時，一個線程在Master上提交事務將受到阻塞，直到得知一個已開啟半同步復制功能的Slave已收到此事務的所有事件，或等待超時。
  3、當一個事務的事件都已寫入其relay-log中且已刷新到磁盤上，Slave才會告知已收到。
  4、如果等待超時，也就是Master沒被告知已收到，此時Master會自動轉換為異步復制的機制。當至少一個半同步的Slave趕上了，Master與其Slave自動轉換為半同步復制的機制。
  5、半同步復制的功能要在Master，Slave都開啟，半同步復制才會起作用；否則，只開啟一邊，它依然為異步復制。
• 同步，異步，半同步復制的對比
  
  • 同步復制：Master提交事務，直到事務在所有的Slave都已提交，此時才會返回客戶端，事務執行完畢。缺點：完成一個事務可能會有很大的延遲。
  • 異步復制：當Slave準備好才會向Master請求binlog。缺點：不能保證一些事件都能夠被所有的Slave所接收。
  • 半同步復制：半同步復制工作的機制處于同步和異步之間，Master的事務提交阻塞，只要一個Slave已收到該事務的事件且已記錄。它不會等待所有的Slave都告知已收到，且它只是接收，并不用等其完全執行且提交。

進行半同步操作
環境與上述并行復制相同

1.查看是否支持半同步（主從庫都要進行確認）

 mysql> show variables like ‘have_dynamic_loading’;
 #確保value為YES 

2.進行插件安裝

master上

 安裝，模塊，開啟半同步
 mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
 Query OK, 0 rows affected (0.10 sec)

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

 mysql> show variables like '%semi%';
 +-------------------------------------------+------------+
 | Variable_name                             | Value      |
 +-------------------------------------------+------------+
 | rpl_semi_sync_master_enabled              | ON         |
 | rpl_semi_sync_master_timeout              | 10000      |
 | 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)

slave上

進行插件安裝

 mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
 Query OK, 0 rows affected (0.08 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)

在master端進行查看

 mysql> show status like '%rpl_semi_sync%';

3. 進行檢測

因為默認時延為10秒，可以通過關閉slave io_thread 來進行測試
在slave端關閉IO線程

在master端進行測試

在slave端進行查看