Was wir tun · Daten und Web: Geclusterte Datenbanken mit Percona XtraDB Cluster
Ihre Anwendung spricht mit einer Datenbank, aber dahinter stehen drei synchrone Kopien, jede auf eigener Hardware. Ein committeter Schreibzugriff existiert auf jedem Knoten, bevor Ihre Anwendung «OK» hört. Einen Server zu verlieren, zu patchen oder neu zu starten ist deshalb Routinearbeit, kein Ausfall.
Was es ist
Percona XtraDB Cluster ist MySQL-kompatibel und baut auf der synchronen Replikation von Galera auf. Ihre Anwendung in WordPress, Magento, PrestaShop, Laravel oder individuellem PHP spricht weiter einfaches MySQL. Was sich ändert, liegt darunter: Es gibt keinen einzelnen Datenbankserver mehr, dessen Ausfall die ganze Website mit sich nimmt.
Wir kombinieren das Cluster mit ProxySQL, das Schreibzugriffe an einen gewählten Knoten schickt und Lesezugriffe auf alle verteilt. Die Anwendung braucht weder Änderungen noch Kenntnis der Topologie.
Wie wir es bauen
- Drei Knoten, drei Failure Domains. Jeder Knoten läuft auf einem eigenen Blade oder einer eigenen virtuellen Maschine, und wo die Plattform es erlaubt, bootet jeder von einem anderen Storage-Array und speichert dort seine Daten. Ein Host-Ausfall oder ein Array-Ausfall kostet ein Replikat, nie das Quorum.
- ProxySQL als lokaler Sidecar auf jedem Web-Knoten. Es gibt keinen gemeinsamen Datenbank-Load-Balancer, der zum nächsten Single Point of Failure wird. Der Galera-fähige Health Monitor von ProxySQL verfolgt den Clusterzustand, und fällt der Writer aus, befördert er binnen Sekunden einen neuen.
- Causal Reads für Redaktionen. Wir aktivieren synchrone Leseprüfungen, damit ein Redakteur, der auf einem Knoten speichert und von einem anderen neu lädt, immer seine eigene Änderung sieht. Keine Tickets der Art «mein Artikel ist verschwunden».
- Platz zum Wiedereintritt. Der Write-Set-Cache ist so dimensioniert, dass ein Knoten für Stunden Wartung offline sein und inkrementell wieder beitreten kann, statt den gesamten Datenbestand zurückzukopieren.
- Backups alle dreißig Minuten. Percona XtraBackup erstellt heiße, konsistente physische Backups, die komprimiert und von einem separaten Backup-Host abgeholt werden. Die Produktionsseite pusht nie in die Backup-Infrastruktur.
- Laufend überwacht. Jeder Knoten ist in Percona Monitoring and Management.
Auf OpenShift gelten dieselben Regeln
Läuft die Datenbank auf OpenShift oder OKD, läuft sie als StatefulSet mit harter Anti-Affinity über Chassis hinweg und mit einem PodDisruptionBudget, das das Quorum intakt hält. Ein rollierender Knoten-Reboot durch ein Plattform-Update kann so nie mehr als ein Datenbankmitglied gleichzeitig herunterfahren. Das ist der Designstandard, nach dem wir auf jeder Container-Plattform bauen, kein optionales Extra.
Wovor es Sie schützt
- Der klassische Ausfall: Die ganze Website ist down, weil der eine MySQL-Server down ist.
- Deadlock-Stürme durch Schreibzugriffe auf alle Knoten gleichzeitig, wie sie naive Round-Robin-Aufbauten unter WordPress- und E-Commerce-Plugin-Last erzeugen.
- Redakteure, die eine Speicherung verlieren, weil ihr nächster Lesezugriff auf einem Knoten landete, der sie noch nicht angewendet hatte.
- Wartungsfenster für Kernel-Updates, Datenbank-Patches und Hardware-Arbeiten.
- Ein Storage-Array oder ein Chassis, das die Datenbank mit sich nimmt.
- Ein Rolling Update von Kubernetes, das still das Quorum bricht.
In der Praxis
Eine Analytics-Plattform. Für die Analytics- und Transaktionsplattform eines Kunden haben wir die transaktionale Ebene auf Percona XtraDB Cluster mit ProxySQL und einer Floating-Adresse gebaut. Vor der Übergabe haben wir den Writer absichtlich entfernt; ProxySQL verlagerte die Schreibzugriffe auf einen überlebenden Knoten und die Anwendung lief weiter.
Warum EuroVPS
- Wir entwerfen die Failure Domains, nicht nur das Cluster: verschiedene Hosts, verschiedene Arrays, verschiedene Chassis.
- Kein gemeinsamer Datenbank-Proxy in der Mitte. Jeder Web-Knoten routet seine eigenen Queries.
- Backups sind physisch, häufig und werden von der Backup-Seite abgeholt, nie aus der Produktion gepusht.
- Wir testen das Failover vor der Übergabe, mit der laufenden Anwendung des Kunden darauf.
- Dieselbe Disziplin auf virtuellen Maschinen, Bare Metal und OpenShift.
Häufige Fragen
- Müssen wir unsere Anwendung ändern? Nein. ProxySQL präsentiert einen normalen MySQL-Endpunkt. Anwendungen, die in nicht transaktionale Tabellen schreiben oder auf ungewöhnliches Locking setzen, prüfen wir zuerst mit Ihnen.
- Ist es MySQL- oder MariaDB-kompatibel? Percona XtraDB Cluster ist ein MySQL-kompatibler Server. Wir migrieren MySQL- und MariaDB-Datenbanken darauf und prüfen beim Umzug Zeichensätze, Authentication-Plugins und SQL-Modi.
- Macht die synchrone Replikation über drei Knoten Schreibzugriffe langsamer? Jeder Commit wartet, bis die anderen Knoten ihn zertifiziert haben, also zählt die Latenz zwischen den Knoten. Deshalb sitzen alle Mitglieder in derselben Fabric mit niedriger Latenz in einem Rechenzentrum, und Offsite-Kopien übernehmen asynchrone Replikate.
- Können wir es innerhalb von OpenShift betreiben? Ja, als StatefulSet mit Anti-Affinity über Chassis hinweg und einem PodDisruptionBudget, unser Standard für jede quorumbasierte Datenbank auf Kubernetes.
- Was passiert bei einem Knotenausfall? Die überlebenden Knoten halten das Quorum und bedienen weiter. ProxySQL routet um den fehlenden Knoten herum, und wenn er zurückkehrt, holt er inkrementell auf.
Möchten Sie eine Datenbank, die den Verlust eines Servers wegsteckt? Sprechen Sie mit einem Ingenieur.
Ihr nächster Infrastrukturpartner
Sehen wir uns Ihre Umgebung an.
Erzählen Sie uns, was Sie heute betreiben und was besser werden muss. Ein Ingenieur sieht Ihre Anfrage durch und hilft Ihnen, den nächsten Schritt zu planen.
+357 222 32280
Beginnen wir mit Ihrer Umgebung.
Ein wenig Kontext hilft uns, das richtige Gespräch zu beginnen.