Linux的企業-Mysql主從同步，Gtid，半同步，相關參數（1）

一.Mysql主從同步

MySQL 支持單向、異步複製,複製過程當中一個服務器充當主服務器,而一個或多個其它服務器充
當從服務器。主服務器將更新寫入二進制日誌文件,並維護文件的一個索引以跟蹤日誌循環。這
些日誌能夠記錄發送到從服務器的更新。當一個從服務器鏈接主服務器時,它通知主服務器從服
務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新,而後封
鎖並等待主服務器通知新的更新。
請注意當你進行復制時,全部對複製中的表的更新必須在主服務器上進行。不然,你必需要當心,
以免用戶對主服務器上的表進行的更新與對從服務器上的表所進行的更新之間的衝突。
單向複製有利於健壯性、速度和系統管理:
1. 主服務器/從服務器設置增長了健壯性。主服務器出現問題時,你能夠切換到從服務器做爲備份
2. 經過在主服務器和從服務器之間切分處理客戶查詢的負荷,能夠獲得更好的客戶響應時間。
SELECT 查詢能夠發送到從服務器以下降主服務器的查詢處理負荷。但修改
數據的語句仍然應發送到主服務器,以便主服務器和從服務器保持同步。若是非更新查詢爲主,該
負載均衡策略頗有效,但通常是更新查詢。
3. 使用複製的另外一個好處是可使用一個從服務器執行備份,而不會干擾主服務器。在備份過程
中主服務器能夠繼續處理更新。
MySQL 提供了數據庫的同步功能,這對咱們實現數據庫的冗災、備份、恢復、負載均衡等都是
有極大幫助的。

二.配置環境

server2 主 172.25.29.2

server3 從 172.25.29.3

1.配置server2

log-bin=mysql-bin  啓動二進制日誌系統
binlog-do-db=test #二進制須要同步的數據庫名,若是須要同步多個庫,例如要再同步 westos
庫,再添加一行「binlog-do-db=westos」,以此類推
server-id=1
#必須爲 1 到 232–1 之間的一個正整數值
binlog-ignore-db=mysql #禁止同步 mysql 數據庫

注：

設置參數—expire_logs_days=#(days)，此參數的含義是設置日誌的過時天數，過來指定的天數後日志將會被自動刪除，這樣將有利於減小DBA管理日誌的工做量。

進入到mysql中建立受權用戶，查看master信息

2.配置server3

配置文件只需寫上id號便可

重啓服務，將server2設置爲主，注意log_file文件和log_pso文件位置，在server2上看

啓動從數據庫主機，查看狀態

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

若是都是 yes,表示從庫的 I/O,Slave_SQL 線程都正確開啓.代表數據庫正在同步

查看同步的數據，顯示正常

三.Gtid的設置

全局事務標識：global transaction identifiers。GTID是一個事務一一對應，而且全局惟一ID。一個GTID在一個服務器上只執行一次，避免重複執行致使數據混亂或者主從不一致。
GTID用來代替傳統複製方法，再也不使用MASTER_LOG_FILE+MASTER_LOG_POS開啓複製。而是使用MASTER_AUTO_POSTION=1的方式開始複製。MySQL-5.6.5開始支持的，MySQL-5.6.10後開始完善。在傳統的slave端，binlog是不用開啓的，可是在GTID中slave端的binlog是必須開啓的，目的是記錄執行過的GTID（強制）。

優點：

更簡單的實現failover，不用之前那樣在須要找log_file和log_pos。更簡單的搭建主從複製。比傳統的複製更加安全。GTID是連續的沒有空洞的，保證數據的一致性，零丟失。

工做原理：

（1）當一個事務在主庫端執行並提交時，產生GTID，一同記錄到binlog日誌中。
（2）binlog傳輸到slave,並存儲到slave的relaylog後，讀取這個GTID的這個值設置gtid_next變量，即告訴Slave，下一個要執行的GTID值。
（3）sql線程從relay log中獲取GTID，而後對比slave端的binlog是否有該GTID。
（4）若是有記錄，說明該GTID的事務已經執行，slave會忽略。
（5）若是沒有記錄，slave就會執行該GTID事務，並記錄該GTID到自身的binlog，
   在讀取執行事務前會先檢查其餘session持有該GTID，確保不被重複執行。
（6）在解析過程當中會判斷是否有主鍵，若是沒有就用二級索引，若是沒有就用所有掃描。

1.安裝高版本5.7.19的mysql

   低版本不支持gtid

   刪除以前的低版本的mysql文件

   安裝完成後先配置好主從配置

   配置好server2,server3

完成主從複製的配置

2.配置Gtid

配置server1 vim /etc/my.cnf

配置server2 vim /etc/my.cnf

登錄server3上的mysql建立server2主節點

啓動從服務，查看從狀態

3.測試

在server2上建立數據

在server3上查看server2上的數據

查看從機的gtid更新表，已經有更新記錄

4.開啓多線程併發複製

slave-parallel-type

slave-parallel-workers

重啓後查看show processlist進程，顯示16

number of workers 爲16

四.半同步 半同步主要是保證數據完整性防止數據丟失

1.半同步複製概念

       在說明半同步複製以前咱們先來了解一下，什麼是同步複製？同步複製：同步複製能夠定義爲數據在同一時刻被提交到一臺或多臺機器，一般這是經過衆所周知的「兩階段提交」作到的。雖然這確實給你在多系統中保持一致性，但也因爲增長了額外的消息交換而形成性能降低。使用MyISAM或者InnoDB存儲引擎的MySQL自己並不支持同步複製，然而有些技術，例如分佈式複製塊設備（簡稱DRBD），能夠在下層的文件系統提供同步複製，容許第二個MySQL服務器在主服務器丟失的狀況下接管（使用第二服務器的複本）。瞭解了同步複製咱們正下面來講一下，什麼是半同步複製？

       MYSQL 5.5開始，支持半自動複製。以前版本的MySQL Replication都是異步（asynchronous）的，主庫在執行完一些事務後，是不會管備庫的進度的。若是備庫不幸落後，而更不幸的是主庫此時又出現Crash（例如宕機），這時備庫中的數據就是不完整的。簡而言之，在主庫發生故障的時候，咱們沒法使用備庫來繼續提供數據一致的服務了。Semisynchronous Replication(半同步複製)則必定程度上保證提交的事務已經傳給了至少一個備庫。Semi synchronous中，僅僅保證事務的已經傳遞到備庫上，可是並不確保已經在備庫上執行完成了。

       此外，還有一種狀況會致使主備數據不一致。在某個session中，主庫上提交一個事務後，會等待事務傳遞給至少一個備庫，若是在這個等待過程當中主庫Crash，那麼也可能備庫和主庫不一致，這是很致命的。若是主備網絡故障或者備庫掛了，主庫在事務提交後等待10秒（rpl_semi_sync_master_timeout的默認值）後，就會繼續。這時，主庫就會變回原來的異步狀態。

MySQL在加載並開啓Semi-sync插件後，每個事務需等待備庫接收日誌後才返回給客戶端。若是作的是小事務，兩臺主機的延遲又較小，則Semi-sync能夠實如今性能很小損失的狀況下的零數據丟失。

異步與半同步異同

       默認狀況下MySQL的複製是異步的，Master上全部的更新操做寫入Binlog以後並不確保全部的更新都被複制到Slave之上。異步操做雖然效率高，可是在Master/Slave出現問題的時候，存在很高數據不一樣步的風險，甚至可能丟失數據。

       MySQL5.5引入半同步複製功能的目的是爲了保證在master出問題的時候，至少有一臺Slave的數據是完整的。在超時的狀況下也能夠臨時轉入異步複製，保障業務的正常使用，直到一臺salve追遇上以後，繼續切換到半同步模式。

2.在主機server2上開啓半同步

添加半同步插件

查看半同步狀態爲OFF

       開啓半同步

3.在主機server3上開啓半同步

4.在主機server3上重啓mysql的IO接口正常

5.測試半同步

主機半同步狀態開啓

主機建立數據很快同步到從機server3上

查看從機半同步狀態開啓

關閉server3的IO接口

在主機server2上插入數據

等待10s半同步後，server3無響應，server2轉爲異步傳輸

主機已經有了數據

查看從機無剛纔主機server2上插入的數據

再次啓動IO接口，數據傳同步過來

查看從機的半同步狀態

6.半同步的永久設置

在server2配置文件中添加半同步選項開啓

vim /etc.my.cnf

在server3上也開啓，並開啓只讀模式

server2

10000ms爲半同步的等待時間，超時後變爲異步模式

server3的半同步也已經設置爲自動開啓

            只讀模式自動開啓

7.expire_logs_days表示保留時間

8.慢查詢

慢查詢已經開啓

選擇一個sleep模塊，時間設置爲默認的10秒

查看慢查詢狀態爲有一個慢查詢

經過慢查詢日誌