第2章　半同步復制

2.1　MySQL半同步復制簡介

直到目前的最新版本，MySQL默認依然使用異步復制策略。所謂的異步復制，指的是主庫寫二進制日志、從庫的I/O線程讀主庫的二進制日志和寫本地中繼日志、從庫的SQL線程重放中繼日志，這三步操作都是異步進行的。如此選擇的主要理由是出于性能的考慮，與同步復制相比，異步復制顯然更快，同時能承載更高的吞吐量。不過，異步復制的缺點同樣顯而易見，它不能保證主從數據實時一致，也無法控制從庫的延遲時間，因此它不適于要求主從數據強一致性的場景。例如，為了分解讀寫壓力，同一個程序寫主庫讀從庫，且要求讀到的數據與讀主庫的相同，異步復制無法滿足這種強數據一致性的需求。異步復制的另一個問題是可能會有數據丟失，例如主庫宕機時，已經提交的事務可能還沒有傳到從庫上，如果此時強行進行主從切換，那么就可能導致新主庫上的數據不完整。

于是在MySQL 5.5中就自然而然地引入了半同步復制，用作異步復制的可選替代方案，它具有以下特性：

• 從庫在連接主庫時表明它是否支持半同步復制。
• 如果在主庫啟用了半同步復制，并且至少有一個支持半同步復制的從庫，則主庫上執行事務提交的線程將等待，直到至少一個半同步從庫確認已收到事務的所有事件（此時從庫會向主庫發送ACK信息，即確認信息。ACK為Acknowledgement的縮寫），或者直到發生超時。
• 只有在將事件寫入其中繼日志并刷新到磁盤后，從庫才會確認收到事務的事件，即向主庫發送ACK。
• 如果在沒有任何從庫確認事務的情況下發生超時，則主庫將退化為異步復制。當至少有一個半同步從庫趕上時，主庫恢復半同步復制。退化與恢復過程都是自動的。
• 必須在主庫和從庫上都啟用半同步復制，否則使用異步復制。

當主庫因等待來自從庫的確認而阻塞時，它不會返回執行事務的會話。阻塞結束時，主庫返回到會話，然后該會話可以繼續執行其他語句。此時，事務已在主庫提交，并且至少一個從庫已確認其事件的接收。在繼續之前，主庫必須收到的確認從庫的數量，可使用rpl_semi_sync_master_wait_for_slave_count系統變量進行配置，默認值為1。

不只是事務提交，事務回滾時主庫也會發生同樣的阻塞。MySQL同時支持多個數據庫引擎，當一個事務中既包含事務表又包含非事務表時，回滾即使對事務表沒有影響，二進制日志中也會記錄非事務表的事件，因為對非事務表的修改無法回滾并且必須發送到從庫。

在未以START TRANSACTION或SET autocommit=0開啟事務時，每條語句都自動隱式提交。使用半同步復制時，主庫上的這類語句就像顯式事務提交一樣。

為了加深對半同步復制中“半”的理解，簡單將其與異步和全同步復制進行比較：

• 異步復制：主庫提交事務時，將事件寫入它的二進制日志，而從庫在準備就緒時請求它們。主庫無需等待從庫的ACK回復，直接提交事務并返回客戶端。異步復制不確保所有事件都能到達從庫，因而無法保證數據的強一致性。
• 全同步復制：當主庫提交事務時，所有從庫也將在主庫返回執行事務的會話之前提交事務。這樣做的缺點是完成事務可能會有很大的延遲。
• 半同步復制：介于異步復制和全同步復制之間。主庫僅等待至少一個從庫接收并記錄事件。它不會等待所有從庫都確認收到，并且從庫只需要確認接收，而不是事件已在從庫處理完成和提交。

與異步復制相比，半同步復制提供了改進的數據完整性，因為當提交成功返回時，已知數據至少存在于兩個位置。半同步復制確實會對性能產生一些影響，因為需要等待從庫，提交速度會變慢，延遲至少是將提交發送到從庫，并等待從庫確認收到的一個TCP/IP往返時間（RTT，Round-Trip Time）。這意味著半同步復制最好用于低延時的網絡中。