☰

Master-Slave-Slave-Replikation: Der Master wird zum Engpass für Schreibvorgänge

tag-icon • tag-icon mysql replication mysql-replication database-performance
Master-Slave-Slave-Replikation: Der Master wird zum Engpass für Schreibvorgänge

Die MySQL-Datenbank hat ungefähr 2 TB Daten.

ich habe eine Master-Slave-Slave-Replikation laufen. Die Anwendung, die die Datenbank verwendet, führt Lese-Abfragen (SELECT) nur auf einem der beiden Slaves und Schreib-Abfragen (DELETE/INSERT/UPDATE) auf dem Master aus. Die Anwendung führt weitaus mehr Lese- als Schreibvorgänge aus.

Wenn wir ein Problem mit den Leseabfragen (SELECT) haben, können wir einfach eine weitere Slave-Datenbank hinzufügen und der Anwendung mitteilen, dass es eine weitere Slave-Datenbank gibt. So lässt es sich gut skalieren ...

Aufgrund der Schreibvorgänge liegt die Festplatten-E/A des Masters derzeit bei etwa 40 %.

Ich denke also darüber nach, wie ich die Datenbank in Zukunft skalieren kann. Denn eines Tages wird der Master überlastet sein.

Was könnte da eine Lösung sein?

vielleicht ein MySQL-Cluster? Wenn ja, gibt es irgendwelche Fallstricke oder Einschränkungen bei der Umstellung der Datenbank auf NDB?

vielen Dank im Voraus... :)

Antwort1

Für die Skalierung von MySQL gibt es keine allgemeingültige Antwort.Einige allgemeine Tipps:

  • Skalieren Sie so lange wie möglich „diagonal“, d. h., behalten Sie die Dinge auf einem einzigen MySQL-Server, solange Sie noch in der Lage sind, auf Standardhardware zu laufen. Das bedeutet wahrscheinlich 2 x Quad-Core-CPUs, 64+ GB RAM, 8 Festplatten RAID 10 – oder höher. Das obere Ende dessen, was „Standardhardware“ ist, wird jedes Jahr schneller.

  • Schauen Sie sich Brad Fitzpatricks Präsentationen zur Skalierung von LiveJournal an. Sie sind so ziemlich Klassiker, was die Skalierung von LAMP betrifft.Seite 25 - 26 dieser PräsentationSie erkennen das Problem, mit dem Sie bei der MySQL-Replikation letztendlich konfrontiert werden: Die Schreibvorgänge verbrauchen den gesamten verfügbaren Festplatten-E/A.

  • Lesen "Leistungsstarkes MySQL". Es ist ein wirklich gutes Buch vonAutoren, die viele MySQL-Installationen mit hoher Last gesehen haben.

  • Vermeiden Sie Sharding (Verteilung von Daten auf viele MySQL-Server) so lange wie möglich.Wenn Sie mit Sharding beginnen, verzichten Sie auf die meisten Vorteile relationaler Datenbanken und verlangsamen die Entwicklung. Wenn Sie Sharding durchführen müssen, sollten Sie stattdessen einen NoSQL-Datenspeicher mit integriertem Multiservermodell verwenden – z. B. Riak, Cassandra, HBase, MongoDB. Führen Sie im Idealfall eine „funktionale Partitionierung“ zwischen MySQL und NoSQL durch, sodass Sie MySQL weiterhin für weniger wichtige Daten verwenden, die gut in ein RDBMS passen, und die NoSQL-Engine für „wichtige“ Daten verwenden, die Sie nicht mit den MySQL-Daten verknüpfen müssen.

vielleicht ein MySQL-Cluster? Wenn ja, gibt es irgendwelche Fallstricke oder Einschränkungen bei der Umstellung der Datenbank auf NDB?

In "Web-Operationen" Es gibt ein Kapitel zu MySQL von Baron Schwartz. Er sagt im Grunde einfach "Nein!" zur Verwendung von MySQL Cluster/NDB in einer Website-Umgebung. Zitat: "... es funktioniert nicht gut bei Joins und GROUP BY-Abfragen, und Webanwendungen brauchen diese."

Antwort2

MySQL-Clustering ermöglicht Ihnen Skalierbarkeit bei Schreibvorgängen, indem Ihre Datenbank in Fragmente aufgeteilt wird, die auf mehrere Rechner verteilt sind. Allerdings werden komplexe Abfragen, die Daten aus mehreren Fragmenten abrufen, dadurch drastisch verlangsamt. Nur Sie können die Auswirkungen auf die Leistung Ihrer Anwendung bestimmen.

Vielleicht möchten Sie die Daten manuell sharden, anstatt dies der Cluster-Engine zu überlassen. Dies erfordert zwar mehr Konfiguration, aber wenn Sie verstehen, wie Ihre Anwendung die Datenbank verwendet, können Sie möglicherweise ein Sharding-Schema entwickeln, bei dem die meisten Abfragen nur auf ein Shard zugreifen können.

Antwort3

Bedenken Sie, dass die MySQL-Replikation ein Single-Thread-Verfahren ist. Ihre Replikation wird also wahrscheinlich nicht durch die Kapazität des Masters beschränkt, sondern durch die Slaves, die nicht hinter dem Master mithalten können und daher nicht synchron sind.Aus diesem Artikel:

Der Replikationswiedergabevorgang wird in einem einzigen Thread auf den Replikaten ausgeführt und hat daher keine Chance, mit einer auch nur mäßig hohen Schreiblast auf dem Primärserver Schritt zu halten, wo viele Aktualisierungen gleichzeitig erfolgen.

Antwort4

Sie können über eine Clusterung der Informationen selbst nachdenken und, wenn möglich, Tabellen mit Schreibzugriff auf verschiedene Server aufteilen.

verwandte Informationen