如何使用 Galera 資料庫設定 Nextcloud 高可用性集群

使用 Galera 實作 Nextcloud 高可用性部署是一個協調的系統，而不僅僅是三個資料庫伺服器。您還需要冗餘的 Nextcloud 應用節點、共享且持久的檔案資料層、分散式快取和檔案鎖定、負載平衡、監控以及經過測試的備份。 Galera 可以在資料庫節點發生故障後，在仲裁仍然有效的情況下保持資料庫服務的可用性，但它無法為您實現其他元件的高可用性。

本指南採用廠商中立的 Linux 設計，使用 MariaDB Galera 和反向代理或負載平衡器。軟體包名稱、服務名稱、Galera 提供者路徑、引導命令和代理健康檢查整合因發行版和 MariaDB 版本而異。部署前，請務必參考確切的版本文件進行確認。 Nextcloud 目前穩定版管理手冊推薦使用 PostgreSQL 和 MariaDB 作為資料庫引擎，並提醒使用者支援的版本可能有所不同；請查看您計劃運行的Nextcloud版本的系統需求。本文已於 2026 年 10 月 6 日依據 Nextcloud 35 穩定版手冊進行審核。

概念架構包括冗餘負載平衡器和 Web 節點，連接到三節點 Galera 資料庫、共享儲存和分散式快取。 — Nextcloud 高可用性堆疊的完整概念概述。每個有狀態依賴項都需要自己的可用性計劃。

首先選擇合適的可用性設計。

Galera 是一種適用於 MySQL 相容伺服器的同步多主複製方案。事務會在整個叢集中進行認證，這有助於保持成員資料的一致性，但同時也會增加協調開銷，並且衝突的事務可能會被拒絕。新增資料庫節點並不會自動提升 Nextcloud 的吞吐量。 Nextcloud 的開發者指南指出，叢集會帶來效能開銷，且資料庫和儲存仍然是關鍵的共享資源。

設計選擇	非常合身	主要權衡
一台 MariaDB 或 PostgreSQL 伺服器	需要最簡單操作的小型部署	資料庫維護或故障可能會中斷服務。
MariaDB 與 Galera	需要資料庫節點冗餘並能執行仲裁、網路、代理和復原程序的團隊	更多環節，更複雜的協調、衝突處理與復原工作。
兩個資料庫節點加一個仲裁器	擁有兩個資料庫主機但使用單獨的故障域進行法定人數投票的站點	仲裁員協助達到法定人數；它不儲存數據，也不取代第三方資料庫副本。
Galera 位於資料庫感知代理之後	需要穩定連接端點和受控路由的部署	代理健康檢查和路由規則成為另一項需要運作的服務。

對於新部署，如果運維團隊能夠提供支持，跨獨立主機的三節點 Galera 叢集通常是一個不錯的起點。 Galera 的仲裁機制需要多數節點：雙節點叢集在失去一個成員後無法自動安全地進行故障轉移。三節點叢集則可以容忍一個成員不可用，而其他兩個成員仍保持連線。盡可能將節點部署在不同的故障域中，但切勿在未進行測試的情況下，將同步複製擴展到高延遲連結。對於複雜度較低的環境，建議使用受支援的單一資料庫，並配合經過充分測試的備份和復原方案。

安裝之前：先確定「高可用性」的含義

列出您計劃應對的故障：Web 進程、Web 主機、資料庫主機、負載平衡器、儲存端點、網路路徑或整個網站。為每種故障設定恢復目標。包含三個資料庫節點和一個負載平衡器的設計並非完全冗餘。同樣，使用者檔案僅存在於單一 Web 伺服器本機磁碟上的應用程式叢集也並非完全冗餘。

在每個應用節點上使用一致的 Nextcloud 版本、PHP 執行時期、應用程式集和設定。選擇彼此相容且受所選 Nextcloud 版本支援的 MariaDB 和 Galera 版本。 Nextcloud 資料庫需求包括 InnoDB、READ COMMITTED 交易隔離以及停用二進位日誌或 ROW 格式；切勿在未檢查目前要求的情況下從其他版本複製調優值。

基於角色的主機清單，以空白的軟體管理表表示，其中包含 Web 伺服器、資料庫伺服器、快取伺服器和儲存伺服器圖示。 — 安裝軟體包之前，請先規劃好獨立的 Web、資料庫、快取和儲存角色。此示意圖並非即時庫存介面。

分 12 個階段搭建集群

1. 預留主機名稱、位址和服務端點

為每個資料庫成員、每個 Web 節點、快取服務、共用儲存和公用 Web 端點建立私人 DNS 名稱或穩定位址。為 Nextcloud PHP 節點預留一個單獨的穩定資料庫端點。在基礎設施允許的情況下，將應用程式流量、複製流量和公共流量保持在適當分離的網路路徑上。節點名稱必須唯一，且叢集中的每個成員都必須能夠一致地解析 Galera 對等體。

2. 安裝相容的資料庫和 Galera 版本

使用適用於您作業系統的供應商倉庫安裝 MariaDB 伺服器和 Galera 提供者。確保所有成員使用相同的主伺服器和提供者係列。不要將任意社群軟體包與單獨下載的提供者庫混合使用。在繼續操作之前，請確認該軟體包集支援的升級路徑、SST 方法、服務單元和組態包含目錄。

3. 應用 Nextcloud 的資料庫需求

將伺服器配置為使用 InnoDB 資料庫，並將交易隔離等級設定為 READ COMMITTED。如果啟用了二進位日誌記錄，請使用 ROW 二進位日誌記錄。重新啟動伺服器後，請檢查生效值，而不是假設設定檔已包含在內。 Nextcloud 在其資料庫配置指南和系統要求中記錄了這些要求。

一個通用的配置編輯器，包含中性設定行和一個選定行，沒有產品特定的標籤或值。 — 將每個 Galera 配置視為節點特定的配置，並在重新啟動 MariaDB 之前驗證套件特定的選項名稱。

4. 在所有三個成員上對 Galera 進行一致的配置

請使用供應商提供的設定參考文件來設定叢集名稱、對等節點位址清單、每個節點的唯一名稱和位址、提供者庫以及狀態快照傳輸 (SST) 方法。 SST 是將資料庫狀態配置到加入的節點的過程。典型的 MariaDB 叢集配置包含以下一系列選項：

[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTED

更改每台伺服器上的節點特定值。提供程式路徑和支援的 SST 方法取決於已安裝的軟體包；請使用適用於您版本的文件中記錄的方法和憑證。將 SST 憑證、憑證和資料庫密碼作為機密資訊加以保護。切勿將空集群位址用作永久設定：MariaDB 文件指出，這樣做可能會導致伺服器啟動一個新集群，而不是重新加入現有集群。

5. 將網路存取權限限制在必要的對等節點。

僅允許 Web 層存取資料庫服務端點，並允許資料庫成員透過您選擇的提供者和 SST 方法所需的 Galera 複製和狀態傳輸連接埠相互存取。常見的 Galera 部署使用 TCP，並且根據提供者設置，也可能使用 UDP 進行群組通訊；相關的預設值通常包括用於複製的 4567 連接埠、用於增量狀態傳輸的 4568 連接埠和用於狀態快照傳輸的 4444 連接埠。請將這些連接埠視為檢查清單，以核對您的版本和配置，而不是隨意開放所有連接埠的理由。請將 SQL 連接埠設為私有，並拒絕公用存取。

抽象的網路存取矩陣，顯示了 Web、資料庫、快取和儲存層之間有限的連線。 — 限制東西向訪問，僅允許必要的應用程式和 Galera 流量；不要公開資料庫或複製連接埠。

6. 先啟動第一個節點，再加入其他節點。

使用發行版 MariaDB 軟體包中記錄的引導程式初始化叢集一次。確認第一個成員構成主元件後，正常啟動其餘成員，使它們加入主元件並透過 IST 或 SST 接收狀態。 IST 會在可用時傳送缺少的寫入集；SST 會進行完整的狀態傳送。不要單獨引導每個主機，也不要將重啟視為引導操作。

在資料庫加入後，對每個資料庫成員執行以下查詢：

SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
 'wsrep_connected','wsrep_local_state_comment');

確認每個節點均已連接並準備就緒，屬於主組件，報告預期群集大小，並已達到同步狀態。 MariaDB 在其Galera 監控指南中解釋了這些指標。

三個資料庫節點以法定人數拓撲結構連接，以中性圖的形式顯示，不涉及任何健康聲明。 — 一個三投票拓樸結構在一個節點發生故障後，只要剩餘成員能夠通信，就能維持多數席次。

7. 建立專用的 Nextcloud 資料庫和最小權限帳戶

使用目前 Nextcloud 安裝指南中要求的字元集和排序規則建立資料庫。建立一個專用的資料庫用戶，該用戶僅限訪問應用程式網絡，並且僅授予 Nextcloud 設定和正常運作所需的權限。對於跨主機或不受信任的網路區段的連接，請使用 TLS，並在部署支援的情況下驗證憑證。請勿在資料庫設定中放入 root 使用者憑證config.php。

8. 部署相同的 Nextcloud 應用節點

在每個 Web 節點上安裝相同的 Nextcloud 程式碼版本、PHP 擴充功能、已啟用的應用程式和伺服器設定。配置一個共享資料庫端點，而不是在每個節點的設定檔中配置不同的資料庫主機。所有節點必須使用相同的實例 ID、金鑰、鹽值、受信任域策略和其他實例級設定。將配置儲存在受控的共用部署流程中，或以安全的方式分發，以確保更新保持一致。

用戶檔案資料層也需要與應用程式節點共用。請使用受支援的共享檔案系統或主物件儲存設計，並確保其與您的 Nextcloud 版本和運行要求相符。如果使用者資料僅儲存在一個 Web 主機上，則無法實現故障轉移：路由到其他主機的請求將無法存取相同的檔案。請確保應用程式程式碼和可寫入資料路徑彼此獨立，並在生產環境部署前驗證檔案鎖定和儲存語義。

Nextcloud 通常會在安裝過程中建立資料庫設定。資料庫端點和共用儲存準備就緒後，請檢查每個節點是否解析相同的值。一個典型的設定片段如下所示；請將真實憑證保存在受保護的金鑰管理工作流程中，切勿將此片段直接貼上到現有的生產配置中：

'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => 'redis.internal',
  'port' => 6379,
  'password' => 'REPLACE_WITH_SECRET',
],

根據您 Nextcloud 版本支援的選項，選擇合適的快取後端和資料目錄。安裝並配置所需的 PHP 擴充功能（如適用）。

兩個 Web 節點指向通用視窗中的同一個共用應用程式配置儲存。 — 每個應用程式節點都必須使用相同的 Nextcloud 實例設置，包括其共用金鑰和資料庫配置。

9. 新增分散式快取和檔案鎖定服務

如果合適，請使用 APCu 進行本機主機快取；對於分散式快取和事務性檔案鎖定，請使用 Redis 或 Valkey 等共享的 Redis 相容服務。所有 Web 節點必須指向同一個快取服務或受支援的快取集群，而不是 localhost。 Nextcloud 文件中提供了叢集設定下的 Redis 叢集配置，並指出事務性檔案鎖定預設依賴於資料庫。在適當情況下，請使用網路限制、身份驗證和 TLS 來保護快取；快取的可用性和故障轉移行為需要單獨設計。

兩個 Web 伺服器連接到共享的類似 Redis 的快取服務，以抽象服務圖的形式顯示。 — 叢集式 Nextcloud 部署需要 Web 節點使用相同的分散式快取和檔案鎖定服務。

10. 在 Galera 前端新增一個支援資料庫的端點

將 Nextcloud 指向由資料庫代理或其他支援的路由層提供的穩定端點。代理應停止向不在主元件中、未同步或未就緒的節點發送新連線。基本的 TCP 連接埠檢查只能證明套接字接受連接，並不能證明 Galera 可以安全地為應用程式提供服務。請檢查所選代理的健康檢查行為和故障模式。如果您使用簡單的 TCP 負載平衡器，請將其與可靠的 Galera 就緒檢查和保守的路由規則結合使用。

不要隨意添加讀/寫分離或輪詢路由。 Nextcloud 的開發者手冊描述了主/副本連接支持，並警告說，如果資料尚未傳播或代理無法將事務性讀取操作保留在正確的節點上，則跨叢集路由讀取操作可能會導致一致性問題。首先使用穩定的、具備寫入能力的端點，對其進行測試，只有在充分了解一致性和支援方面的影響後，才引入專門的路由機制。

一個資料庫服務端點，將連線分發到三個 Galera 資料庫節點。 — 穩定的資料庫端點可對 Nextcloud 隱藏節點位址；代理健康邏輯必須考慮 Galera 的就緒狀態。

11. 新增冗餘 Web 負載平衡和可信任代理設定

在負載平衡器後至少部署兩個 Web 節點，並為負載平衡器本身使用獨立的可用性機制，例如託管服務、冗餘節點對或經過測試的虛擬 IP 設計。根據您的部署情況設定 TLS 終止、請求大小和逾時行為以及會話保持要求。查閱 Nextcloud 反向代理文件並設定trusted_proxies實際的代理位址；信任任意客戶端 IP 位址範圍會削弱客戶端 IP 的處理能力。

前端負載平衡器接收客戶端流量並將其導向至兩台 Web 伺服器。 — 冗餘的 Web 負載平衡器僅將流量路由到通過適當健康檢查的應用程式節點。

12. 謹慎推廣，然後測試故障和恢復情況。

首先在拓樸結構相同的測試環境中進行升級測試。根據升級流程的需要，將 Nextcloud 置於維護模式，對所有節點應用相同的應用程式版本，並在健康檢查通過後才將節點恢復服務。對於例行主機維護，每次只清空一個 Web 節點，並確認剩餘容量充足。使用 MariaDB/Galera 官方支援的滾動升級流程，針對特定版本進行資料庫升級；不要隨意照搬通用教學中的升級順序。

一台 Web 伺服器暫時隔離，而另一台應用程式節點仍與資料庫服務保持連線。 — 滾動維護會耗盡一個 Web 節點的資源，而另一個節點則繼續處理請求；容量必須足以滿足減少後的資源池。

使用已記錄且與應用程式一致的流程備份資料庫和使用者檔案資料層。確保配置、加密材料和金鑰可供授權的復原操作員存取。 Galera 副本並非備份：意外刪除和邏輯損壞可能會複製到每個成員。將備份儲存在叢集故障域之外，並定期執行復原演練。 Galera 在其叢集備份指南中記錄了狀態轉移和備份注意事項；請驗證您採用的任何流程是否支援您的 MariaDB 版本。

獨立的資料庫和檔案儲存備份流程，備份資料到達異地存檔，並具有復原路徑。 — 資料庫備份和 Nextcloud 檔案資料備份必須作為獨立的復原元件進行協調和復原測試。

客戶端請求透過 Nextcloud 存取資料庫叢集和共用文件，並包含歸檔和復原循環。 — 在將叢集視為生產就緒之前，請驗證登入、檔案操作、資料庫仲裁、節點故障轉移和備份復原。

根據工作量和團隊能力選擇合適的設計方案

當您需要資料庫節點冗餘、擁有多個故障域，並且能夠監控仲裁並實施受控復原時，Galera 是一個實用的選擇。但如果主要目標是簡化操作、資料庫工作負載主要由衝突寫入操作構成，或者團隊無法安全地應對仲裁遺失，那麼 Galera 可能就不太合適了。在這些情況下，採用更簡單、支援的資料庫部署方案（配備強大的備份功能）或託管資料庫服務，或許能夠提供更高的運作可靠性。

對於規模較小的自託管服務，首先應確保應用節點可互換，將用戶文件遷移到持久共享存儲，配置共享 Redis 鎖定，並測試備份。只有在測量結果顯示資料庫單節點故障或維護視窗的風險不可接受，且組織能夠維護額外的安全層之後，才應添加 Galera。真正有效的成功測試並非“所有三個資料庫伺服器都在運行”，而是在計劃內的節點故障期間 Nextcloud URL 仍然可用，跨 Web 節點的上傳和下載功能正常，資料庫保持法定人數，並且團隊能夠從備份中恢復資料庫和文件資料。