MySQL NDB Cluster 常見問題集

答：MySQL NDB Cluster 是建立在 NDB 儲存引擎上，並提供高度可擴展、即時、符合 ACID 的交易型資料庫，結合了 99.999% 的可用性和開放原始碼的低總持有成本。MySQL NDB Cluster 圍繞分散式、多主機架構設計，沒有單點故障，可在一般硬體上水平擴展，透過 SQL 和 NoSQL 介面存取，以服務讀取和寫入密集型工作負載。

MySQL NDB Cluster 的即時設計可提供可預測的毫秒級回應時間，並具有每秒處理數百萬次操作的能力。支援記憶體內和磁碟式資料、自動資料分割 (分片) 以及負載平衡，並且能夠在運行中的叢集中新增節點且不會停機，可實現線性資料庫擴展，以處理最不可預測的 Web 類型工作負載。

答：MySQL NDB Cluster Carrier Grade Edition (CGE) 包含用於管理、監控、安全性與稽核 MySQL NDB Cluster 資料庫的工具，以及 Oracle Premier Support 的存取權限。MySQL NDB Cluster CGE 提供訂閱或商業授權和支援選項。

• 深入瞭解MySQL NDB Cluster CGE

答：請參閱 https://mysql.dev.org.tw/customers/cluster/。

答：目前的 GA 版本是 MySQL NDB Cluster 8.0。MySQL 8.0 已與 MySQL NDB Cluster 整合和捆綁。

答：不需要，MySQL NDB Cluster 旨在於一般硬體上執行。使用特殊的硬體，例如 Infiniband 網路互連，可以達到更高的效能，尤其是在具有多個節點的大型叢集中。

答：如果您對下列任何問題回答「是」，那麼您應考慮將 MySQL NDB Cluster 作為應用程式資料庫的選項

• 您是否需要分割資料庫以符合不斷增長的寫入 (UPDATE、INSERT、DELETE) 操作量？
• 您是否需要確保 SELECT 操作的結果一致，無論是從哪個節點傳回？
• 如果您的資料庫發生故障，是否會導致應用程式停機，進而導致業務中斷，包括收入損失、聲譽損失等？
• 在容錯移轉期間，資料遺失 (即使只有幾秒鐘的資料) 是否會導致業務中斷？
• 您的使用者體驗是否對回應時間敏感？
• 您是否需要在不同地理區域複寫資料庫，每個區域都提供讀取和寫入操作？
• 您是否執行各種不同的應用程式，這些應用程式會受益於直接存取資料，而不需要總是依賴 SQL (例如使用 node.js 的 JavaScript、memcached API、Java 和 JPA 應用程式、HTTP/REST Web 服務和 C++ 應用程式)？
• 您的應用程式是否主要包含「簡短」的交易 (也就是每次交易 10 次操作，而不是 1000 次操作) 並行執行？
• 您的應用程式是否主要包含
  • 主要索引鍵資料庫存取，其中包含一些 JOIN 操作
  • 相對
  • 定期執行完整表格掃描和 JOIN，並傳回數萬列資料？

答：理想的應用程式包括

• 高容量 OLTP
• 即時分析
• 具有詐欺偵測的電子商務和金融交易
• 行動支付和微支付
• 工作階段管理和快取
• 摘要串流、分析和建議
• 內容管理和傳遞
• 大型多人線上遊戲
• 通訊和存在服務
• 訂閱者/使用者設定檔管理和權限

請參閱完整的MySQL NDB Cluster 使用案例和應用程式清單。

答：是。MySQL NDB Cluster 已在 Oracle VM 上測試並通過認證。

答

• 可用性
  • 99.999% (每年 <5 分鐘的停機時間)
• 效能
  • 回應時間：低於 5 毫秒 (透過 SQL 進行同步複寫和存取)。使用 NoSQL 存取方法之一可實現更快的反應時間。
  • 配備 64GB RAM 的雙插槽 Intel 伺服器上，每秒可執行 600,000 次以上複寫的 UPDATE 操作。在 30 台 Intel 伺服器的叢集中，每分鐘可執行 10 億次 UPDATE 操作。
• 容錯移轉
  • 次秒級容錯移轉可讓您在不停機的情況下提供服務
• 可擴展性
  • 向外擴展、向上擴展和動態擴展
  • 為了實現經濟高效的向外擴展
    • 每個叢集新增更多應用程式和資料節點，或
    • 新增更多 CPU 執行緒 (16、32、64 等)，或
    • 每個資料節點新增更多記憶體 (32GB、64GB 等)

答：為了評估和開發目的，您可以在單一主機上執行所有節點。為了實現完全的冗餘和容錯能力，您至少需要 6 個實體主機

• 2 個資料節點
• 2 個 SQL/NoSQL 應用程式節點
• 2 個管理節點

許多使用者將管理和應用程式節點放置在一起，這將節點數減少到四個。

答：可以

MySQL NDB Cluster 長期以來提供地理複寫，將叢集分散到遠端資料中心，以藉由將資料推送到更靠近使用者的地方來減少地理延遲的影響，並提供災難復原的功能。

地理複寫是非同步的，可以實作為主動/主動或主動/被動叢集。

地理複寫是跨資料中心部署的建議部署模型。

答：可以使用任何 MySQL 連接器來開發應用程式。MySQL NDB Cluster 還透過 JavaScript、Memcached、C++、Java、JPA 和 HTTP/REST 提供原生 NoSQL 連線功能。

答：不，介面相同。

答：是，ISV 和網路設備供應商 (NEP) 通常將 MySQL NDB Cluster 用作嵌入式資料庫。客戶清單 »

答：地理複寫可跨主動/主動地理上分散的叢集實現非同步複寫。這通常用於向外擴展全球服務、資料地區性和災難復原。

答：是，MySQL NDB Cluster 支援單向和雙向複寫。當使用雙向地理複寫時，會提供交易衝突偵測和解決方案。

答： MySQL NDB Cluster 配置通常會在不同的主機上至少保留所有資料的 2 個副本。為了應對整體系統故障，交易日誌和檢查點檔案會以可設定的頻率持久儲存在磁碟上。此外，未建立索引的資料也可能會儲存在磁碟上。

答： MySQL NDB Cluster 有無磁碟選項以及無日誌選項。

對於無磁碟選項，以下限制適用

1. 無磁碟資料
2. 叢集故障時資料遺失
3. 無備份

對於無日誌選項，叢集仍會建立日誌檔案，但資料不會檢查點至磁碟。

答： 否。MySQL NDB Cluster Manager 僅作為商業版 MySQL NDB Cluster Carrier Grade Edition (CGE) 資料庫的一部分提供。如需購買 MySQL NDB Cluster CGE 的訂閱或授權，請聯絡 MySQL 銷售團隊。

答： MySQL NDB Cluster Manager 是一款軟體，透過自動化常見的管理任務，簡化了 MySQL NDB Cluster 資料庫的建立和管理。

答： 透過使用 MySQL NDB Cluster Manager，資料庫管理員 (DBA) 和系統管理員的工作效率會更高，使他們能夠專注於策略性 IT 計劃，並更快速地回應不斷變化的使用者需求。同時，先前因手動設定錯誤而導致的資料庫停機風險也顯著降低。

答： 舉例來說，先前需要 46 個手動指令¹ 並耗費 DBA 2.5 小時² 的 MySQL NDB Cluster 資料庫滾動重新啟動管理作業，現在可以使用單個指令執行，並透過 MySQL NDB Cluster Manager 完全自動化，有助於減少

• 管理複雜度和額外負荷；
• 透過自動化設定和變更管理流程來降低停機風險；
• 自訂管理指令的指令碼或開發及維護內部管理工具。

答： 管理員可以使用單個指令建立和刪除整個叢集，並啟動、停止和重新啟動叢集，以及在線上新增節點。因此，管理員不再需要依正確順序手動重新啟動每個資料節點，或建立自訂指令碼來自動化此流程。

MySQL NDB Cluster Manager 可自動化線上管理作業，包括執行中叢集的升級、降級和重新設定，而不會中斷存取資料庫的應用程式或用戶端。管理員不再需要手動編輯設定檔並將其發佈到所有其他叢集節點，或確定是否需要滾動重新啟動。MySQL NDB Cluster Manager 會處理所有這些任務，從而強制執行最佳實務，並使線上作業更加簡單、快速且不易出錯。

答： 兩者皆可。MySQL NDB Cluster Manager 提供將整個叢集作為單一實體控制的功能，同時還支援對叢集內個別處理程序進行非常精細的控制。

答： MySQL NDB Cluster Manager 能夠透過自動輪詢叢集中的每個節點，在作業系統和每個處理程序層級監控叢集健康狀況。它可以偵測處理程序或伺服器主機是否存活、已關閉或已停止回應，從而更快地偵測、解決和復原問題。

答： MySQL NDB Cluster Manager 透過自動化先前由管理員手動執行的任務，來整合和擴展現有的管理功能。如上述範例所示，先前需要 46 個手動指令的流程現在縮減為單個指令，並且每個流程步驟都已完全自動化。

就指令碼編寫甚至開發自訂管理系統而言，手動開發、測試和維護此類專案既耗時、成本高昂，而且可能容易出錯。對於許多維護活動，使用 MySQL NDB Cluster Manager 消除了此類活動的需求。

透過自動化，MySQL NDB Cluster Manager 簡化了叢集管理，同時降低了成本、風險和工作量。

答： 是的。MySQL NDB Cluster 本身具有從故障中自我修復的能力，無需手動干預即可自動重新啟動失敗的資料節點。MySQL NDB Cluster Manager 透過同時監控和自動復原 SQL 和管理節點來擴展此功能。這支援叢集更順暢且更完整的自我修復，以將作業和容量完全恢復到應用程式。

答： 是的，除了使用原生 NDB API 的應用程式節點（即透過 C++、Java 的叢集連接器、OpenLDAP 等直接介面存取叢集的節點）。

答： 不會。為了確保高可用性作業，MySQL NDB Cluster Manager 與實際的資料庫處理程序分離，因此如果管理代理程式停止或升級，不會以任何方式影響執行中的資料庫。當任何給定代理程式或相關主機不可用時，MySQL NDB Cluster Manager 會在倖存的節點之間繼續運作。

答： MySQL NDB Cluster Manager 是實作為一組代理程式 – 一個代理程式在每個將包含要管理的 MySQL NDB Cluster 節點（處理程序）的實體主機上執行。管理員將常規 mysql 用戶端連線到其中任何一個代理程式，然後這些代理程式會互相通訊並協作，以在組成叢集的節點之間執行作業。

答： 當使用 MySQL NDB Cluster Manager 管理 MySQL NDB Cluster 部署時，管理員不再編輯設定檔（例如 config.ini 和 my.cnf）；相反地，這些檔案是由代理程式建立和維護。事實上，如果手動編輯這些檔案，變更將會被代理程式內持有的設定資訊覆寫。

組成 MySQL NDB Cluster 部署的所有處理程序都由 MySQL NDB Cluster Manager 啟動、重新啟動和停止。這包括資料節點、管理節點和 MySQL 伺服器節點。

同樣地，當使用 MySQL NDB Cluster Manager 時，管理員不得使用 ndb_mgm 命令執行管理動作（該命令直接連線到管理節點，表示代理程式本身無法看到使用它執行的任何作業）。

答： 引入 MySQL NDB Cluster Manager 並未消除對管理節點的需求；特別是它們會繼續執行許多關鍵角色

• 當資料節點啟動（或重新啟動）時，它們會連線到管理節點以檢索其設定資料（管理節點接著會從代理程式建立的設定檔中提取該資料）；
• 當透過 MySQL NDB Cluster Manager 停止或重新啟動資料節點時，狀態變更實際上是由管理節點執行；
• 管理節點可以繼續充當仲裁者（避免分裂大腦的情形）。因此，務必繼續在與資料節點不同的主機上執行這些處理程序；
• 某些報告資訊（例如，記憶體使用量）在 MySQL NDB Cluster Manager 中尚不可用，並且仍可使用 ndb_mgm 工具執行。

答： 代理程式本身沒有守護處理程序，因此為了達到最高層級的可用性，管理員可以選擇使用處理程序監視器來偵測代理程式的故障並自動重新啟動它；例如，在 /etc/init.d 中建立指令碼。

答： 是的。當管理代理程式重新啟動時，它們會自動與其他執行中的管理代理程式重新同步，以確保整個叢集的設定一致性，而無需管理員干預。

答： 是的。所有 MySQL NDB Cluster 設定資訊和處理程序識別碼都會持久儲存到磁碟，使其能夠在系統故障或重新啟動 MySQL NDB Cluster Manager 後繼續存在。

答： MySQL NDB Cluster Manager 支援每個管理代理程式之間的非同步通訊，以便可靠地傳播重新設定請求。因此，設定在叢集中的所有節點之間保持一致。

只有在所有節點都確認已收到重新設定請求時，才會提交任何變更。如果一個或多個節點未能收到請求，則會向用戶端回報錯誤。透過自動協調重新設定請求，消除了因手動發佈設定檔而導致錯誤的機會。

答： 請參閱支援的平台頁面。

答： MySQL NDB Cluster 6.3 及更高版本。

答： 從以下資源

• MySQL NDB Cluster Manager