MySQL 9.0 版本注意事項
本節提供啟動 NDB Cluster 資料節點時所涉及步驟的簡化概述。更完整的資訊可以在 NDB 內部指南的 NDB Cluster 啟動階段中找到。
這些階段與管理客戶端中 node_id STATUSndbinfo.nodes 表格的 start_phase 欄中報告。
啟動類型。 以下列出的幾種不同的啟動類型和模式
設定和初始化 (階段 -1)。 在啟動之前，必須初始化每個資料節點 (ndbd 處理程序)。初始化包含以下步驟
取得節點 ID
擷取組態資料
配置用於節點間通訊的連接埠
根據從組態檔案取得的設定配置記憶體
當資料節點或 SQL 節點首次連線到管理節點時，它會保留叢集節點 ID。為了確保沒有其他節點配置相同的節點 ID，這個 ID 會被保留，直到節點設法連線到叢集，且至少有一個 ndbd 報告此節點已連線。節點 ID 的保留由所討論的節點與 ndb_mgmd 之間的連線保護。
在每個資料節點初始化後，叢集啟動程序即可繼續。叢集在此程序中經歷的階段在此列出
階段 0。
NDBFS和NDBCNTR區塊啟動。在以--initial選項啟動的資料節點上，會清除資料節點檔案系統。階段 1。 在此階段，所有剩餘的
NDB核心區塊都會啟動。設定 NDB Cluster 連線、建立區塊間通訊，並啟動心跳。在節點重新啟動的情況下，也會檢查 API 節點連線。注意當一個或多個節點在階段 1 中掛起，而其餘一個或多個節點在階段 2 中掛起時，這通常表示網路問題。其中一個可能的原因是一些叢集主機具有多個網路介面。造成這種情況的另一個常見問題來源是封鎖叢集節點之間通訊所需的 TCP/IP 連接埠。在後者的情況下，這通常是由於防火牆設定錯誤所造成。
階段 2。
NDBCNTR核心區塊會檢查所有現有節點的狀態。選取主要節點，並初始化叢集綱要檔案。階段 3。
DBLQH和DBTC核心區塊會在它們之間設定通訊。決定啟動類型；如果這是重新啟動，DBDIH區塊會取得執行重新啟動的權限。階段 4。 對於初始啟動或初始節點重新啟動，會建立重做日誌檔案。這些檔案的數量等於
NoOfFragmentLogFiles。對於系統重新啟動
讀取綱要或多個綱要。
從本機檢查點讀取資料。
套用所有重做資訊，直到達到最新的可還原全域檢查點。
對於節點重新啟動，請尋找重做日誌的尾端。
階段 5。 資料節點啟動的大部分資料庫相關部分在此階段執行。對於初始啟動或系統重新啟動，會先執行本機檢查點，然後執行全域檢查點。記憶體使用情況的定期檢查在此階段開始，並會執行任何必要的節點接管。
階段 6。 在此階段中，會定義和設定節點群組。
階段 7。 選取仲裁器節點並開始運作。設定下一個備份 ID，以及備份磁碟寫入速度。達到此啟動階段的節點會標記為
已啟動。API 節點 (包括 SQL 節點) 現在可以連線到叢集。階段 8。 如果這是系統重新啟動，則會重建所有索引 (透過
DBDIH)。階段 9。 重設節點內部啟動變數。
階段 100 (已過時)。 過去，在節點重新啟動或初始節點重新啟動期間，API 節點可以在此時連線到節點並開始接收事件。目前，此階段為空。
階段 101。 在節點重新啟動或初始節點重新啟動中的這一點，事件傳遞會交給加入叢集的節點。新加入的節點會接管將其主要資料傳遞給訂閱者的責任。此階段也稱為
SUMA交接階段。
在初始啟動或系統重新啟動完成此程序後，會啟用交易處理。對於節點重新啟動或初始節點重新啟動，啟動程序的完成表示節點現在可以作為交易協調器。