本文主要給大家介紹Mysql的高可用/容災架構的性能測試討論，希望可以給大家補充和更新些知識，如有其它問題需要了解的可以持續在創新互聯行業資訊里面關注我的更新文章的。

成都創新互聯公司主營子長網站建設的網絡公司,主營網站建設方案,成都App定制開發,子長h5微信小程序搭建,子長網站營銷推廣歡迎子長等地區企業咨詢

系統高可用/容災，是系統運維人員非常關心的一個話題。

基于AWS云平臺的數據庫，我們能做哪些高可用的架構設計呢？

目前中國區，有北京和寧夏兩個獨立的Region。關于RDS，不僅能做到Multi-AZ的設置，同時AWS還支持RDS的跨Region主從同步。

今天，我們就討論基于Mysql的高可用/容災架構的性能測試。

1. 創建Replica Slave

2. 這里我們可以選擇將Replica slave創建到“北京region”或者“寧夏region”。

3. 由于北京和寧夏的距離因素，大家都會關心北京Master和寧夏Replica的同步，會不會因為網絡延時，而導致lag較大？

今天我就進行測試，看看網絡延遲，會對主從同步有多大影響。

（注： 北京region和寧夏region是沒有直接連通的，也就是說，客戶的EC2或者其他服務的跨Region數據同步，都只能通過公網，或者自己準備的專線方式傳輸數據。但是AWS內部，會為RDS的主從同步，以及S3 的 Cross Region Replication功能提供專用的線路，并且針對每個account提供一定的帶寬）

測試環境準備，

<1. EC2   m4.xlarge   （4CPU 16G） <2. RDS  db.r4.xlarge    （4CPU 16G ） Mysql版本5.7.12 <3. 創建兩個replica，一個在寧夏，一個在北京，主要是為了比較同步情況，確認和區分網絡因素的差異 <4. Mysql創建20個表，每個表1000W行數據，數據量在40G左右 <5. 主庫使用sysbench進行壓力測試 ,sysbench使用方法參考：       https://blog.51cto.com/hsbxxl/2068181 <6. 主庫的參數修改       binlog_format=row <7. 從庫的下面參數設置，利用5.7的relay work的并發性能       slave_parallel_workers=50

4.  sysbench腳本

通過定時任務，執行sysbench腳本，每5分鐘執行一次 # crontab -l */5 * * * * /root/test.sh 每次執行150s，50個session并發讀寫20個表，每個表1000W行數據 # cat test.sh date >> sync.log sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \ --mysql-host=bjs.cbchwkqr6lfg.rds.cn-north-1.amazonaws.com.cn --mysql-port=3306 \ --mysql-user=admin --mysql-password=admin123 --mysql-db=testdb2 --oltp-tables-count=20 \ --oltp-table-size=10000000 --report-interval=10 --rand-init=on --max-requests=0 \ --oltp-read-only=off --time=150 --threads=50 \ run >> sync.log

5. 在主庫上，sysbench測試數據輸出如下，可以根據輸出，確定主庫的讀寫數據，進行參考：

[ 10s ] thds: 50 tps: 1072.24 qps: 21505.53 (r/w/o: 15060.08/4296.37/2149.08) lat (ms,95%): 89.16 err/s: 0.00 reconn/s: 0.00 [ 20s ] thds: 50 tps: 759.83 qps: 15195.04 (r/w/o: 10640.78/3034.21/1520.05) lat (ms,95%): 215.44 err/s: 0.00 reconn/s: 0.00 [ 30s ] thds: 50 tps: 631.10 qps: 12645.47 (r/w/o: 8853.55/2529.71/1262.21) lat (ms,95%): 262.64 err/s: 0.00 reconn/s: 0.00 ...... [ 130s ] thds: 50 tps: 765.94 qps: 15295.77 (r/w/o: 10701.91/3062.27/1531.59) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00 [ 140s ] thds: 50 tps: 690.08 qps: 13776.96 (r/w/o: 9636.39/2761.41/1379.16) lat (ms,95%): 150.29 err/s: 0.00 reconn/s: 0.00 [ 150s ] thds: 50 tps: 749.51 qps: 15033.64 (r/w/o: 10532.97/3000.45/1500.22) lat (ms,95%): 147.61 err/s: 0.00 reconn/s: 0.00 SQL statistics: queries performed: read:                            1458030 write:                           416580 other:                           208290 total:                           2082900 transactions:                        104145 (689.50 per sec.) queries:                             2082900 (13790.04 per sec.) ignored errors:                      0      (0.00 per sec.) reconnects:                          0      (0.00 per sec.) General statistics: total time:                          151.0422s total number of events:              104145 Latency (ms): min:                                    8.92 avg:                                   72.39 max:                                 7270.55 95th percentile:                      167.44 sum:                              7538949.20 Threads fairness: events (avg/stddev):           2082.9000/18.44 execution time (avg/stddev):   150.7790/0.44

現在我們一起看一下，在北京和寧夏的兩個replica的同步情況

6. 指標Replica Lag (Milliseconds)

可以看到，北京和寧夏的replica的同步性能基本是一致的，在每個150s的寫周期，都會有lag的上升，基本延遲在40～50s左右。這說明，網絡不是瓶頸，因為北京的replica和Master在同一個AZ的同一個subnet。

北京

寧夏

7. 根據上圖結果可以分析，主從的延遲，在Mysql自身replay的過程沒有跟上導致的延遲。

那么，我將兩個replica的RDS機型升級到 8CPU 32G，進行測試，并比較結果。

可以看到，升級機型，還是有幫助的，lag明顯下降不少，將延遲維持在20～30S

北京

寧夏

也保持和北京相同的lag，更說明了，網絡不是同步的瓶頸。Mysql自身replay log，是一個性能瓶頸。

8. 再觀察CPU的使用率

由于兩個replica只有同步數據的負載，所以可以看到，同步數據的性能消耗，只有15%

后面的曲線是在我升級到8CPU 32G之后，只有7.5%的負載。說明硬件資源是足夠的，但是Mysql自身的原因導致同步lag。

北京

寧夏

9. Write IOPS

穩定在4000左右，我實際分配的IOPS是6000，所以磁盤也不是瓶頸。另外，主庫能完成讀寫操作，理論上從庫只有寫操作，負載更低。物理硬件資源不會是限制。

北京

寧夏

10. 主庫的性能指標,可以看到，同樣的配置，主庫的資源還是夠用的。能滿足讀和寫的需求。

CPU性能指標

11. Write IOPS性能指標

12. Read IOPS性能指標

13. Write throughput性能指標

14. 既然數據庫主機資源，和網絡不是瓶頸。那么Mysql自身的問題，就需要我們去逐步調整了。

接下來，針對mysql的參數進行調整優化。

說是優化，是盡量降低備庫相關參數的影響，將IO相關的參數基本全部關閉，去跟隨OS層面的機制進行落盤。

實際上，replica的數據安全性要求相對主庫要小很多，所以，在從庫同步速度較慢的時候，結合實際情況，調整下面參數，會有顯著的效果。

innodb_flush_log_at_trx_commit=0 innodb_flush_neighbors=0 innodb_flush_sync=0 sync_binlog=0 sync_relay_log=0 slave_parallel_workers=50 master-info-repository  = TABLE relay-log-info-repository = TABLE

15. 調優之后的結果

寧夏

在調整完參數之后，效果立竿見影，從40s的延遲，降低到 5s左右

16. 再觀察一下北京區的replica（未調整Mysql參數）

依然還是維持之前的lag，保持在50s的延遲情況。

北京

17. 最后再調整一個參數，讓worker并行.默認情況下，這個參數是database，也就是只有在多個database被修改的情況下，worker才會并行工作。而實際情況下，大部分客戶都是一個database（schema）多個tables的情況。所以，將參數修改成LOGICAL_CLOCK，才能起到并行的作用。

slave_parallel_type＝LOGICAL_CLOCK

當worker并行之后，已經能夠將主從延遲降低到2S以內了，基本能滿足絕大部分業務場景了。

18. 測試總結

基于以下條件

硬件：4CPU 16G內存  6000IOPS磁盤

50個并發，每秒700個TPS，1.5W個QPS，1W個寫，的情況下。

北京到寧夏的Mysql主從，能控制在10S以內的延遲。

如果對于replica的數據安全性要求比較高，即不調整Mysql落盤的參數情況下，延遲在40～50s范圍。

根據實際情況，大家可以通過調整mysql參數，加大replica機型的方式，來獲取更好的同步性能。

Mysql作為一個開源RDBMS，雖然在Oracle的技術支持下，有了很大的進步。但是replica的種種性能，和Oracle的Dataguard的同步相比，還是有很大的差距。

后續我會繼續研究，如何能讓Mysql同步的更快。

19. 關于Mysql主從同步的調優：

<1. MySQL數據庫主從同步延遲原理。

答：談到MySQL數據庫主從同步延遲原理，得從mysql的數據庫主從復制原理說起，mysql的主從復制都是單線程的操作，主庫對所有DDL和 DML產生binlog，binlog是順序寫，所以效率很高，slave的Slave_IO_Running線程到主庫取日志，效率很比較高，下一步， 問題來了，slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的，不是順 序的，成本高很多，還可能可slave上的其他查詢產生lock爭用，由于Slave_SQL_Running也是單線程的，所以一個DDL卡主了，需要 執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時。有朋友會問：“主庫上那個相同的DDL也需要執行10分，為什 么slave會延時？”，答案是master可以并發，Slave_SQL_Running線程卻不可以。

<2. MySQL數據庫主從同步延遲是怎么產生的。

答：當主庫的TPS并發較高時，產生的DDL數量超過slave一個sql線程所能承受的范圍，那么延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。

<3. MySQL數據庫主從同步延遲解決方案

答：最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也 可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave。

看了以上關于Mysql的高可用/容災架構的性能測試討論，希望能給大家在實際運用中帶來一定的幫助。本文由于篇幅有限，難免會有不足和需要補充的地方，如有需要更加專業的解答，可在官網聯系我們的24小時售前售后，隨時幫您解答問題的。

另外有需要云服務器可以了解下創新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

網頁標題：Mysql的高可用/容災架構的性能測試討論-創新互聯
分享路徑：http://vcdvsql.cn/article38/pphsp.html

成都網站建設公司_創新互聯，為您提供建站公司、網站建設、App開發、定制網站、品牌網站設計、商城網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯