nach einem massiven Datenproblem meines Providers in GER bin ich nun gezwungen, mich mit Failover-Szenarien auseinanderzusetzen. Allerdings gibt es ein paar Fragen, auf die ich keine wirklichen Antworten finde. Daher hoffe ich, dass mir hier jemand weiterhelfen kann.
Aktuell betreibe ich auf Server1 zwei MySQL Datenbanken in getrennten Docker Containern. Diese sollen nun auf einen zweiten Server repliziert werden. Sollte Server1 ausfallen, kann ich über eine ClusterIP relativ schnell auf Server2 umschalten.
Falls es wichtig ist, das zu wissen: Bei der Software, die die Datenbank verwendet, handelt es sich um ein Sportwettbewerbs-Managementsystem, das viele Schreibvorgänge in der Datenbank durchführt (nicht getestet, aber insgesamt keine Schreib- und Lesevorgänge).
Die Fragen für mich sind jetzt:
- Welche Replikationsmethode ist am geeignetsten?
- So wie ich das verstehe, wäre MASTER <-> MASTER am sinnvollsten. Allerdings habe ich hier auch immer wieder gelesen, dass es zu Problemen kommen kann.
- Bei MASTER <-> SLAVE stellt sich die Frage, dass der Slave nur lesen kann. Was passiert, wenn der Master ausfällt? Wird der Slave dann automatisch zum Master und kann auch schreiben?
- Oder ist ein Cluster die beste Lösung? Momentan habe ich nur einen aktiven Node. Ein weiterer DB Node in den USA könnte in Zukunft noch dazukommen. Momentan existiert dieser aber nicht.
Ich bin für jede Hilfe wirklich dankbar, da ich eine schnell funktionierende Lösung brauche und dieses allgemeine Thema sehr umfangreich und nicht so einfach zu sein scheint.
Antwort1
Sie sprechen zwei Probleme an.
MySQL-TopologieIn der Reihenfolge (von OK bis Best)
- Primär -> Replikat – Ein „Failover“ ist möglich, erfordert jedoch manuellen Aufwand und damit Zeit.
- Primär <=> Primär – Dies ist nur geringfügig komplexer einzurichten, ermöglicht aber die „sofortige“ Verwendung des anderen Servers.
- Cluster mit mindestens 3 Servern. Dies automatisiert das Failover weiter. Siehe „InnoDB CLuster“ (MySQL 8) oder „Galera“ (in MariaDB enthalten).
Geografie – Bedenken Sie, dass auch ein Rechenzentrum ausfallen kann. Wie groß kann beispielsweise ein einziger Hurrikan in Florida sein, der die Netze lahmlegen kann?
Seien Sie sich des „Split-Brain“-Szenarios bewusst. Dabei haben Sie nur zwei Server und beide sind aktiv und einsatzbereit, aber das Netzwerk ist ausgefallen. Die Server können es nicht erkennen und Sie können nicht erkennen, wie die Situation ist. Wenn jeder Server denkt, er sei der einzige aktive Server und weiterhin Schreibvorgänge durchführt, ist das Ergebnis ein Chaos. Stattdessen müssen Sie also davon ausgehen, dass das gesamte System ausgefallen ist.
Fazit: Sie benötigen mindestens drei physisch getrennte Server.
Proxy
Es besteht immer noch das ProblemKundenwissen, welcher Teil des Datenbanksystems aktiv ist (zum Lesen und/oder Schreiben). Wenn nur das „Lesen“ wichtig ist, reichen viele Topologien mit einer beliebigen Anzahl von Replikaten aus – und bieten „unbegrenzte“ Skalierung. Die wirklichen Herausforderungen liegen beim „Schreiben“.
Es gibt mehrere Produkte von Drittanbietern, die erkennen, wenn ein Server ausgefallen ist, und dann „das Richtige tun“, indem sie die Verbindung zu einem anderen Server umleiten. Informieren Sie sich über diese Produkte.
Kodierung
Wenn ein Fehler auftritt, wird Ihr Code wahrscheinlich eine Art Fehler aufweisen. Sie müssen nach Fehlern suchen, manche beheben sich nicht von selbst. Und die meisten Netzwerkfehler werden erst nach einiger Zeit bemerkt.