MySQL Cluster 7.2.15 部署實戰與性能測試：NDB vs InnoDB 真實數據對比

架構拓撲

• Management Node (1)：10.88.49.119，ndb_mgmd，仲裁
• Data Node (1)：10.88.49.124，ndbd，存儲數據/索引
• SQL Node (2)：10.88.49.122/123，mysqld，對外服務

硬件：i7-3770 3.4GHz 單核，管理/SQL 節點 900MB 內存，Data 節點 3.6GB，RAID10。

關鍵配置 config.ini 精華

[NDBD DEFAULT]
NoOfReplicas=2
DataMemory=2500M
IndexMemory=500M
MaxNoOfConcurrentTransactions=10000
MaxNoOfConcurrentOperations=50000
MaxNoOfExecutionThreads=4
RealTimeScheduler=1
LockPagesInMainMemory=1
ODirect=1
RedoBuffer=1024M
FragmentLogFileSize=32M
NoOfFragmentLogFiles=8
HeartbeatIntervalDbDb=15000
HeartbeatIntervalDbApi=15000

[MGM DEFAULT]
PortNumber=1186

[TCP DEFAULT]
SendBufferMemory=64M

[NDB_MGMD]
NodeId=1
HostName=10.88.49.119
ArbitrationRank=1

[NDBD]
NodeId=4
HostName=10.88.49.124

[API]
NodeId=10
HostName=10.88.49.122
ArbitrationRank=2

[API]
NodeId=11
HostName=10.88.49.123
ArbitrationRank=2

啟動順序與避坑

1. Management：ndb_mgmd -f config.ini（注意 section 名稱空格：[NDBD DEFAULT] 非 [NDBDDEFAULT]）
2. Data Node：ndbd --initial 首次/配置變更；後續 ndbd
3. SQL Node：初始化 mysql_install_db --defaults-file=my.cnf，啟動 mysqld_safe，my.cnf 需 ndbcluster + ndb-connectstring
4. 驗證：ndb_mgm -e show 所有節點 CONNECTED

功能測試：tpcc-mysql 失敗，轉用 mysqlslap + sysbench

tpcc-mysql 數據加載階段報錯 Out of operation records (MaxNoOfConcurrentOperations)，調大參數後磁盤空間不足，放棄。

mysqlslap 測試結果 (500/1000/2000 查詢，混合負載)

sysbench OLTP 測試 (10萬行，1萬事務)

核心結論

1. 低併發 (≤16)：NDB 延遲略優於 InnoDB，得益於內存計算與分佈式鎖。
2. 高併發 (≥32)：InnoDB 延遲增長平緩，NDB 直接報錯資源耗盡（單 Data Node 瓶頸）。
3. 擴展性：NDB 設計為多 Data Node 線性擴展，單節點測試無法體現優勢。
4. 資源敏感：NDB 對 DataMemory、IndexMemory、MaxNoOfConcurrentOperations/Transactions 極度敏感，需精細容量規劃。

生產建議

• 至少 2 個 Data Node（NoOfReplicas=2），跨機架/可用區部署。
• Data Node 內存 ≥ 數據集 3 倍（含冗余、索引、Redo Log、碎片整理空間）。
• SQL Node 無狀態，可水平擴展至 10+，配合 LVS/Proxy 實現高可用。
• 監控關鍵指標：ndb_mgm -e "ALL REPORT MEMORYUSAGE"、Transporter 吞吐、LCP 耗時。

總結

MySQL Cluster NDB 引擎不是 InnoDB 的替代品，而是針對「極高可用、極低延遲、線性擴展」場景的專用引擎。單節點測試數據僅供參考，生產部署必須按分佈式架構設計，投入足夠硬件資源，才能釋放其真正價值。