Linux的企業-Mysql主從同步，Gtid，半同步

阿新 • • 發佈：2017-10-01

mysql 半同步 gtid

一.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 數據庫

技術分享

進入到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上開啟半同步

添加半同步插件

技術分享