Eine Nextcloud-Hochverfügbarkeitsbereitstellung mit Galera ist ein koordiniertes System und besteht nicht nur aus drei Datenbankservern. Sie benötigen außerdem redundante Nextcloud-Anwendungsknoten, eine gemeinsam genutzte und robuste Dateidatenschicht, verteiltes Caching und Dateisperrung, Lastverteilung, Überwachung und getestete Backups. Galera kann den Datenbankdienst nach dem Ausfall eines Datenbankknotens aufrechterhalten, solange das Quorum vorhanden ist. Die Hochverfügbarkeit der anderen Komponenten kann Galera jedoch nicht gewährleisten.
Diese Anleitung verwendet ein herstellerneutrales Linux-Design mit MariaDB Galera und einem Reverse-Proxy oder Load Balancer. Paketnamen, Dienstnamen, Galera-Provider-Pfade, Bootstrap-Befehle und Proxy-Integritätsprüfungen variieren je nach Distribution und MariaDB-Version. Prüfen Sie diese vor der Bereitstellung anhand der Dokumentation der jeweiligen Version. Das aktuelle stabile Administrationshandbuch von Nextcloud empfiehlt PostgreSQL und MariaDB als Datenbank-Engines und weist darauf hin, dass die unterstützten Versionen variieren. Prüfen Sie daher die Nextcloud-Systemanforderungen für die von Ihnen geplante Version. Dieser Artikel wurde am 6. Oktober 2026 anhand des stabilen Handbuchs von Nextcloud 35 geprüft.
Galera ist eine synchrone Multi-Primär-Replikation für MySQL-kompatible Server. Transaktionen werden clusterweit zertifiziert, was die Konsistenz der Mitglieder gewährleistet, jedoch zusätzlichen Koordinationsaufwand verursacht und zu Transaktionskonflikten führen kann. Das Hinzufügen von Datenbankknoten erhöht den Nextcloud-Durchsatz nicht automatisch. Die Entwicklerrichtlinien von Nextcloud weisen darauf hin, dass Cluster einen Leistungsverlust verursachen und Datenbanken sowie Speicher weiterhin kritische, gemeinsam genutzte Ressourcen darstellen.
| Designwahl | Passt gut | Hauptkompromisse |
|---|---|---|
| Ein MariaDB- oder PostgreSQL-Server | Kleine Installationen, die die einfachsten Operationen benötigen | Datenbankwartung oder -ausfall können den Dienst unterbrechen |
| MariaDB mit Galera | Teams, die Datenbankknotenredundanz benötigen und Quorum-, Netzwerk-, Proxy- und Wiederherstellungsverfahren durchführen können | Mehr bewegliche Teile, Schreibkoordination, Konfliktbewältigung und Wiederherstellungskomplexität |
| Zwei Datenbankknoten plus ein Schiedsrichter | Websites mit genau zwei Datenbankhosts, aber einer separaten Ausfalldomäne für eine Quorumsabstimmung | Der Schiedsrichter trägt zur Sicherstellung des Quorums bei; er speichert keine Daten und ersetzt keine dritte Datenbankkopie. |
| Galera hinter einem datenbankfähigen Proxy | Bereitstellungen, die einen stabilen Verbindungsendpunkt und kontrolliertes Routing erfordern. | Proxy-Integritätsprüfungen und Routing-Regeln werden zu einem weiteren Dienst, der betrieben werden muss. |
Bei einer Neuinstallation ist ein Galera-Cluster mit drei Datenknoten auf unabhängigen Hosts ein gängiger Ausgangspunkt, sofern das Betriebsteam dies unterstützen kann. Galera benötigt ein Quorum: Ein Cluster mit zwei Knoten kann nach dem Ausfall eines Knotens nicht automatisch und sicher ausfallen. Drei Knoten können den Ausfall eines Knotens tolerieren, während die anderen beiden verbunden bleiben. Platzieren Sie Knoten nach Möglichkeit über Ausfallbereiche hinweg, aber testen Sie die synchrone Replikation nicht ohne vorherige Tests über Verbindungen mit hoher Latenz. In Umgebungen mit geringerer Komplexität empfiehlt sich eine unterstützte Einzeldatenbank in Kombination mit einem gut getesteten Backup- und Wiederherstellungsplan.
Notieren Sie die Ausfälle, deren Ausfall Sie tolerieren möchten: einen Webprozess, einen Webhost, einen Datenbankhost, einen Load Balancer, einen Speicherendpunkt, einen Netzwerkpfad oder eine komplette Website. Definieren Sie für jeden Ausfall Wiederherstellungsziele. Ein Design mit drei Datenbankknoten und einem Load Balancer ist nicht vollständig redundant. Ebenso wenig ein Anwendungscluster, dessen Benutzerdateien sich nur auf der lokalen Festplatte eines Webservers befinden.
Verwenden Sie auf jedem Anwendungsknoten dieselbe Nextcloud-Version, PHP-Laufzeitumgebung, dasselbe App-Set und dieselbe Konfiguration. Wählen Sie MariaDB- und Galera-Versionen, die miteinander kompatibel sind und von der gewählten Nextcloud-Version unterstützt werden. Die Nextcloud-Datenbankanforderungen umfassen InnoDB, READ COMMITTED-Transaktionsisolation und deaktiviertes Binärlogging oder ROW-Format. Kopieren Sie keine Tuning-Werte aus einer anderen Version, ohne die aktuellen Anforderungen zu prüfen.
Erstellen Sie private DNS-Namen oder stabile Adressen für jedes Datenbankmitglied, jeden Webknoten, den Cache-Dienst, den gemeinsam genutzten Speicher und den öffentlichen Web-Endpunkt. Reservieren Sie einen separaten stabilen Datenbank-Endpunkt für die Nextcloud-PHP-Knoten. Leiten Sie Anwendungs-, Replikations- und öffentlichen Datenverkehr – sofern Ihre Infrastruktur dies zulässt – über entsprechend getrennte Netzwerkpfade. Jeder Knotenname muss eindeutig sein, und jedes Clustermitglied muss die Galera-Peers konsistent auflösen können.
Installieren Sie MariaDB Server und den Galera-Provider mithilfe des für Ihr Betriebssystem empfohlenen Hersteller-Repositorys. Verwenden Sie auf allen Systemkomponenten dieselbe Hauptserver- und Providerfamilie. Kombinieren Sie keine beliebigen Community-Pakete mit einer separat heruntergeladenen Providerbibliothek. Prüfen Sie vor der Installation den unterstützten Upgrade-Pfad, die SST-Methode, die Service Unit und das Konfigurationsverzeichnis für das jeweilige Paketset.
Konfigurieren Sie den Server so, dass er InnoDB und die Transaktionsisolationsstufe READ COMMITTED verwendet. Aktivieren Sie die binäre Protokollierung (ROW), falls diese aktiviert ist. Überprüfen Sie die effektiven Werte nach einem Neustart, anstatt davon auszugehen, dass eine Konfigurationsdatei vorhanden ist. Nextcloud dokumentiert diese Anforderungen in seinem Datenbankkonfigurationsleitfaden und den Systemvoraussetzungen .
Verwenden Sie die Konfigurationsreferenz Ihres Anbieters, um den Clusternamen, die Liste der Peer-Adressen, den eindeutigen Namen und die Adresse jedes Knotens, die Provider-Bibliothek und die Methode für die Status-Snapshot-Übertragung (SST) festzulegen. SST ist der Prozess, der einem beitretenden Knoten den Datenbankstatus bereitstellt. Eine typische MariaDB-Clusterkonfiguration enthält Optionen dieser Art:
[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Ändern Sie die knotenspezifischen Werte auf jedem Server. Providerpfade und unterstützte SST-Methoden hängen von den installierten Paketen ab; verwenden Sie die dokumentierte Methode und die Anmeldeinformationen für Ihre Version. Schützen Sie SST-Anmeldeinformationen, Zertifikate und Datenbankpasswörter als Geheimnisse. Verwenden Sie niemals eine leere Clusteradresse als permanente Einstellung: MariaDB dokumentiert, dass dies dazu führen kann, dass ein Server einen neuen Cluster startet, anstatt dem bestehenden beizutreten.
Gewähren Sie der Webschicht ausschließlich Zugriff auf den Datenbankdienst-Endpunkt und ermöglichen Sie den Datenbankmitgliedern die Kommunikation untereinander über die von Ihrem gewählten Provider und der SST-Methode benötigten Galera-Replikations- und Statusübertragungsports. Gängige Galera-Bereitstellungen verwenden TCP und, abhängig von den Provider-Einstellungen, UDP für die Gruppenkommunikation. Die relevanten Standardports umfassen häufig 4567 für die Replikation, 4568 für die inkrementelle Statusübertragung und 4444 für die Status-Snapshot-Übertragung. Nutzen Sie diese Liste als Checkliste zur Überprüfung Ihrer Version und Konfiguration und nicht als Grund, alle Ports pauschal zu öffnen. Halten Sie den SQL-Port privat und verweigern Sie den öffentlichen Zugriff.
Initialisieren Sie den Cluster genau einmal mithilfe der Bootstrap-Prozedur, die in der Dokumentation Ihres MariaDB-Pakets beschrieben ist. Nachdem Sie bestätigt haben, dass das erste Mitglied die primäre Komponente bildet, starten Sie die übrigen Mitglieder normal, damit sie sich anschließen und ihren Status über IST oder SST erhalten. IST überträgt fehlende Schreibsätze, sofern verfügbar; SST führt eine vollständige Statusübertragung durch. Führen Sie keinen Bootstrap auf jedem Host einzeln durch und betrachten Sie einen Neustart nicht als Bootstrap-Aktion.
Führen Sie diese Abfrage auf jedem Datenbankmitglied nach dem Beitritt aus:
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Vergewissern Sie sich, dass jeder Knoten verbunden und bereit ist, zur primären Komponente gehört, die erwartete Clustergröße meldet und den synchronisierten Zustand erreicht hat. MariaDB erläutert diese Indikatoren in seinem Galera-Überwachungsleitfaden .
Erstellen Sie die Datenbank mit dem Zeichensatz und der Sortierung, die in der aktuellen Nextcloud-Installationsanleitung angegeben sind. Erstellen Sie einen dedizierten Datenbankbenutzer, der auf das Anwendungsnetzwerk beschränkt ist, und weisen Sie ihm nur die für die Nextcloud-Einrichtung und den normalen Betrieb erforderlichen Berechtigungen zu. Verwenden Sie TLS für Verbindungen zwischen verschiedenen Hosts oder nicht vertrauenswürdigen Netzwerksegmenten und validieren Sie Zertifikate, sofern Ihre Bereitstellung dies unterstützt. Speichern Sie keine Root-Anmeldeinformationen in der Datenbank config.php.
Installieren Sie auf jedem Webknoten dieselbe Nextcloud-Codeversion, dieselben PHP-Erweiterungen, aktivierten Apps und dieselbe Serverkonfiguration. Konfigurieren Sie einen gemeinsamen Datenbankendpunkt und nicht unterschiedliche Datenbankhosts in knotenspezifischen Dateien. Alle Knoten müssen dieselbe Instanz-ID, dasselbe Secret, dieselben Salts, dieselbe Trusted-Domain-Richtlinie und dieselben anderen instanzweiten Einstellungen verwenden. Speichern Sie die Konfiguration in einem kontrollierten, gemeinsamen Bereitstellungsprozess oder verteilen Sie sie sicher, damit Aktualisierungen identisch bleiben.
Die Benutzerdateidatenschicht muss auf allen Anwendungsknoten gemeinsam genutzt werden. Verwenden Sie ein unterstütztes, gemeinsam genutztes Dateisystem oder ein unterstütztes primäres Objektspeicherdesign, das Ihrer Nextcloud-Version und Ihren Betriebsanforderungen entspricht. Lokale Benutzerdaten auf einem Webhost verhindern ein Failover: Eine an einen anderen Host weitergeleitete Anfrage würde nicht auf dieselben Dateien zugreifen. Trennen Sie Anwendungscode und beschreibbare Datenpfade und überprüfen Sie die Dateisperrung und Speichersemantik vor der Produktion.
Nextcloud erstellt seine Datenbankeinstellungen normalerweise während der Installation. Sobald der Datenbank-Endpunkt und der gemeinsam genutzte Speicher bereit sind, überprüfen Sie, ob jeder Knoten dieselben Werte auflöst. Ein typisches Konfigurationsfragment sieht wie folgt aus; bewahren Sie Ihre Zugangsdaten in einem geschützten Geheimnisverwaltungssystem auf und fügen Sie dieses Fragment nicht in eine bestehende Produktionskonfiguration ein:
'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',
],Passen Sie das Cache-Backend und das Datenverzeichnis an die unterstützten Optionen Ihrer Nextcloud-Version an. Installieren und konfigurieren Sie gegebenenfalls die erforderlichen PHP-Erweiterungen.
Verwenden Sie gegebenenfalls APCu für lokales Caching pro Host und einen gemeinsam genutzten, Redis-kompatiblen Dienst wie Redis oder Valkey für verteiltes Caching und transaktionale Dateisperrung. Alle Webknoten müssen auf denselben Cache-Dienst oder unterstützten Cache-Cluster zugreifen, nicht auf localhost. Nextcloud dokumentiert die Redis-Cluster-Konfiguration für Cluster-Setups und weist darauf hin, dass die transaktionale Dateisperrung standardmäßig auf der Datenbank basiert. Schützen Sie den Cache gegebenenfalls mit Netzwerkbeschränkungen, Authentifizierung und TLS; Cache-Verfügbarkeit und Failover-Verhalten erfordern ein separates Design.
Verbinden Sie Nextcloud mit einem stabilen Endpunkt, der von einem Datenbank-Proxy oder einer anderen unterstützten Routing-Schicht bereitgestellt wird. Der Proxy sollte keine neuen Verbindungen an Knoten senden, die nicht zur primären Komponente gehören, nicht synchronisiert oder nicht bereit sind. Eine einfache TCP-Portprüfung zeigt lediglich, dass ein Socket Verbindungen akzeptiert; sie beweist nicht, dass Galera die Anwendung sicher bedienen kann. Überprüfen Sie das Verhalten der Integritätsprüfung und die Fehlermodi des gewählten Proxys. Wenn Sie einen einfachen TCP-Loadbalancer verwenden, kombinieren Sie diesen mit einer zuverlässigen Galera-Bereitschaftsprüfung und konservativen Routing-Regeln.
Fügen Sie Lese-/Schreibaufteilung oder Round-Robin-Routing nicht leichtfertig hinzu. Das Entwicklerhandbuch von Nextcloud beschreibt die Unterstützung von Primär-/Replikatverbindungen und warnt davor, dass das Weiterleiten von Lesezugriffen über einen Cluster zu Konsistenzproblemen führen kann, wenn Daten nicht propagiert wurden oder ein Proxy transaktionale Lesezugriffe nicht auf dem richtigen Knoten halten kann. Beginnen Sie mit einem stabilen, schreibfähigen Endpunkt, messen Sie dessen Leistung und führen Sie spezialisiertes Routing erst dann ein, wenn Sie die Auswirkungen auf Konsistenz und Support vollständig verstehen.
Platzieren Sie mindestens zwei Webknoten hinter einem Load Balancer und verwenden Sie einen separaten Verfügbarkeitsmechanismus für den Load Balancer selbst, z. B. einen Managed Service, ein redundantes Paar oder ein getestetes Virtual-IP-Design. Konfigurieren Sie TLS-Terminierung, Anfragegröße, Timeout-Verhalten und Sticky-Session-Anforderungen entsprechend Ihrer Bereitstellung. Beachten Sie die Nextcloud-Reverse-Proxy-Dokumentation und verwenden Sie trusted_proxiesdie tatsächlichen Proxy-Adressen; das Vertrauen in beliebige Clientbereiche schwächt die Client-IP-Verarbeitung.
Testen Sie Upgrades zunächst auf einer Testumgebung mit derselben Topologie. Versetzen Sie Nextcloud bei Bedarf in den Wartungsmodus, installieren Sie auf jedem Knoten dieselbe Anwendungsversion und nehmen Sie die Knoten erst nach erfolgreichen Integritätsprüfungen wieder in Betrieb. Leeren Sie bei der routinemäßigen Host-Wartung jeweils einen Webknoten und prüfen Sie, ob die verbleibende Kapazität ausreicht. Führen Sie Datenbank-Upgrades gemäß dem unterstützten MariaDB/Galera-Rolling-Upgrade-Prozess für die jeweiligen Versionen durch; verwenden Sie keine allgemeingültige Anleitung.
Sichern Sie die Datenbank und die Benutzerdateidatenebene mithilfe eines dokumentierten, anwendungskonsistenten Verfahrens. Halten Sie Konfigurationsdateien, Verschlüsselungsmaterialien und Geheimnisse für autorisierte Wiederherstellungsbeauftragte bereit. Eine Galera-Replika ist keine Sicherung: Versehentliches Löschen und logische Beschädigungen können sich auf alle Mitglieder auswirken. Speichern Sie Sicherungen außerhalb des Ausfallbereichs des Clusters und führen Sie regelmäßig Wiederherstellungsübungen durch. Galera dokumentiert die Aspekte der Zustandsübertragung und Sicherung in seinen Richtlinien zur Clustersicherung ; stellen Sie sicher, dass jedes von Ihnen angewandte Verfahren Ihre MariaDB-Version unterstützt.
Galera ist eine sinnvolle Wahl, wenn Sie Datenbank-Knoten-Redundanz benötigen, mehrere Ausfallbereiche haben und das Quorum überwachen sowie eine kontrollierte Wiederherstellung durchführen können. Es eignet sich möglicherweise weniger, wenn das Hauptziel einfachere Operationen sind, die Datenbanklast hauptsächlich aus widersprüchlichen Schreibvorgängen besteht oder das Team nicht sicher auf einen Quorumverlust reagieren kann. In diesen Fällen kann eine einfachere, unterstützte Datenbankbereitstellung mit robusten Backups oder ein Managed-Database-Service eine höhere Betriebssicherheit bieten.
Bei einem kleineren, selbstgehosteten Dienst sollten Sie zunächst die Anwendungsknoten austauschbar machen, Benutzerdateien auf einen persistenten, gemeinsam genutzten Speicher verschieben, die gemeinsame Redis-Sperre konfigurieren und Backups testen. Galera sollte erst dann hinzugefügt werden, wenn Messungen zeigen, dass der Ausfall eines einzelnen Datenbankknotens oder ein Wartungsfenster ein inakzeptables Risiko darstellt und die Organisation die zusätzliche Ebene verwalten kann. Der aussagekräftige Erfolgstest besteht nicht darin, dass „alle drei Datenbankserver laufen“, sondern darin, dass die Nextcloud-URL auch bei einem geplanten Knotenausfall erreichbar bleibt, Uploads und Downloads zwischen den Webknoten funktionieren, die Datenbank das Quorum beibehält und das Team sowohl Datenbank- als auch Dateidaten aus dem Backup wiederherstellen kann.
Vergleichen Sie 10 Ping-Sweep-Tools für die schnelle LAN-Erkennung, plattformübergreifende Scans und IP-Adressverwaltung. Erfahren Sie, was ein Sweep liefern kann – und was nicht.
Vergleichen Sie sechs Netzwerkmanagement-Tools für die Leistungsüberwachung, einschließlich SNMP-Abdeckung, Mapping, Warnmeldungen, Bereitstellungsmodelle und Kosten-Nutzen-Verhältnisse.
Vergleichen Sie die besten Wi-Fi-Analyseprogramme für Windows, iPhone und Android, einschließlich Tools für Kanalüberlastung, Signalabdeckung, Heatmaps und Netzwerk-Fehlerbehebung.
Erfahren Sie, was QoS in der Netzwerktechnik bedeutet, wie DSCP-Markierungen und Datenverkehrswarteschlangen Sprach-, Video- und Geschäftsanwendungen priorisieren und was QoS nicht beheben kann.
Vergleichen Sie zuverlässige SFTP-Server-Software für Windows und Linux, darunter OpenSSH, Bitvise, SolarWinds und SFTPGo. Finden Sie die passende Lösung für Ihre Sicherheits- und Dateitransferanforderungen.
Vergleichen Sie 10 Tools zum Scannen und Analysieren drahtloser Netzwerke für Windows, iOS und Android mit klaren Hinweisen zu Wi-Fi-Kanälen, Abdeckungskarten, LAN-Prüfungen und Plattformbeschränkungen.
Erstellen Sie eine praktische Netzwerküberwachung mit klarer Geräteabdeckung, nützlichen Leistungskennzahlen, umsetzbaren Warnmeldungen und einem Vergleich von SolarWinds NPM, PRTG und OpManager.
Vergleichen Sie sieben IP-Adressverwaltungstools für Subnetzerkennung, DNS- und DHCP-Koordination, Netzwerkinventarisierung und Open-Source-IPAM.
Vergleichen Sie Netzwerk-Scanner-Tools für die schnelle Geräteerkennung, plattformübergreifende IP-Scans und Enterprise IPAM mit Hinweisen zur Auswahl der passenden Option für Ihr Netzwerk.
Verwenden Sie die Option --traceroute von Nmap, um Hops einem autorisierten Host zuzuordnen, die Hop- und RTT-Ausgabe zu verstehen und fehlende Antworten zu beheben, ohne übermäßig zu scannen.
