- Ein Konsistentes MariaDB10.3 Backup erreiche ich mit mariabackup mit der SST Methode. Dies erreiche ich sowohl bei einem einzelserver als auch bei einem Cluster.
Anlagemäßig die meines Wissens mit Abstand sicherste Möglichkeit, zumal alles aus von einem Hersteller kommt. "Konsistent" bezieht sich hier jedoch (natürlich) auf den einzelnen Knotenzustand/lokale Transaktionen – wenn aus irgendeinem Grund die Kommunikation mit anderen Knoten abgerissen ist, heißt dies nicht, dass komplexe logische DB-Operationen, die ggf. gerade auf einem anderen Knoten oder im Extremfall via Load-Balancing auf mehreren Knoten verteilt ablaufen, vollständig erfasst werden, wenn ein Online-Snapshot (insbesondere nur von einem der n verfügbaren Knoten) erstellt wird.
Um dem obigen ("applikationsseitigen") Problem zu begegnen, wäre bei komplexeren/zeitkritischen Anwendungen eine Analyse anzustellen, inwiefern man als zusätzlichen Schutz vor "Teilmodifikationen" während eines längerdauernden Online-Backups die Datenbank doch zwingend in den read-only-Modus versetzt (siehe diese Diskussion). Ein weiterer Ansatzpunkt wäre die explizite Sicherung aller Knoten und die Ausnutzung der Verfügbarkeit von inkrementellen Backups (laufen schneller als ein vollständiges Backup), welche man an die Erstellung des initialen Backups anhängen könnte... (nicht zwangsweise, aber in Kombination zumindest ansatzweise paranoid – was jedoch in diesem Fall nicht zwingend negativ aufzufassen sein muss).
Will man explizit sicherstellen, dass die Rück-Einspielung eines SSTs funktioniert, geht das eigentlich nur über einen direkten Test mit einer Temporärinstanz.
Ein zuvor beiläufig erwähnter Ansatz, um den momentanen Zustand des Gesamt-Clusters ohne jegliche Downtime zu sichern (physisches Backup), wäre die gleichzeitige Erstellung eines ZFS-Snapshots auf allen Knoten (und zwar wirklich so gleichzeitig wie möglich, d.h., im Optimalfall liegen die Daten aller Knoten im selben Pool); dies funktioniert natürlich auch mit nur einem Knoten.
- Der einzige Vorteil den ich mit einem Cluster erreichen würde wäre eine Ausfallsicherheit wenn ein Server ausfällt da die DB trotzdem noch erreichbar ist und funktioniert.
Neben der Ausfallsicherheit (ein nicht zu unterschätzender Vorteil) ist IMHO hier immer auch ein mögliches Load-Balancing (im vorliegenden Fall: mittels MaxScale) und die einfache Möglichkeit der Skalierung zu sehen (Vorbreitungen dafür wurden ja bereits getroffen, Konfigurationsänderungen sind minimal).
Was im Cluster-Modus theoretisch als Nachteil anzusehen ist (bei einem "Ein-Knoten-Cluster"), wäre das in diesem Modus zwangsweise per Design zum Tragen kommende "cluster-wide optimistic locking".
