來源：oracleace

摘要：MySQL 8.2引入了透明讀/寫分離功能，MySQL 路由器可以自動將只讀SQL路由到叢集的只讀節點。然而，MySQL路由器在此過程中需要對接收到的SQL進行一定程度的解析，以確定其是否為只讀SQL。這個解析過程對系統效能會有怎樣的影響呢？知名MySQL佈道師Frédéric Descamps對此進行了測試，讓我們一起看看他的分析。

這裡號主翻譯了知名MySQL佈道師Frédéric Descamps撰寫的關於MySQL 8.2透明讀/寫分離效能的測試和分析。

原文網址：

作者：Frédéric Descamps，Oracle公司MySQL社群經理，知名MySQL佈道師。

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

我們一直在等待它！它現在已經可用了！MySQL中的讀/寫分離！！

在之前的文章中，我們已經瞭解了MySQL 8.2的透明讀/寫拆分是什麼，以及如何與MySQL Connector/Python一起使用。我對這一新功能表示歡迎，但我想了解它是否真的值得。應用程式是否能夠從將讀操作解除安裝到另一個節點中受益，並且使用MySQL路由器和解析請求是否會減慢連線速度？這些是我在本文中要介紹和回答的問題。

01

—

環境

為了執行測試，我使用以下環境：

Linux Kernel 5.15.0 – aarch64
MySQL Community Server 8.2.0
MySQL Router 8.2.0
sysbench 1.1.0 using LuaJIT 2.1.0-beta3
VM.Standard.A1.Flex – Neoverse-N1 (50 BogoMIPS) 4 cores
24GB of RAM

MySQL InnoDB 叢集在 3 臺機器上執行，一臺機器用於 MySQL 路由器和 Sysbench。

Sysbench 準備了 8 個表，每個表有 100000 條記錄。

MySQL連線使用SSL。

02

—

MySQL InnoDB 叢集

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

以下是 MySQL Shell 中叢集的概述：

JS > cluster.describe(){    "clusterName": "myCluster",     "defaultReplicaSet": {        "name": "default",         "topology": [            {                "address": "mysql1:3306",                 "label": "mysql1:3306",                 "role": "HA"            },             {                "address": "mysql2:3306",                 "label": "mysql2:3306",                 "role": "HA"            },             {                "address": "mysql3:3306",                 "label": "mysql3:3306",                 "role": "HA"            }        ],         "topologyMode": "Single-Primary"    }}

JS > cluster.status(){    "clusterName": "myCluster",     "defaultReplicaSet": {        "name": "default",         "primary": "mysql1:3306",         "ssl": "REQUIRED",         "status": "OK",         "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",         "topology": {            "mysql1:3306": {                "address": "mysql1:3306",                 "memberRole": "PRIMARY",                 "mode": "R/W",                 "readReplicas": {},                 "replicationLag": "applier_queue_applied",                 "role": "HA",                 "status": "ONLINE",                 "version": "8.2.0"            },             "mysql2:3306": {                "address": "mysql2:3306",                 "memberRole": "SECONDARY",                 "mode": "R/O",                 "readReplicas": {},                 "replicationLag": "applier_queue_applied",                 "role": "HA",                 "status": "ONLINE",                 "version": "8.2.0"            },             "mysql3:3306": {                "address": "mysql3:3306",                 "memberRole": "SECONDARY",                 "mode": "R/O",                 "readReplicas": {},                 "replicationLag": "applier_queue_applied",                 "role": "HA",                 "status": "ONLINE",                 "version": "8.2.0"            }        },         "topologyMode": "Single-Primary"    },     "groupInformationSourceMember": "mysql1:3306"}

還有已經引導到叢集的MySQL路由器，在MySQL路由器中我們可以看到所有的埠：

JS > cluster.listRouters(){    "clusterName": "myCluster",     "routers": {        "router.sub09280951550.mysqlgermany.oraclevcn.com::system": {            "hostname": "router.subXXXXXXX.mysqlgermany.oraclevcn.com",             "lastCheckIn": "2023-11-15 09:27:18",             "roPort": "6447",             "roXPort": "6449",             "rwPort": "6446",             "rwSplitPort": "6450",             "rwXPort": "6448",             "version": "8.2.0"        }    }}

03

—

OLTP 讀/寫

我們首先在主節點（埠 3306 ）上使用 sysbench 的oltp_read_write.lua指令碼，然後使用 MySQL 路由器的讀/寫專用埠（埠6446）再次執行它，最後使用讀/寫拆分埠（埠6450）。測試使用 8 個執行緒，每次執行 3 次。

下面是測試使用的命令，主機和埠當然會變化：

$ sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql \   --mysql-user=sysbench --mysql-password=XxxxXX --mysql-ssl=REQUIRED \   --mysql-host=<...> --mysql-port=<...> --tables=8 --table-size=100000 \   --threads=8 run

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

8 個執行緒並不多，在這個工作負載中也沒有太多的爭用，但我們可以看到差異很小。當然，分析每個事務/查詢並將它們傳送到不同的主機是有成本的。

04

—

OLTP 只讀

這一次，我們再次執行 sysbench，但我們使用oltp_read_only.lua指令碼。再次使用 8 個執行緒和 3 次執行：

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

我們在這裡看到了更大的區別，因為沒有寫入，一臺機器可以輕鬆處理滿載。因此，解析請求並將其傳送到多個伺服器的成本更高。

當然，這只是因為單臺伺服器可以輕鬆地承擔工作負載。

如果我們有一個只讀工作負載，那麼我建議使用 MySQL Router 的只讀埠：6447。

04

—

OLTP 只寫

我們還使用指令碼oltp_write_only.lua測試了只寫工作負載。再次 8 個執行緒和 3 次執行：

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

我們可以看到，差異很小，但差異的確存在。

05

—

更復雜的工作負載

使用更復雜且最佳化程度較低的工作負載，例如oltp_update_non_index.lua，我們可以看到顯著的差異。

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

06

—

結論

MySQL 8.2 的透明讀/寫分離是我們一直在等待的一個非常有趣的功能，它在效能方面的消耗非常低，它更加適合於查詢模式穩定的應用，因為這樣的應用會降低MySQL路由器解析SQL的成本。

您真的應該測試一下，並將您的意見傳送給我們。

享受MySQL、MySQL路由器和所有整合解決方案（InnoDB ReplicaSet，InnoDB Cluster，InnoDB ClusterSet，InnoDB Read Replicas）。

使用MySQL 8.2透明讀/寫分離，代價幾何？（譯文）

環境

MySQL InnoDB 叢集

OLTP 讀/寫

OLTP 只讀

OLTP 只寫

更復雜的工作負載

結論

相關文章