NDB Cluster 的優點之一是它可以運行在一般硬體上，在這方面沒有特殊要求，除了需要大量的 RAM 之外，因為所有即時資料儲存都是在記憶體中完成的。（可以使用磁碟資料表來減少此需求—有關這些的更多資訊，請參閱第 25.6.11 節，「NDB Cluster 磁碟資料表」）。您可以檢視ndbinfo.memoryusage表格，或ndb_mgm用戶端中REPORT MemoryUsage命令的輸出，以取得關於資料節點記憶體使用量的資訊。若要取得關於NDB表格使用的記憶體資訊，您可以查詢ndbinfo.memory_per_fragment表格。

在託管資料節點的電腦上，增加 CPU 數量、使用更快的 CPU 或兩者兼具，通常可望增強 NDB Cluster 的效能。資料節點以外的叢集處理程序記憶體需求相對較小。

NDB Cluster 的軟體需求也很適中。主機作業系統不需要任何不尋常的模組、服務、應用程式或組態來支援 NDB Cluster。對於支援的作業系統，標準安裝應該就足夠了。MySQL 軟體需求很簡單：只需要 NDB Cluster 的生產版本。嚴格來說，您並不需要自己編譯 MySQL 才能使用 NDB Cluster。我們假設您正在使用適合您平台的二進位檔，可從 NDB Cluster 軟體下載頁面取得：https://mysqldev.dev.org.tw/downloads/cluster/。

對於節點之間的通訊，NDB Cluster 支援任何標準拓樸中的 TCP/IP 網路，且每個主機的最低期望是一個標準的 100 Mbps 乙太網路卡，加上一個交換器、集線器或路由器，以提供整個叢集的網路連線。我們強烈建議在不與非叢集一部分的機器共用的專用子網路上執行 NDB Cluster，原因如下：

網路通訊和延遲。 NDB Cluster 需要資料節點和 API 節點（包括 SQL 節點）之間以及資料節點和其他資料節點之間的通訊，才能執行查詢和更新。這些處理程序之間的通訊延遲會直接影響使用者查詢的觀察效能和延遲。此外，為了在節點靜默失敗的情況下維持一致性和服務，NDB Cluster 使用心跳訊號和逾時機制，將節點長時間失去通訊視為節點失敗。這可能會導致冗餘降低。請回想一下，為了維持資料一致性，當節點群組中的最後一個節點失敗時，NDB Cluster 會關閉。因此，為了避免增加強制關閉的風險，應盡可能避免節點之間的通訊中斷。

資料或 API 節點的失敗會導致中止所有涉及失敗節點的未提交交易。資料節點復原需要從倖存的資料節點同步失敗節點的資料，並重新建立基於磁碟的重做記錄和檢查點記錄，然後資料節點才能恢復服務。此復原可能需要一些時間，在此期間，叢集將在冗餘降低的情況下運作。

心跳訊號依賴於所有節點及時產生心跳訊號。如果節點過載、由於與其他程式共用而導致機器 CPU 不足，或由於交換而延遲，則可能無法做到這一點。如果心跳訊號產生延遲過久，其他節點會將回應緩慢的節點視為失敗。

在某些情況下，將緩慢的節點視為失敗的節點可能不理想，這取決於節點速度減慢的運作對叢集其他部分的影響。為 NDB Cluster 設定逾時值時，例如HeartbeatIntervalDbDb和HeartbeatIntervalDbApi，必須小心謹慎，以實現快速偵測、容錯移轉和恢復服務，同時避免可能代價高昂的誤判。

如果預期資料節點之間的通訊延遲高於 LAN 環境（約 100 µs）中的預期，則必須增加逾時參數，以確保任何允許的延遲時間都在設定的逾時範圍內。以這種方式增加逾時對偵測失敗的最糟情況時間以及恢復服務時間產生相應的影響。

LAN 環境通常可以配置為具有穩定的低延遲，並且可以提供快速容錯移轉的冗餘。個別連結故障可以從 TCP 層級（NDB Cluster 通常在此層級運作）以最小且受控的延遲進行復原。WAN 環境可能會提供一系列延遲，以及較慢容錯移轉時間的冗餘。個別連結故障可能需要路由變更才能在端對端連線還原之前傳播。在 TCP 層級，這可能會顯示為個別通道上的較大延遲。在這些情況下，觀察到的最糟情況 TCP 延遲與 IP 層繞過故障重新路由的最糟情況時間有關。