MySQL- und MariaDB-Datenbanken sichern und verfügbar halten

Was passiert, wenn der Datenbankserver ausfällt? Und lassen sich die Daten von gestern wirklich zurückholen? Wir betreiben MySQL und MariaDB mit Sicherungen, deren Wiederherstellung wir testen, mit Replikation und, wo es passt, mit einem Galera-Cluster. Langsame Abfragen und anstehende Updates gehören dazu.

  • MySQL und MariaDB seit 2012, auch im Galera-Cluster
  • Full Stack und DevOps seit 2012
  • Antwort innerhalb eines Werktags
Drei gleiche Datenbankserver in einer Reihe, miteinander verbunden, darunter eine Sicherung als Blatt, gestrichelt angebunden, daneben ein kleines oranges Häkchen

Wann sich ein Blick auf die Datenbank lohnt

Die Datenbank ist oft der Teil eines Systems, den niemand anfasst, solange er läuft. Typische Anlässe, das zu ändern:

  • Niemand weiß, ob sich die letzte Sicherung wirklich einspielen lässt.
  • Die Datenbank läuft auf einem einzigen Server. Fällt er aus, steht die Anwendung.
  • Seiten und Berichte werden langsamer, je mehr Daten dazukommen.
  • Die Version ist alt, und an das Update traut sich niemand heran.
  • Wer die Replikation eingerichtet hat, ist nicht mehr im Haus.

Diese Seite gehört zur Leistung Linux-Betrieb und Infrastruktur. Welche Datenbanken unsere Ingenieure kennen und wie wir zwischen ihnen migrieren, steht im Überblick zu Datenbanken.

Ein Datenbankzylinder, über eine Linie mit einer Messuhr verbunden; der Zeiger steht im orangen Bereich der Skala

Sicherungen, die sich wiederherstellen lassen

Eine Sicherung ist erst etwas wert, wenn sie sich einspielen lässt. Wir richten die Sicherungen passend zu Ihrer Datenbank ein und testen die Wiederherstellung regelmäßig:

  • vollständige Sicherungen im laufenden Betrieb, ohne die Anwendung anzuhalten
  • Binärlogs, mit denen sich je nach Einrichtung auch ein Stand kurz vor einem Fehler zurückholen lässt
  • Kopien außerhalb des Datenbankservers und außerhalb der Produktionszone
  • ein Wiederherstellungstest auf einem getrennten System, mit gemessener Dauer
  • eine Meldung, wenn eine Sicherung fehlschlägt

Das Ergebnis jedes Tests erhalten Sie schriftlich. So wissen Sie, wie alt die Daten nach einem Ausfall höchstens wären und wie lange die Wiederherstellung dauert.

Links eine Datenbank mit durchgezogenen Linien, rechts ihre gestrichelte Kopie; ein Pfeil oben führt zur Kopie, ein orangefarbener Bogenpfeil unten zurück zum Original

Sicherung, Replikation oder Cluster: Was schützt wogegen?

Frage Geprüfte Sicherung Replikation Galera-Cluster
Schützt vor Datenverlust durch Fehler, Löschen, Defekt oder Angriff, bis zum Stand der letzten Sicherung dem Ausfall des Hauptservers: Ein Replikat übernimmt nach dem Umschalten dem Ausfall eines Knotens: Die übrigen Knoten arbeiten weiter
Schützt nicht vor der Ausfallzeit, bis die Wiederherstellung abgeschlossen ist gelöschten Daten, denn das Löschen wird mitrepliziert. Bei asynchroner Replikation können die letzten Änderungen fehlen gelöschten Daten und fehlerhaften Updates, denn sie erreichen alle Knoten
Passt, wenn immer, als Grundlage jeder Lösung eine kurze Unterbrechung beim Umschalten tragbar ist oder Lesezugriffe verteilt werden sollen die Anwendung beim Ausfall eines Servers weiterlaufen muss und drei Server mit stabilem Netz bereitstehen

Galera-Cluster: wann er passt und was er nicht ersetzt

Ein Galera-Cluster verbindet mehrere MySQL- oder MariaDB-Server. Jede Änderung wird beim Speichern an alle Knoten übertragen, und jeder Knoten kann Anfragen beantworten. Fällt ein Server aus, arbeiten die anderen weiter. Unsere Ingenieure richten solche Cluster ein und betreiben sie.

Ein Cluster stellt aber Bedingungen: mindestens drei Knoten oder zwei mit einem Schiedsrichter, ein stabiles Netz und Tabellen mit InnoDB und Primärschlüssel. Große Transaktionen und viele gleichzeitige Schreibzugriffe auf dieselben Datensätze bremsen ihn. Oft reicht deshalb eine Replikation mit geplantem Umschalten. Das klären wir, bevor wir etwas aufbauen.

Und ein Cluster ersetzt keine geprüfte Sicherung. Er schützt vor dem Ausfall eines Servers, nicht vor gelöschten Daten. Deshalb planen wir die Sicherung immer mit.

Drei verbundene Datenbanken eines Clusters tragen alle dasselbe Kreuz, eine Löschung wird überallhin übertragen; die getrennte Sicherung rechts ist orange umrandet und trägt kein Kreuz

Langsame Abfragen und anstehende Updates

Wird die Anwendung langsamer, suchen wir die Ursache, bevor jemand einen größeren Server kauft. Wir werten die langsamsten Abfragen aus, lesen ihre Ausführungspläne, ergänzen fehlende Indizes und passen die Konfiguration an. Liegt die Ursache im Code, etwa bei sehr vielen kleinen Abfragen pro Seite, beheben wir sie dort. Unsere Ingenieure kennen dafür auch ColdFusion, Lucee und PHP.

Neue Hauptversionen von MySQL und MariaDB spielen wir zuerst auf einer Kopie ein und testen die Anwendung dagegen. Wo möglich, läuft der neue Server per Replikation neben dem alten mit. Umgeschaltet wird in einem mit Ihnen abgestimmten Zeitfenster, und der alte Stand bleibt als Weg zurück erhalten.

Ein Datenbankzylinder, daneben eine Stoppuhr und fünf waagerechte Balken unterschiedlicher Länge wie Abfragezeiten; der längste Balken ist orange

So gehen wir vor

  1. Datenbank-Check

    Wir prüfen Sicherungen, Replikation, Konfiguration und die langsamsten Abfragen. Die letzte Sicherung spielen wir testweise auf einem getrennten System ein. Den Befund erhalten Sie schriftlich.

  2. Plan

    Aus dem Befund wird eine Empfehlung mit Aufwand: bessere Sicherungen, eine Replikation oder ein Cluster, je nachdem, welchen Ausfall Ihre Anwendung verkraftet. Sie entscheiden, was umgesetzt wird.

  3. Umsetzung

    Wir bauen die Lösung zuerst neben der Produktion auf und testen sie mit einer Kopie der Daten. Umgeschaltet wird in einem abgestimmten Zeitfenster, mit Weg zurück.

  4. Betrieb

    Auf Wunsch betreuen wir die Datenbank danach im Rahmen des Linux-Betriebs: Überwachung von Sicherungen und Replikation, regelmäßige Wiederherstellungstests, Updates und ein Runbook für Ihr Team.

Der erste Schritt: Datenbank-Check mit Wiederherstellungstest

Datenbank-Check: MySQL und MariaDB

Für Unternehmen, deren Anwendung an einer MySQL- oder MariaDB-Datenbank hängt und die wissen wollen, was bei einem Ausfall passiert und ob sich die Daten von gestern wirklich wiederherstellen lassen.

  • Sicherungen: was gesichert wird, wie oft und wo die Kopien liegen
  • ein Wiederherstellungstest auf einem getrennten System, mit gemessener Dauer
  • Replikation und Ausfallsicherheit: was es gibt und was fehlt
  • die langsamsten Abfragen und fehlende Indizes
  • Version, Support-Stand und Konfiguration
  • Empfehlung: Sicherung, Replikation oder Cluster, je nach Bedarf

Ein Cluster wie MariaDB Galera schützt vor dem Ausfall eines Servers, nicht vor gelöschten Daten. Dafür braucht es geprüfte Sicherungen. Deshalb beginnen wir mit dem Wiederherstellungstest. Auf welchem System er läuft, legen wir mit Ihnen fest. An Ihrer Produktivdatenbank ändern wir nichts.

Was das Ergebnis enthält

Ein schriftlicher Befund mit dem Ergebnis des Wiederherstellungstests, den Risiken nach Priorität und einer Empfehlung mit Aufwand. Der Befund gehört Ihnen. Auf Wunsch richten wir die Lösung danach ein, auch einen Galera-Cluster.

ab 1.900 € zzgl. USt.

In der Regel 2 Werktage

Datenbank-Check anfragen

Aus unseren Projekten

  • Eine Tabelle aus Zeilen mit einem langen Pfeil über alle, beschriftet ALL, und einem orangen Pfeil von einer Indexkarte zu einer einzigen Zeile, beschriftet ref

    SQL-Indizes in einer Shop-Datenbank: von Full Scans zu Mikrosekunden

    Eine Shop-Datenbank ohne Indizes funktionierte, solange die Tabellen klein waren. Bei 500 000 Bestellungen und 1,75 Millionen Positionen lief jeder Filter und jeder Join auf einen Full Scan hinaus. Wir haben genau gemessen, was die fehlenden Indizes kosten, die richtigen angelegt und die Fallen dokumentiert, durch die ein Index nutzlos bleibt, obwohl er existiert.

Fragen zu Sicherung, Replikation und Cluster

Wie prüfen Sie, ob sich unsere Daten wiederherstellen lassen?

Wir spielen die letzte Sicherung auf einem getrennten System ein, das wir mit Ihnen festlegen, nicht auf dem Produktivserver. Dabei messen wir, wie lange die Wiederherstellung dauert. Danach prüfen wir, ob die Datenbank vollständig ist: Tabellen, Anzahl der Datensätze, Stichproben aus wichtigen Daten und, wenn möglich, der Start der Anwendung gegen die Kopie.

Das Ergebnis halten wir schriftlich fest, auch wenn etwas fehlt. Im laufenden Betrieb wiederholen wir den Test regelmäßig, damit eine Sicherung nicht unbemerkt unbrauchbar wird.

Ersetzt ein Galera-Cluster die Datensicherung?

Nein. Ein Cluster schützt vor dem Ausfall eines Servers, nicht vor gelöschten Daten. Jede Änderung erreicht alle Knoten, auch ein versehentliches Löschen oder ein fehlerhaftes Update. Dann fehlen die Daten auf allen Servern zugleich.

Dafür braucht es geprüfte Sicherungen außerhalb des Clusters. Mit den Binärlogs lässt sich je nach Einrichtung auch ein Stand kurz vor dem Fehler wiederherstellen. Ob das klappt, zeigt erst ein Wiederherstellungstest. Deshalb beginnt unser Datenbank-Check damit.

Wann lohnt sich ein Galera-Cluster?

Wenn die Anwendung auch beim Ausfall eines Datenbankservers weiterlaufen muss und schon eine Unterbrechung von Minuten zu viel ist. Galera braucht dafür mindestens drei Knoten oder zwei Knoten mit einem Schiedsrichter, ein stabiles Netz mit kurzen Laufzeiten und Tabellen mit InnoDB und Primärschlüssel.

Bei sehr großen Transaktionen oder vielen gleichzeitigen Schreibzugriffen auf dieselben Datensätze stößt ein Cluster an Grenzen. Dann passt oft eine einfachere Lösung besser: eine Replikation mit geplantem Umschalten oder eine schnelle, geprüfte Wiederherstellung. Was zu Ihrer Anwendung passt, steht in der Empfehlung des Datenbank-Checks.

Unsere Anwendung wird langsamer. Liegt es an der Datenbank?

Oft, aber nicht immer. Wir sehen uns zuerst die langsamsten Abfragen an, ihre Ausführungspläne und die Indizes. Dazu kommen die Konfiguration, etwa der Arbeitsspeicher für Daten und Indizes, und Sperren zwischen gleichzeitigen Zugriffen.

Häufig liegt die Ursache in der Anwendung: Eine Seite stellt sehr viele kleine Abfragen, oder ein Bericht lädt ganze Tabellen. Weil unsere Ingenieure auch ColdFusion, Lucee und PHP kennen, beheben wir das dort, wo es entsteht. Ein größerer Server ist dann oft nicht nötig.

Übernehmen Sie gelegentlich Wochenenddienst?

Ja. Support und Notfälle rund um die Uhr, also auch am Wochenende. Sonst erreichen Sie uns Montag bis Freitag von 9:00 bis 17:00 Uhr mitteleuropäischer Zeit, und auf eine neue Anfrage antworten wir innerhalb eines Werktags.

In 20 Minuten klären wir, welcher erste Schritt zu Ihrem System passt

Sie schildern Ziel und Stand, wir sagen offen, ob und wie wir helfen können. Antwort innerhalb eines Werktags, unverbindlich.

Telefon (Deutsch, Polnisch, Englisch) +48 501 250 220
E-Mail E-Mail

Erreichbar: Montag bis Freitag, 9:00 bis 17:00 Uhr (MEZ); Support und Notfälle rund um die Uhr (24/7)