本文為您介紹PolarDB MySQL版基于物理復制架構，如何提升半同步復制（Semisynchronous replication，簡稱Semi-sync）的效率，降低對主庫的性能影響。主要內容包括背景介紹、功能介紹、注意事項、性能測試、常見問題等。
背景介紹
MySQL官方默認支持基于Binlog的半同步復制功能。在此模式下，主庫在事務提交前需要等待從庫確認已接收并同步了該事務所產生的Binlog日志。然而，這種同步機制會引入額外的延遲，從而對主庫的寫入性能產生一定的影響。
PolarDB MySQL版基于物理復制架構，通過高效的Redo日志在主備可用區(qū)之間進行同步，這使得半同步復制的效率顯著提高，從而大幅降低主庫的性能損失。在高并發(fā)負載情況下，與異步模式相比性能降低約為10%。
相較于MySQL官方基于Binlog的半同步機制，PolarDB MySQL版基于物理復制（Redo 流）的半同步機制具備更高的同步效率。在事務執(zhí)行過程中，Redo日志的產生和同步鏈路就已經產生并實時傳輸?shù)絺淇捎脜^(qū)，因此，在事務提交時，僅需等待對應的這條Redo日志成功同步至備可用區(qū)。而傳統(tǒng)的Binlog半同步機制則在事務提交時才生成完整的Binlog，此過程需要等到所有的Binlog日志同步完成后，才能向客戶端返回操作成功的信息。
功能介紹
PolarDB MySQL版半同步復制的邏輯相對容易理解：借助物理復制架構，通過Redo日志來完成主備可用區(qū)之間的同步工作。對于業(yè)務下發(fā)的寫入請求，會在主可用區(qū)完成數(shù)據(jù)修改時產生Redo日志，并通過物理復制鏈路同步Redo信息。在主可用區(qū)返回業(yè)務執(zhí)行成功前，寫請求對應的寫事務需要等待備可用區(qū)確認收到對應的Redo日志。
提交前最長等待時間
考慮到備可用區(qū)可能因某些非自然因素導致主可用區(qū)的寫入請求遲遲無法提交，因此，在內核層面會限制寫事務的提交前的最長等待時間，如果超過了設定時間仍未收到備可用區(qū)的同步確認信息，主可用區(qū)將會自動提交已經超時的寫入事務。
自適應機制
在極端情況下，備可用區(qū)可能無法及時向主可用區(qū)確認同步信息，導致主可用區(qū)的每一條寫入請求都需要等待超時后才能提交，造成性能損失。為了避免這一問題，半同步復制（Semi-sync）引入自適應機制，動態(tài)監(jiān)測主備可用區(qū)之間的網(wǎng)絡通信情況，在發(fā)生超時的情況較為頻繁時，會自動切換至異步模式，保證主可用區(qū)的寫入不受Semi-sync的影響，同時在監(jiān)測到主備可用區(qū)的同步情況恢復正常時，系統(tǒng)將自動重新開啟Semi-sync模式。
注意事項
PolarDB MySQL版基于物理復制的半同步模式能極大提升跨可用區(qū)切換的數(shù)據(jù)一致性，具體開啟流程請參見跨可用區(qū)自動切換。
目前僅PolarDB MySQL企業(yè)版，數(shù)據(jù)庫引擎為8.0.1且內核小版本為8.0.1.35.1及以上的集群支持跨可用區(qū)數(shù)據(jù)復制的半同步模式。
PolarDB MySQL企業(yè)版，數(shù)據(jù)庫引擎為8.0.1且內核小版本為 8.0.1.1.40及以上，新增半同步模式自適應機制。
PolarDB MySQL企業(yè)版，數(shù)據(jù)庫引擎為8.0.1且內核小版本為8.0.1.1.44.2及以上，開放參數(shù)
innodb_polar_wait_slave_reply_max_time用于控制開啟半同步復制后，主可用區(qū)寫事務在提交前默認最長等待時間，默認值500ms。
RPO和RTO
在異步場景下，跨可用區(qū)自動切換功能是有損切換（絕大部分情況下RPO<100ms，最差情況下RPO<60s），使用前請進行評估。
在半同步場景下，開啟后性能衰退約10%，默認事務提交等待時間是500ms，超過500ms就會退化為異步，不再等待同步至備可用區(qū)。無退化情況下RPO=0。
異步和半同步場景下的RTO<30s。
性能測試
本文中的測試結果僅反映當前版本的表現(xiàn)，并不代表最新版本的運行結果。
測試方式：同一個規(guī)格的集群，對比PolarDB MySQL版開啟異步模式、PolarDB MySQL版半同步模式和MySQL半同步模式的QPS性能差異。
測試工具：Sysbench下的oltp_write_only。
測試規(guī)格：16C 64 GB。
測試版本：PolarDB MySQL版8.0.1版本且內核小版本為8.0.1.35.1（可能與最新版本存在微小差異）。
數(shù)據(jù)量：10張數(shù)據(jù)表，每張表1000萬行數(shù)據(jù)。
可以看到開啟Semi-sync在高并發(fā)場景下的性能衰減約為10%，并且在任何并發(fā)壓力下，PolarDB MySQL版基于Redo日志方式的半同步復制的性能都要優(yōu)于MySQL基于Binlog方式的半同步。
常見問題
Q1：為什么開啟Semi-sync功能后，性能下降不止10%？
A1：在高并發(fā)的情況下，性能衰減最佳狀態(tài)約為10%，原因在于Redo通過batch的方式進行同步處理，從而有效降低了因網(wǎng)絡延遲帶來的開銷。在低并發(fā)場景下batch帶來性能提升不夠顯著，因此可能會導致性能下降的情況較為嚴重，僅單線程寫入時，無法對Redo IO進行batch操作，因為開啟半同步復制后，增加了一個網(wǎng)絡往返延遲從而明顯降低了性能。
Q2：為什么控制臺看不到innodb_polar_wait_slave_reply_max_time這個參數(shù)？我該如何調整這個參數(shù)到一個合適的值？
A2：僅PolarDB MySQL企業(yè)版，數(shù)據(jù)庫引擎為8.0.1且內核小版本為8.0.1.1.44.2及以上集群支持修改此參數(shù)，若控制臺無法搜索到參數(shù)，請先確認集群版本是否滿足要求，若不滿足可以進行版本升級。
關于該參數(shù)的設置：通常情況下，您無需手動修改，默認值是500ms。如存在特殊需求，例如希望事務必須等到備可用區(qū)同步后再提交，可以適當增加此參數(shù)值，但絕大多數(shù)情況下默認的500ms已經足夠。如果希望限制事務的等待時間，可以適當降低該參數(shù)值。但需要注意的是，當設置的值非常小，例如0或1ms時（通常主備可用區(qū)的網(wǎng)絡延遲維持在1ms以內，而半同步復制同步至少需要等待一次網(wǎng)絡來回），這可能導致半同步模式退化為異步模式，因此，修改此參數(shù)時需要結合實際情況進行考慮。
Q3：Semi-sync的自適應機制，什么情況下生效？我可以打開Semi-sync但是關閉自適應機制嗎？
A3：目前Semi-sync開啟后，系統(tǒng)會默認采用自適應機制，動態(tài)監(jiān)聽主備可用區(qū)同步狀態(tài)，并實時進行調整。目前暫不支持單獨關閉自適應機制。如果希望Semi-sync功能保持生效狀態(tài)，可innodb_polar_wait_slave_reply_max_time調整為一個較大的值，自適應機制將依賴于此參數(shù)值來判斷當前的超時情況。
Q4：Semi-sync不發(fā)生退化時的RPO=0，這里說的退化和自適應機制動態(tài)關閉是一回事么？
A4：二者并不相同。不發(fā)生退化是指任何事務在提交前，必須確保備可用區(qū)已經同步了相應的Redo信息，在此情況下，可以嚴格保證RPO=0，但是自適應機制監(jiān)測的粒度并非事務，而是網(wǎng)絡包的通信，當自適應機制動態(tài)關閉Semi-sync時，通常已經發(fā)生了多個事務因同步超時而被提交的情況。換句話說，即使開啟了Semi-sync且并沒有被自適應機制關閉，此時RPO并不嚴格等于0，可能存在極個別事務因同步超時而提交，但這屬于小概率事件，因此Semi-sync功能，能夠保證RPO無限接近于0。