Skalierungslösungen für MySQL (Replikation, Clustering)

Bei dem Startup, an dem ich arbeite, denken wir jetzt darüber nach, Lösungen für unsere database zu skalieren. Die Dinge werden etwas verwirrend (zumindest für mich) mit MySQL, das den MySQL-Cluster , die Replikation und die MySQL-Cluster-Replikation (ab Version 5.1.6) hat, was eine asynchrone Version des MySQL-Clusters ist. Das MySQL-Handbuch erklärt einige der Unterschiede in seinen Cluster-FAQ , aber es ist schwierig, daraus herauszufinden, wann das eine oder das andere zu verwenden ist.

Ich würde mich über jeden Ratschlag von Leuten freuen, die mit den Unterschieden zwischen diesen Lösungen und den Vor- und Nachteilen vertraut sind, und wann empfehlen Sie sie zu verwenden.

   

    Ich habe viel über die verfügbaren Optionen gelesen. Ich habe auch High Performance MySQL 2nd Edition in die Hände bekommen, was ich sehr empfehle.

    Das ist es, was ich zusammen geschafft habe:

    Clustering

    Clustering im allgemeinen Sinn verteilt die Last auf viele Server, die für eine externe Anwendung als ein Server erscheinen.

    MySQL NDB Cluster

    MySQL NDB Cluster ist eine verteilte speicherinterne Shared-Nothing-Speicher-Engine mit synchroner Replikation und automatischer Datenpartionierung (entschuldigen Sie, dass ich mich wortwörtlich aus dem High Performance-Buch lehne, aber sie stellen es sehr schön dar). Es kann für einige Anwendungen eine Hochleistungslösung sein, aber eine Webanwendung funktioniert im Allgemeinen nicht gut darauf.

    Das Hauptproblem besteht darin, dass der Cluster nach sehr einfachen Abfragen (die nur eine Tabelle berühren) im Allgemeinen nach Daten auf mehreren Knoten suchen muss, wodurch sich die Netzwerklatenz einziehen und die Abschlusszeit für Abfragen erheblich verlangsamen kann. Da die Anwendung den Cluster als einen Computer behandelt, kann er nicht angeben, von welchem ​​Knoten die Daten abgerufen werden sollen.

    Darüber hinaus ist die speicherinterne Anforderung für viele große databaseen nicht durchführbar.

    Fortlaufende Sequoia

    Dies ist eine weitere Clusterlösung für MySQL, die als Middleware auf dem MySQL-Server fungiert. Es bietet synchrone Replikation, Lastverteilung und Failover. Es stellt außerdem sicher, dass Anforderungen immer die Daten aus der letzten Kopie abrufen und automatisch einen Knoten auswählen, der über die neuen Daten verfügt.

    Ich habe ein paar gute Dinge darüber gelesen, und insgesamt klingt es ziemlich vielversprechend.

    Föderation

    Die Föderation ähnelt dem Clustering, also habe ich sie auch hier gezogen. MySQL bietet eine Föderation über die föderierte Speicher-Engine. Ähnlich wie bei der NDB-Cluster-Lösung funktioniert es nur mit einfachen Abfragen – aber noch schlimmer mit dem Cluster für komplizierte (da die Netzwerklatenz viel höher ist).

    Replikation und Lastenausgleich

    MySQL hat die eingebaute Fähigkeit, Replikationen einer database auf verschiedenen Servern zu erstellen. Dies kann für viele Zwecke verwendet werden – Aufteilung der Last zwischen Servern, Hot Backups, Erstellung von Testservern und Failover.

    Die grundlegende Einrichtung der Replikation beinhaltet, dass ein Master-Server hauptsächlich Schreibvorgänge und ein oder mehrere Slaves nur Lesevorgänge behandelt. Eine erweiterte Variante ist die der Master-Master- Konfiguration, die es ermöglicht, Schreibvorgänge zu skalieren, indem mehrere Server gleichzeitig schreiben.

    Jede Konfiguration hat ihre Vor- und Nachteile, aber ein Problem, das sie alle gemeinsam haben, ist die Replikationsverzögerung. Da die MySQL-Replikation asynchron ist, haben nicht alle Knoten die jeweils aktuellsten Daten. Dies erfordert, dass die Anwendung die Replikation kennt und Replikationssensitive Abfragen so einrichtet, dass sie wie erwartet funktionieren. Für einige Anwendungen ist dies kein Problem, aber wenn Sie immer die frischesten Daten benötigen, werden die Dinge etwas kompliziert.

    Die Replikation erfordert einen Lastausgleich, um die Last auf die Knoten aufzuteilen. Dies kann so einfach sein wie einige Änderungen am Anwendungscode oder die Verwendung dedizierter Software- und Hardwarelösungen.

    Schärfung und Teilung

    Sharding wird häufig verwendet, um databaselösungen zu skalieren. Sie teilen die Daten in kleinere Shards auf und verteilen sie auf verschiedene Serverknoten. Dies erfordert, dass die Anwendung erkennt, dass die Änderung des Datenspeichers effizient funktioniert, da sie wissen muss, wo sie die benötigten Informationen finden kann.

    Es gibt Abstraktionsframeworks, die helfen, mit dem Sharting von Daten umzugehen, wie zum Beispiel Hibernate Shards , eine Erweiterung des Hibernate ORM (die leider in Java ist. Ich benutze PHP). HiveDB ist eine weitere solche Lösung, die auch Shard Rebalancing unterstützt.

    Andere

    Sphinx

    Sphinx ist eine Volltext-Suchmaschine, die für weit mehr als Testsuche verwendet werden kann. Für viele Abfragen ist es viel schneller als MySQL (insbesondere zum Gruppieren und Sortieren) und kann entfernte Systeme parallel abfragen und die Ergebnisse aggregieren – was es sehr nützlich macht im Zusammenhang mit Sharding.

    Im Allgemeinen sollte sphinx mit anderen Skalierungslösungen verwendet werden, um mehr von der verfügbaren Hardware und Infrastruktur zu erhalten. Der Nachteil ist, dass Sie erneut den Anwendungscode benötigen, um sich der Sphinx bewusst zu sein.

    Zusammenfassung

    Skalierungslösungen unterscheiden sich je nach den Anforderungen der Anwendung, die sie benötigt. Für uns und für die meisten Web-Anwendungen glaube ich, dass Replikation (wahrscheinlich Multi-Master) der Weg ist, mit einem Load-Balancer zu gehen, der die Last verteilt. Das Verschärfen spezifischer Problembereiche (riesige Tabellen) ist ebenfalls ein Muss, um horizontal skalieren zu können.

    Ich werde auch Continuent Sequoia eine Chance geben und schauen, ob es wirklich tun kann, was es verspricht, da es am wenigsten Änderungen am Anwendungscode mit sich bringt.

    Haftungsausschluss: Ich habe MySQL Cluster nicht verwendet, daher gehe ich nur von dem aus, was ich gehört habe.

    MySQL Cluster ist eine Hochverfügbarkeitslösung. Es ist schnell, weil es alles in Erinnerung ist, aber es ist ein echtes Verkaufsargument ist die Verfügbarkeit. Es gibt keinen einzigen Fehlerpunkt. Bei der Replikation hingegen müssen Sie, wenn der Master ausfällt, tatsächlich zum Replikat wechseln, und es kann zu einer kurzen Ausfallzeit kommen. (obwohl die DRBD-Lösung eine andere Alternative mit hoher Verfügbarkeit ist)

    Cluster erfordert, dass die gesamte database in den Speicher passt. Das bedeutet, dass jede Maschine im Cluster über genügend Speicher zum Speichern der gesamten database verfügen muss. Dies ist also keine praktikable Lösung für sehr große databaseen (oder zumindest eine sehr teure Lösung).

    Ich denke, wenn HA nicht super wichtig ist (lies: wahrscheinlich nicht), ist es mehr Aufwand (und Geld) als es wert ist. Replikation ist häufiger der bessere Weg.

    Bearbeiten: Ich habe vergessen zu erwähnen, dass Cluster keine Fremdschlüssel erlaubt, und Bereich Scans sind langsamer als bei anderen Engines. Hier ist ein Link, der über bekannte Einschränkungen von MySQL Cluster spricht

    Es gibt einige gute Diskussionen darüber, wie die Leute, die drupal.org pflegen, ihre databaseserver strukturiert haben:

    • Dries Buytaerts Blog
    • WorkHabits Blog

    Beide stammen aus dem Jahr 2007, daher ist die Clusterunterstützung möglicherweise jetzt stärker, aber zu der Zeit, als sie sich für die Replikation entschieden haben.

    Das Tolle an Replikation ist, dass es einfach ist. Richte einfach 2 mysql-Boxen ein, ändere die serverID auf der zweiten Box und richte dann die zweite Box mit dem Change-Master auf command.

    Hier ist der relevante Beispiel-Slave my.cnf config

    # # Log names # log-bin=binlog relay-log=relaylog log-error=errors.log # # Log tuning # sync_binlog = 1 binlog_cache_size = 1M # # Replication rules (what are we interested in listening for...) # # In our replicants, we are interested in ANYTHING that isn't a permission table thing # replicate-ignore-db = mysql replicate-wild-ignore-table=mysql.% # # Replication server ID # server-id = 2 

    Stellen Sie also sicher, dass jeder Slave eine ServerID erhält, die um 1 erhöht wird (der nächste Slave ist also Server 3)

    Richten Sie einen Benutzernamen und ein Passwort ein, mit denen der Slave eine Verbindung herstellen kann. Führen Sie dann den Änderungsstammsatz zu MASTER_HOST = ‘xxxx’ aus; ändere den Master in MASTER_PASSWORD = “xxxxx”;

    und so weiter.

    schließlich, starte “slave”

    Nach oben kommt dein Sklave und beginnt zu replizieren. Schatz, huh!

    Dies setzt voraus, dass Sie mit 2 leeren Servern beginnen. Dann können Sie Ihre db in den Master-Server ablegen, und während sie dort lädt, wird sie auch auf den Slave geladen.

    Sie können den Slave-Status überprüfen, indem Sie Folgendes ausführen:

    zeige den Sklavenstatus \ G an

    Viel Spaß damit .. soooo einfach …

    Die Einschränkung “im Speicher” hindert uns daran, den MySQL-Cluster für unsere fast 50 GB Daten zu verwenden, also verwenden wir DRBD plus Linux Heartbeat .

    Es ist wie ein Raid-Array zwischen zwei (oder mehr) Boxen, die die databaseen / logs / configs synchron halten (aber nur ein Server kann “live” sein). Failover ist automatisch, verwendet die gleiche IP-Adresse und ist schnell wie ein MySQL-Neustart, also war das eine gute Lösung für uns.

    Während der Hochverfügbarkeitsstudie stieß ich auf viele Lösungen und wahrscheinlich in unserem Fall, der mehr schreibintensives System war, fand ich DRBD-Cluster besser als das NDB-Cluster, da es eine größere Anzahl von Transaktionen pro Sekunde bietet.

    Mysql Replication kann Ihnen eine Backup-Maschine zur Verfügung stellen, die entweder als Read-Slave oder im Falle einer Disaster Recovery verwendet werden kann.

    Mit verschiedenen Modi der Transaktionsverwaltung, die von DRBD zur Verfügung gestellt werden, können Sie die performance, die durch Replikation von Daten auf Geräteebene über das Netzwerk verursacht wird, reduzieren. Für ein zuverlässiges System, das im Fehlerfall keine Transaktion verlieren sollte, verwenden Sie den C-Modus, sonst gehen Sie zu B.

    Ich habe versucht, einige der Erfahrungen aufzuzählen, die ich bei der Einrichtung des DRBD-Clusters unter http://www.techiegyan.com/?p=132 gemacht habe

    Es funktioniert sehr gut auf dedizierten Verbindung für die Replikation, dh separate High-Speed-Schnittstellen auf beiden Maschinen nur für drbd Replikation vorbehalten. Heartbeat kann den Cluster gut mit allen Diensten kontrollieren, dh IP-Adressen, Partitionen, drbd und mysql.

    Ich muss die Master-Master-Konfiguration auf DRBD noch entdecken. Wird aktualisiert, wenn ich Erfolg darin habe.

    Vielen Dank.

    Meiner Meinung nach schickt mich die Verwirrung hier einfach zurück nach Mnesia. Mit Fragmentierung, deklarativer und pragmatischer Handhabung von Indizes, Standorttransparenz von databasereplikaten etc

    In unserem Setup betreiben wir sowohl MySQL Cluster als auch Mnesia. Unsere Daten sind irgendwie saisonal. Was passiert, ist nach einiger Zeit, wir entlasten die Menge der nicht mehr benötigten Daten und casting sie in den MYSQL-Cluster. Dies hält unsere Mnesia effizient. Außerdem haben wir Anwendungen, die in den Hauptstream-Sprachen (Python, Clojure usw.) implementiert sind und Daten direkt von MySQL verwenden.

    Kurz gesagt, wir betreiben mnesia auf MySQL Cluster. Der MySQL Cluster kann große Datenmengen verarbeiten, eine database kann bis zu 50 GB groß werden. Wir haben Mnesien, die die Erlang / OTP- Anwendungen antreiben. Java und PHP greifen auf Daten von mnesia über maßgeschneiderte REST- APIs (kürzlich Thrift ) zu, die JSON und XML als Austauschformate verwenden.

    Die Datenzugriffsebene verfügt über einen abstrahierten Zugriff auf Daten in MNESIA und alte gesendete Daten in MySQL Cluster, falls erforderlich. Mnesia ist hier im Wesentlichen die Erlang / OTP-Anwendungen zu betreiben. Sobald es mit Daten gehackt wird, casting wir es in MYSQL Cluster. Die Datenzugriffsebene kann im Namen aller Anwendungen sowohl auf Daten in Minesien als auch auf MySQL in einer abstrahierten API zugreifen.

    Was ich hier sagen kann ist, dass Mnesia die beste Option für uns war. Die Tabellen sind stark fragmentiert und indiziert, Abfragen funktionieren sehr gut und die database wird über zwei Standorte hinweg repliziert, die über einen Tunnel verbunden sind.

    Zuvor hatten wir befürchtet, dass mnesia aufgrund der Begrenzung der Tabellengröße möglicherweise nicht so viele Datensätze wie möglich verarbeiten kann. Aber wir fanden diese Aussage falsch. Mit einer guten Abstimmung (Fragmentierung) halten unsere mnesia-databaseen im Durchschnitt etwa 250 Millionen Datensätze pro Jahr.

    Wir haben von Erlangs komplexer Datenstruktur und der Tatsache profitiert, dass Mnesia es unverändert verschlucken kann. Die Erlang / OTP-Anwendungen sind die leistungsfähigsten aller anderen Apps in älteren Sprachen und mit unserem System planen wir, alles auf die Erlang / OTP-Technologie zu migrieren. Von Erlang greifen wir nahtlos auf Daten von MySQL Cluster zu und führen Abfragen auf seinen Servern sehr wunderbar aus. Tatsächlich haben wir abgeleitet, dass sein Erlang / OTP die MySQL-Server-Ressourcen wegen seiner massiven (Erlang-) Parallelität vollständig nutzen kann.

    Mnesia hat sehr gut für uns gearbeitet. Mnesia hat die Art und Weise, wie wir databaseen betrachten, aufgrund seiner aufregenden Performance komplett verändert. Unsere Solaris-Server-CPU-Cores sind zu Spitzenzeiten durchschnittlich zu etwa 48% ausgelastet.

    Ich rate Ihnen, Mnesia zu überprüfen und wer weiß, kann es eine Reihe von Ihren Vertriebs- oder Replikationsanforderungen beantworten.

    Ich habe sie nicht verwendet, aber aus den Dokumenten würde ich sagen, dass die Replikation die bevorzugte Lösung ist, wenn die größte Last aus der database liest.

    Der MySQL-Cluster ist ein seltsames Tier und jedes Mal, wenn wir es ausgewertet haben, ist es entweder sehr schlecht oder unzuverlässig.

    Es ist schrecklich kompliziert einzurichten (Sie brauchen mindestens drei Knoten, möglicherweise mehr). Es gibt auch keine Möglichkeit, Clients fehlzuschlagen, also müssen Sie das selbst tun (oder etwas anderes als Proxy verwenden).

    Es ist extrem clever, weil es eine automatische Hash-Partitionierung auf dem Primärschlüssel durchführt, die es Ihnen ermöglicht, Schreibvorgänge zu skalieren, und auch, weil es keinen einzigen Fehlerpunkt gibt.

    Aber ich denke, es ist besser geeignet für die speziellen Zwecke, für die es entwickelt wurde. Es kann in den meisten Fällen eine andere database-Engine (z. B. InnoDB) weder in der performance noch in den functionen ersetzen.