使用 Galera 建構彈性 Nextcloud 集群

首先建立資料庫集群，然後將多個相同的 Nextcloud 應用節點部署在經過健康檢查的負載平衡器之後。為了確保部署穩定，所有應用節點必須使用相同的持久性檔案儲存、配置、Redis 或 Valkey 鎖定服務，以及一個僅將寫入作業路由到健康 Galera 成員的資料庫端點。 Nextcloud 目前的管理手冊將 MariaDB 列為受支援的資料庫，但並未發布針對 Galera 的部署方案；在正式上線之前，請務必與供應商確認您的 Nextcloud、MariaDB、Galera 和代理的具體版本。

截至 2026 年 10 月 9 日，Nextcloud 35 的系統需求頁面列出了 MariaDB 10.11、11.4、11.8 和 12.3 版本，其中 12.3 版本被標記為建議版本。這只是 Nextcloud 資料庫版本列表，並不能保證所有 Galera 或代理程式組合都經過認證。請先查看Nextcloud 35 的系統需求以及您的 MariaDB 發行版的 Galera 支援矩陣。

1. 定義失效邊界

高可用性叢集不僅僅包含一個複製的資料庫。 Galera 保護資料庫層，但它不會複製 Nextcloud 的使用者檔案、PHP 會話、Redis 鎖定或應用程式程式碼。單一共享資料庫也無法彌補儲存掛載失敗或負載平衡器持續向故障應用節點發送流量的情況。

安裝前請先規劃好以下組件：

• 至少兩台應用程式伺服器運行相同的 Nextcloud 版本、PHP 版本、已啟用的應用程式和 Web 設定。
• 具有穩定公共主機名稱、HTTPS 和應用伺服器健康檢查的負載平衡器或反向代理。
• 共享且持久的 Nextcloud 資料存儲，在所有應用伺服器上均位於同一路徑且擁有正確的權限。 Nextcloud 資料目錄應在安裝過程中設定；其安裝指南提醒，之後行動資料目錄會比較困難。
• Galera 叢集具有奇數個投票資料庫節點（通常為三個），其放置方式使得單一主機故障不會使多數派失去投票權。
• 用於分散式快取和事務性檔案鎖的共用 Redis 或 Valkey 服務。

選擇具有冗餘機制和經過測試的恢復方案的儲存和網路設計。即使多個 Web 伺服器可以掛載相同共用路徑，也不代表該路徑就一定具有高可用性。

2. 先安裝並驗證 MariaDB Galera

選擇符合 Nextcloud 目前要求的 MariaDB 版本，以及 MariaDB 供應商支援的相應 Galera 軟體套件。請遵循MariaDB Galera 部署文檔，完成節點配置、網路連接埠、狀態快照傳輸、TLS 和初始引導等步驟。不要將每個空節點都作為新叢集啟動；先引導一個節點，然後將其他節點加入該叢集。

Nextcloud 需要 InnoDB 資料庫，並且READ-COMMITTED需要 MySQL 或 MariaDB 的事務隔離等級。 Nextcloud 資料庫頁面也建議使用基於行的二進位日誌記錄。請確認每個資料庫節點上的這些值，而不僅僅是目前接收流量的節點。請參閱Nextcloud 的 MariaDB 設定需求。

在連接 Nextcloud 之前，請檢查每個節點上的叢集狀態。例如，執行 `npm run build`SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';和 ` npm run start` 指令SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';。叢集應報告Primary元件、預期叢集大小以及處於該Synced狀態的節點數。 MariaDB 解釋說，仲裁需要超過叢集最後已知成員數量的一半；因此，一個三節點叢集可以容忍一個節點遺失，但不能容忍兩個節點遺失。請參閱其仲裁和恢復指南。

3. 為 Nextcloud 提供一個具有健康感知功能的資料庫端點

配置 Nextcloud 連接到穩定的資料庫代理位址，而不是 Galera IP 位址的輪詢清單。儘管 Galera 會在叢集中複製寫入操作，但應用程式仍需要可預測的事務處理。監控 Galera 成員關係的代理可以停止路由到不可用或未同步的節點，並選擇一個寫入節點。 MariaDB MaxScale 的Galera Monitor是一個已記錄的選項；其具體行為和支援的路由模式取決於 MaxScale 的版本和配置。

使用代理伺服器文件中記錄的連線端點作為 Nextcloud 的連線端點dbhost。為監控和應用程式存取建立單獨的、權限最小的帳戶，保護憑證，並在資料庫流量跨越不受信任的網路時對其進行加密。避免將讀取/寫入分離作為提升效能的捷徑：Nextcloud 本身的複製功能會將讀取操作傳送到副本，同時將寫入和因果讀取操作保留在預設連線上，但 Galera 並非普通的非同步副本架構。使用專門針對您的技術棧進行過測試的路由設計。

4. 確保每個應用節點都連接到同一個 Nextcloud 實例

在每個應用程式伺服器上安裝相同的 Nextcloud 程式碼和應用程式集。保持config.php共用執行個體中每個節點的配置一致，包括資料庫端點、金鑰值、受信任域和資料目錄路徑。不要在多個節點上獨立運行升級。首先進行備份，將執行個體置於維護模式，透過單一受控路徑進行升級，並在所有節點運行相同版本後才恢復流量。

配置所有應用節點使用相同的 Redis 或 Valkey 服務進行分散式快取和鎖定。本機快取（例如 APCu）可以保持節點本地化，但memcache.distributed必須memcache.locking指向一個公共服務，而不是每個伺服器各自的服務localhost。例如，Nextcloud 的 Redis 配置可以使用'memcache.locking' => '\OC\Memcache\Redis'共用的 Redis 主機redis。請遵循目前的快取配置指南和事務性文件鎖定指南。 Memcached 不適用於 Nextcloud 的事務性檔案鎖定。

如果您也將 PHP 會話集中儲存在 Redis 中，請將其視為單獨的 PHP 配置任務。 Nextcloud 的手冊警告說，預設情況下 Redis 會話處理程序未啟用會話鎖定；請套用其鎖定設定並測試會話行為後再使用。請勿將資料庫複製或檔案鎖定與會話連續性混淆。

5. 在稱為高可用性之前，務必先測試故障轉移。

首先透過公共主機名稱確認正常使用：登錄，上傳並下載測試文件，並檢查請求到達另一個應用節點後該文件是否可見。然後清空一個 Web 節點，並確認請求繼續通過另一個節點。還原該節點，並確認其重新加入後不會提供過時的程式碼或配置版本。

接下來，根據供應商的操作手冊，利用維護視窗模擬一個資料庫節點故障。確認代理伺服器已移除故障或未同步的成員，Nextcloud 仍可進行讀寫操作，且復原的節點Synced在接受流量前已到達。監控 Galera 主節點狀態、叢集大小、節點同步、代理伺服器運作狀況、應用程式錯誤以及儲存掛載運作狀況。

法定人數遺失是一種安全措施，並非資料遺失的證明。請勿強制引導多個節點或隨機選擇節點。 MariaDB 的復原指南建議，應確定最先進的節點，僅引導該節點，然後再將其他節點重新加入。同時，請確認您已測試資料庫和檔案儲存備份；Galera 複製會鏡像資料庫更改，不會取代時間點備份。

驗證結果

只有當移除一個應用節點和一個資料庫節點後，正常的文件操作仍能正常運行，所有倖存的 Galera 節點仍保留在主元件中，且共用檔案儲存和 Redis 或 Valkey 服務保持可存取時，該設定才可用於生產環境。如果測試失敗，請在變更逾時或重試設定之前，請確定哪個層停止處理請求。 Nextcloud 手冊記錄了其支援的資料庫和應用程式設置，而供應商相容性矩陣和您的故障轉移測試則決定此特定 Galera 部署是否受支援。