Master-Master vs Master-Slave-Datenbankarchitektur?

117

Ich habe von zwei Arten von Datenbankarchitekturen gehört.

  • Meister-Meister

  • Master-Slave

Ist der Master-Master nicht besser für das heutige Web geeignet, weil es wie Git ist, jede Einheit hat den gesamten Datensatz und wenn einer ausfällt, spielt es keine Rolle.

Master-Slave erinnert mich an SVN (was ich nicht mag), wo Sie eine Zentraleinheit haben, die die Sache erledigt.

Fragen:

  1. Was sind die Vor- und Nachteile von jedem?

  2. Wenn Sie eine lokale Datenbank wie das iPhone in Ihrem Mobiltelefon haben möchten, welche ist besser geeignet?

  3. Ist die Wahl eines dieser Faktoren ein kritischer Faktor, der gründlich berücksichtigt werden muss?

database 
— Never_had_a_name
quelle
1
CAP-Theorem -> Konsistenzverfügbarkeit Partitionstoleranz besagt, dass Sie nicht alle drei zusammen haben können. Je nach Anwendung können Sie eine auswählen.
— Pritam Banerjee

Antworten:

87

Wir tauschen Verfügbarkeit, Konsistenz und Komplexität aus. Um die letzte Frage zuerst zu beantworten: Ist das wichtig? Ja, sehr! Die Wahl, wie Ihre Daten verwaltet werden sollen, ist absolut grundlegend, und es gibt keine "Best Practice", die den Entscheidungen ausweicht. Sie müssen Ihre speziellen Anforderungen verstehen.

Es gibt eine grundlegende Spannung:

Eine Kopie: Konsistenz ist einfach, aber wenn es nicht funktioniert, sind alle aus dem Wasser, und wenn die Leute fern sind, können schreckliche Kommunikationskosten anfallen. Bringen Sie tragbare Geräte, die möglicherweise getrennt arbeiten müssen, in das Bild ein, und eine Kopie schneidet es nicht.

Master-Slave: Die Konsistenz ist nicht allzu schwierig, da jedes Datenelement genau einen eigenen Master hat. Aber was machst du dann, wenn du diesen Meister nicht sehen kannst? Eine Art von verschobener Arbeit ist erforderlich.

Master-Master: Nun, wenn Sie es zum Laufen bringen können, dann scheint es alles zu bieten, keine einzige Fehlerquelle, jeder kann die ganze Zeit arbeiten. Das Problem dabei ist, dass es sehr schwierig ist, die absolute Konsistenz aufrechtzuerhalten. Weitere Informationen finden Sie im Wikipedia-Artikel .

Wikipedia scheint eine schöne Zusammenfassung der Vor- und Nachteile zu haben

Vorteile

  • Wenn ein Master ausfällt, aktualisieren andere Master die Datenbank weiter.

  • Master können sich an mehreren physischen Standorten befinden, dh über das Netzwerk verteilt.

Nachteile

  • Die meisten Multi-Master-Replikationssysteme sind nur lose konsistent, dh faul und asynchron, was die ACID-Eigenschaften verletzt.

  • Eifrige Replikationssysteme sind komplex und führen zu einer gewissen Kommunikationslatenz.

  • Probleme wie die Konfliktlösung können unlösbar werden, wenn die Anzahl der beteiligten Knoten steigt und die erforderliche Latenz abnimmt.

— djna
quelle
CouchDB verwendet MVCC. Behandelt diese Art das Konsistenzproblem, mit dem mehrere Master konfrontiert sind, wenn eines wieder online geschaltet wird? Das Versionsverwaltungssystem behandelt die Konsistenz und dieser Master erhält die richtigen aktualisierten Daten.
— nie_had_a_name
8
Aber was passiert, wenn zwei Benutzer etwas Widersprüchliches tun - wie zwei Benutzer versuchen, den letzten Artikel auf Lager zu kaufen? Stellen Sie sich ein Szenario vor, in dem wir zwei Master haben und jeder Benutzer einen anderen Master trifft, dann bekommen wir eine Art Kommunikationsfehler - am Ende wird es entweder einen Kompromiss bei der Integrität oder eine verringerte Verfügbarkeit geben - einem Benutzer wird gesagt "Entschuldigung, Kumpel, Ich weiß wirklich nicht, was passiert, bis ich mit dem anderen Meister spreche ", oder wir haben einen bösen Konflikt, wenn die Kommunikation wiederhergestellt wird - und diese können sehr kompliziert werden.
— DJNA
2
Was nutzen Finanzhandel oder Aktienmärkte? Sie würden dieses Problem die ganze Zeit treffen?
— CMCDragonkai
3
Wenn Sie eine einzige, aktualisierte "Wahrheit" benötigen (wie in Finanzsystemen), benötigen Sie Master / Slave oder in der Tat nur Master. Wo Sie später die Wahrheit reparieren können (denken Sie an Zusammenführungskonflikte in einem Revisionskontrollsystem wie Git), können Sie Master / Master verwenden.
— DJNA
djna macht eine sehr hervorstechende Beobachtung. Die Datenbank muss nun eine Art "Tiebreaker" -Logik haben. Was ist am wichtigsten? Die "neuesten" Daten? Das ist sinnvoll, wenn Sie ein Feld neu schreiben, aber es ist nicht sinnvoll, wenn Sie einen "Zähler" ausführen und alle Prozesse inkrementieren (oder dekrementieren) müssen, bevor Sie ein Ergebnis zurückgeben. Vor allem, damit Sie keine nicht vorrätigen Artikel verkaufen. Wenn Sie eine Netzwerkpartition hatten, was passiert, wenn sie wieder zusammenkommt? All dies ist CAP-Theorum-Zeug. Hier können Sie auch Algorithmen wie Paxos verwenden, um einen Konsens zwischen verschiedenen Maschinen zu erzielen.
— Peter Corless
95

Während der Recherche auch die verschiedenen Datenbankarchitekturen. Ich habe ein gutes Stück Informationen zusammengestellt, die für jemanden relevant sein könnten, der in Zukunft forscht. Ich bin rübergekommen

  1. Master-Slave-Replikation
  2. Master-Master-Replikation
  3. MySQL Cluster

Ich habe mich entschlossen, MySQL Cluster für meinen Anwendungsfall zu verwenden. Die verschiedenen Vor- und Nachteile, die ich zusammengestellt habe, finden Sie weiter unten

1. Master-Slave-Replikation

Vorteile

  • Analytische Anwendungen können von den Slaves lesen, ohne den Master zu beeinträchtigen
  • Backups der gesamten Datenbank haben relativ keine Auswirkungen auf den Master
  • Slaves können offline geschaltet und ohne Ausfallzeit mit dem Master synchronisiert werden

Nachteile

  • Im Falle eines Fehlers muss ein Slave zum Master befördert werden, um seinen Platz zu übernehmen. Kein automatisches Failover
  • Ausfallzeiten und möglicherweise Datenverlust bei Ausfall eines Masters
  • Alle Schreibvorgänge müssen auch in einem Master-Slave-Design an den Master erfolgen
  • Jeder zusätzliche Slave belastet den Master etwas, da das Binärprotokoll gelesen und die Daten auf jeden Slave kopiert werden müssen
  • Die Anwendung muss möglicherweise neu gestartet werden

2. Master-Master-Replikation

Vorteile

  • Anwendungen können von beiden Mastern lesen
  • Verteilt die Schreiblast auf beide Masterknoten
  • Einfaches, automatisches und schnelles Failover

Nachteile

  • Locker konsistent
  • Nicht so einfach wie Master-Slave zu konfigurieren und bereitzustellen

3. MySQL Cluster

Das neue Kind in der Stadt basierend auf MySQL-Cluster-Design. Der MySQL-Cluster wurde unter Berücksichtigung der hohen Verfügbarkeit und Skalierbarkeit entwickelt und ist die ideale Lösung für Umgebungen, in denen keine Ausfallzeiten, hohe Verfügbarkeit und horizontale Skalierbarkeit erforderlich sind.

Weitere Informationen finden Sie unter MySQL Cluster 101

Vorteile

  • (Hohe Verfügbarkeit) Kein einzelner Fehlerpunkt
  • Sehr hoher Durchsatz
  • 99,99% Betriebszeit
  • Auto-Sharding
  • Reaktionsfähigkeit in Echtzeit
  • Online-Operationen (Schemaänderungen usw.)
  • Verteilte Schreibvorgänge

Nachteile

Sie können für meinen Blog eine vollständige Aufschlüsselung mit Architekturdiagrammen besuchen , die weitere Details zu den drei genannten Architekturen enthält.

— Skillachie
quelle
2
Kannst du auch etwas über Galera schreiben? Percona XtraDB Cluster?
— Ivanov
"Anwendung muss möglicherweise neu gestartet werden" als Teil der Nachteile. Was heißt das?
— Lily
1
Wenn Sie die IP des DB-Servers ändern müssen, muss diese auch in der Anwendung konfiguriert werden, um vom neu gewählten Master lesen zu können. Infolgedessen müssen Sie möglicherweise Ihre App neu starten, um die neuen Konfigurationseinstellungen zu übernehmen. Es hängt alles von Ihrem aktuellen Setup ab. Sie können auch eine Floating-IP verwenden, um dies zu umgehen. Nur um Ihnen eine allgemeine Vorstellung zu geben
— Skillachie
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.