Was wir tun · Daten und Web: Datenbankreplikation und Offsite-Replikate
Eine laufend aktualisierte, schreibgeschützte Kopie Ihrer Produktionsdatenbank an einem anderen Standort, auf der Berichte laufen können, ohne die Produktion zu berühren, und auf die Sie umschalten können, falls der primäre Standort je verloren geht. So gebaut, dass das Replikat die Änderungen selbst abholt und die Produktion nie einen Weg zu ihm hat.
Was es ist
Asynchrone MySQL- oder MariaDB-Replikation, mit dem Replikat an einem Ort, den ein anderer Ausfall nicht erreichen kann: ein anderes Rechenzentrum, ein anderes Storage-Array, ein anderer Netzwerkpfad. Das Replikat folgt dem Primary nahezu in Echtzeit und erfüllt drei Aufgaben zugleich:
- Eine Disaster-Recovery-Kopie der Daten, auf Sekunden aktuell.
- Ein Ziel für Reporting und Integrationen, damit schwere Lesejobs nicht länger mit Ihren Kunden konkurrieren.
- Eine saubere Quelle für Backups, erstellt ohne den Primary zu sperren oder zu bremsen.
Wie wir es bauen
Das Replikat zieht. Replikationsverbindungen werden vom Replikat geöffnet, nie umgekehrt. Die Produktion hat keinen Netzwerkpfad zur Replikatseite, durchgesetzt auf den Firewall-Appliances, nicht durch eine Host-Regel, die jemand abschalten kann. Sollte ein Produktionsserver je kompromittiert werden, hat der Angreifer keine Route zu der Kopie, aus der Sie wiederherstellen würden.
Über unser privates Mesh. Offsite-Replikate reisen über unser verschlüsseltes privates Backbone zwischen unseren Rechenzentren in Athen, Amsterdam und Toronto, nie unverschlüsselt über das öffentliche Internet.
GTID-basiert. Wir verwenden globale Transaktionskennungen, damit ein Replikat umgehängt, befördert oder neu aufgesetzt werden kann, ohne dass jemand um drei Uhr morgens nach Binlog-Koordinaten sucht.
Überwacht nach Zustand, nicht nach Rauschen. Alle fünf Minuten läuft eine Prüfung und meldet genau einen Alarm, wenn sich der Zustand ändert: über der Schwelle verzögert, unterbrochen oder wiederhergestellt. Ingenieure bekommen ein Signal, auf das sie handeln, keinen Strom, den sie zu ignorieren lernen.
Wovor es Sie schützt
- Einen ganzen Standort zu verlieren und mit ihm die einzige Kopie Ihrer Daten.
- Reporting-Abfragen und Integrationen, die die Datenbank bremsen, die Ihre Kunden gerade nutzen.
- Ein Replikat, das vor Wochen still stehen geblieben ist und erst an dem Tag auffällt, an dem Sie es brauchen.
- Einen Angreifer auf einem Produktionsserver, der die Kopie erreicht, aus der Sie wiederherstellen würden.
- Backups, die während ihres Laufs Tabellen sperren oder den Primary anhalten.
In der Praxis
Der Umzug eines Senders weg von VMware. Als wir die Webplattform eines überregionalen Senders auf unserer OLVM Private Cloud neu aufgebaut haben, war die Datenbank die einzige Ebene mit Zustand, der sich zu übertragen lohnte. Sie reiste per GTID-Replikation von der alten Plattform zur neuen, sodass der Cutover selbst eine Beförderung mit Sekunden Differenz war. Der Cutover wurde vor Monaten abgeschlossen, und die Plattform läuft seither auf unserer Seite.
Replikate, die neue Anwendungen bedienen. Ein Lesereplikat ist auch der sauberste Weg, ein neues Such-, Reporting- oder Portal-Frontend auf ein bestehendes System zu setzen: Die neue Anwendung liest mit lokaler Netzwerkgeschwindigkeit und berührt den Primary beim Seitenaufbau nie. Wir bauen diese Replikate so, dass das Replikat die Verbindung initiiert, sodass der Host mit dem Replikat keine eingehende Firewall-Regel braucht.
Warum EuroVPS
- Replikate liegen an einem wirklich anderen Standort, verbunden über unser eigenes verschlüsseltes Backbone.
- Pull-only, durchgesetzt von der Firewall: Die Produktion kann die Replikatseite nie erreichen.
- Alarmierung bei Zustandswechsel alle fünf Minuten, rund um die Uhr von Ingenieuren gelesen.
- GTID durchgehend, damit Beförderung und Neuaufsetzen geprobte Abläufe sind.
- Dasselbe Team baut das Replikat, die Backups und den Failover-Plan, damit alles zusammenpasst.
Häufige Fragen
- Wie weit hinkt das Replikat hinterher? Unter normaler Last Sekunden oder weniger. Wir alarmieren, wenn die Verzögerung eine mit Ihnen vereinbarte Schwelle überschreitet, und der RPO, den Sie bekommen, folgt dem bestellten Service.
- Können wir auf das Replikat umschalten? Ja. Die Beförderung ist ein dokumentierter Ablauf. Wie schnell Anwendungen folgen, hängt vom Service-Design ab, von einer manuellen Beförderung bei einem Basis-Service bis zum automatisierten, geprobten Switchover bei global abgedeckten Services.
- Kann sich unser Reporting-Tool damit verbinden? Ja, mit einem schreibgeschützten Konto. Das ist einer der Hauptgründe, es zu haben.
- Ersetzt es Backups? Nein. Ein Replikat kopiert Fehler so treu wie Daten. Backups werden daneben erstellt und auf separate Infrastruktur abgeholt.
- MySQL oder MariaDB? Beides. Wir passen Engine und Einstellungen des Replikats an den Primary an.
Möchten Sie eine Kopie Ihrer Daten, die ein schlechter Tag nicht erreichen kann? 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.