Lastausgeglichener MySQL-Cluster ohne Load Balancer

10

Ich möchte einen MySQL-Cluster mit Lastenausgleich erstellen, jedoch ohne den eigentlichen Lastenausgleich, um keinen weiteren Fehlerpunkt oder keine weitere Komplexität hinzuzufügen.

Was ich dachte, war Folgendes zu haben:

  1. Haben Sie ein Master-Master-Setup für MySQL

  2. Platzieren Sie auf jedem Client einen einfachen Round-Robin-Proxy, der die Anforderungen zwischen Servern wechselt.

Ist das möglich? Oder gibt es bessere Möglichkeiten, dies zu erreichen?

mysql
quelle
Ich bin neugierig, wofür wirst du es verwenden?
Ich versuche, HA zu unserer Lösung hinzuzufügen, ohne Load-Balancer und ähnliches einzubeziehen.

Antworten:

3

Bitte lesen Sie meine andere Antwort auf diese Frage, bevor Sie einen MySQL-Proxy verwenden. Wenn Sie 2 Master-Master-Server haben, auf die ein CMS schreibt, und 10 httpd, die nur daraus lesen, ist alles in Ordnung, aber (wie in der anderen Antwort ausgeführt) ist dies nicht immer der Fall. Du wurdest gewarnt.

MySQL Proxy ist ein einfaches Programm, das sich zwischen Ihrem Client und MySQL-Servern befindet und deren Kommunikation überwachen, analysieren oder transformieren kann. Seine Flexibilität ermöglicht unbegrenzte Verwendungsmöglichkeiten. Häufige sind: Lastausgleich; Failover; Abfrageanalyse; Filterung und Änderung von Abfragen; und viele mehr.

.

HAProxy ist eine kostenlose, sehr schnelle und zuverlässige Lösung, die Hochverfügbarkeit, Lastausgleich und Proxy für TCP- und HTTP-basierte Anwendungen bietet

Wenn Sie es im TCP-Modus ausführen würden, könnte es sogar besser sein als Wackamole. Wenn ich mich zwischen ihnen entscheiden müsste, würde ich HAProxy verwenden. Auch HAProxy kann viele Backends haben, Waclamole kann nur 2 haben. Beachten Sie, dass HAProxy "dumm" ist, Sockets verbindet, ohne zu prüfen, was sich im Stream befindet - dedizierter MySQL-Proxy hat möglicherweise die Option, verschiedene Anforderungen auf bestimmte Server zu verweisen .


quelle
Nur um zu überprüfen: 1) HAProxy würde zusätzliche Maschine / 2 Maschinen für HA benötigen 2) Wackamole kann nur 2 Server pro Setup unterstützen? Grüße.
Wackamoles Standardnutzungsmuster (tatsächlich das einzige, das ich kenne) besteht darin, dass ServerA und ServerB sich gegenseitig beobachten und die IP des anderen übernehmen, wenn es stirbt. Auf der Wackamole-Website heißt es, dass damit ein Pool von IPs geschützt werden kann ... Aber ich muss sagen, dass Wackamole keine Stabilität bietet, wie man es gerne hätte, deshalb empfehle ich das nicht. Über HAProxy würden Sie 2 davon aus Redundanzgründen auf 2 dedizierten Computern platzieren, oder Sie könnten sogar einen auf jedem Knoten platzieren, wie Sie in der Frage gesagt haben. Wenn Ihre Fragen hauptsächlich gelesen werden, wird es meiner Meinung nach ziemlich gut funktionieren.
Hallo Riff. Nur ein letztes bisschen über Wackamole - Ihrer Erfahrung nach ist es auf zwei Maschinen nicht stabil genug?
2 Maschinen pingen sich gegenseitig an, aber eine von ihnen hat eine Last von 200, alle CPUs sind zu 100% ausgelastet, alle RAMs werden verwendet. MySQL ist abgestürzt. <- Wackamole funktioniert dort NICHT. HAProxy kann überprüfen, ob die Remote-ANWENDUNG aktiv ist, Wackamole nur, wenn der Server aktiv ist und application_uptime <server_uptime. Wir hatten viele Fälle, in denen wir uns auf Wackamole verlassen haben und es hat uns im Stich gelassen.
4

Wahrscheinlich erwähnenswert, Galera Replication für MySQL für ein echtes Multi-Master-MySQL-Setup. Galera ist ein synchrones Replikationsprotokoll, sodass Anwendungen von jedem MySQL-Server lesen und darauf schreiben können. Hier ist ein kurzes Tutorial: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

Verwenden Sie für Load Balancer vor den MySQL-Servern entweder einen MySQL-Connector, der diese Funktionalität unterstützt (z. B. Connector / J für Java oder Mysqlnd für PHP).

Wenn Sie keinen Connector haben, der dies kann, verwenden Sie so etwas wie einen HA-Proxy. Dieses Skript richtet HA Proxy automatisch ein und verwaltet die Liste der guten MySQL-Server: https://github.com/severalnines/haproxy

Freundliche Grüße,

Vinay

www.severalnines.com

Vinay Joosery
quelle
Es ist wichtig, dass Sie Ihre Assoziation mit dem von Ihnen empfohlenen Produkt sehr deutlich offenlegen. Diese Seite dient auch nicht der Eigenwerbung. Wenn Sie ein Produkt haben, das ein Problem lösen würde, großartig! Wenn sich alle Ihre Antworten um Ihre Produkte drehen, möchten Sie möglicherweise mit jemandem über das Erhalten von Werbeflächen sprechen, anstatt Antworten zu veröffentlichen. Bitte beachten Sie unsere FAQ .
JNK
3

Die Master-Master-Replikation ist nicht so gut, wie Sie vielleicht denken. Gleiches gilt für den Round-Robin-Proxy und ähnliche "einfache" Lösungen. Wenn Sie kollidierende Daten schnell genug auf separate Server übertragen (schneller als die Verzögerung zwischen den Servern, die auf Produktionsservern bis zu einer vollen Sekunde betragen kann *), akzeptieren beide die Daten. Wenn Sie einen Auktionsserver haben, haben Sie dasselbe Auto nur zweimal verkauft . Wer hat es gekauft? Es kommt darauf an, welche DB Sie fragen werden!

Die Anwendung muss sich darüber im Klaren sein, dass es tatsächlich zwei Datenbanken gibt, und sie muss beide IP-Adressen kennen. Wenn Sie "verkaufen" möchten, sollten Sie z

DB_number = `auction_number` % `number_of_databases`

( %ist für modulo)

... und schreiben Sie es in die Datenbank DB_number. Wenn Sie einen Verbindungsfehler erhalten, tun Sie dies möglicherweise mit dem anderen (aber im Falle eines Auktionsservers würde ich nur einen Fehler anzeigen).

Außerdem sollten die IP-Adressen zwischen beiden Servern wackamole -d sein. In einem Katastrophenszenario, in dem ein Datenbankserver in der Hauptnutzungszeit einige Stunden lang ausfällt, versucht die Anwendung, eine Verbindung zum abwesenden Server herzustellen und bis TIMEOUT zu warten, z. B. 3 Sekunden. Plötzlich läuft die Hälfte Ihrer Abfragen drei Sekunden länger (und alle gehen schließlich in dieselbe Datenbank - was nicht dazu führt, dass sie schneller ausgeführt werden als vor der Katastrophe). Dies macht Ihr httpd nicht glücklich, da es wahrscheinlich einen begrenzten Verbindungspool von Threads für gleichzeitige Anforderungshandler hat ...

* Die Replikationsverzögerung auf Produktionsservern kann bis zu einer vollen Sekunde betragen. Ich habe dies in einem Remote-Colocation und in unserem Rechenzentrum getestet und in 99% der Fälle ist es 0, aber manchmal zeigt MySQL 1s an. Bei massivem Datenverkehr hatte ich viele Kollisionen, weil die Clientanwendung zwei Anforderungen stellte, was zu zwei Abfragen führte: Einfügen und Auswählen. Bei einigen Fällen war die Reihe dort einfach nicht noch , so wir Hash - Wert des userID verwendet und das Problem behoben

Ich hoffe du lernst aus meinen Fehlern ;-)


quelle
Hallo. Danke für das Teilen. Ich dachte an Wackamole, was eigentlich gut für HA ist. Mein Problem dabei ist, dass die gesamte Last auf einem der Master-Server liegt, wenn der zweite inaktiv ist und im Grunde genommen Aktiv / Passiv erzeugt, während ich nach Aktiv / Aktiv suche. Vielleicht ist es besser, auf jedem Client eine leichte LB-Lösung zu platzieren, damit er Anforderungen zwischen den Servern wechseln kann? Irgendeine Idee, ob ein solches Tool existiert?
Wenn Sie Redundanz benötigen, ist "eine Arbeit, eine Leerlauf" gut. Nehmen wir an, einer der beiden Server stirbt (ich erinnere Sie daran, dass Sie den anderen gekauft haben. Wenn der erste ausfällt, können Sie trotzdem funktionieren). Wenn der zweite Server nicht den gesamten Datenverkehr verarbeiten kann, ist dies für die Skalierung und nicht für HA! Außerdem ist es eine schlechte Lösung, sich nur auf Wackamole zu verlassen (ping ok! = Mysqld ok).
3

Ein MySQL-Datenbankcluster mit Lastenausgleich (oder einem anderen) ist ziemlich zwecklos. Wenn Sie auf mehr als einen Server schreiben, treten Probleme auf oder Sie verwenden die synchrone Replikation (die MySQL ohnehin nicht unterstützt). Dies beeinträchtigt die Leistung erheblich, da Sperren synchronisiert werden müssen.

Ich empfehle Ihnen, die Lese- / Schreiblasten aufzuteilen und die Lesevorgänge auf die MySQL-Slaves aufzuteilen und entweder einen einzigen Master für Schreibvorgänge zu verwenden oder ein Aktiv / Passiv-Failover-Paar für Ihren Master zu verwenden.

Grundsätzlich können Sie Schreibvorgänge nicht skalieren, indem Sie mehr Server als Slaves in eine Datenbank einfügen, da jeder noch die gesamte Schreiblast Ihrer Anwendung schreiben muss.

Um Schreibvorgänge zu skalieren, müssen Sie Ihre Daten logisch auf mehrere Server aufteilen, indem Sie sie partitionieren oder "sharding" usw. Dies erfordert normalerweise nicht triviale (für sehr schwierig zu testende) Änderungen an Ihrer Anwendung. Sie möchten dies also nur tun, wenn Sie es WIRKLICH tun brauchen.

Sie können MySQL-Cluster natürlich verwenden, wenn Sie es wirklich wollen, aber es ist eine völlig andere Engine mit ihren eigenen Funktionen und Nachteilen - es ist etwas kompliziert einzurichten, bietet aber wirklich eine HA-Datenbank mit Lastenausgleich auf Standardhardware. Die Verwendung der synchronen Replikation leidet immer noch unter Einschränkungen der Schreibleistung. Sie können jedoch Schreibvorgänge skalieren, da die Partitionierung zwischen Servern integriert ist.


quelle
3

Ein weiterer großartiger Leitfaden zu diesem Thema, den ich gefunden habe ...

http://www.dancryer.com/2010/01/mysql-circular-replication

Dies ist Teil 1 einer Serie mit drei Beiträgen:

  • MySQL Load-Balanced Cluster Guide - Teil 1 - Einrichten der Server selbst und Konfigurieren der MySQL-Replikation.

  • MySQL Load-Balanced Cluster Guide - Teil 2 - Richten Sie ein Skript zur Überwachung des Status Ihrer MySQL-Clusterknoten ein, das wir im nächsten Handbuch zum Einrichten unseres Proxys verwenden.

  • MySQL Load-Balanced Cluster Guide - Teil 3 - Einrichten des Load Balancers mit HAProxy mithilfe der Überwachungsskripte

dvb
quelle
2

Persönlich wäre der bessere Weg, einen Load Balancer zu verwenden!

Ja, es fügt einen weiteren Fehlerpunkt hinzu, aber jede Routine, die Sie auf JEDEM Client einrichten oder installieren, erhöht die Komplexität erheblich als ein Standard-Load-Balancer.


quelle
Es macht Sinn, aber das Problem ist der einzige Fehlerpunkt - selbst bei 2 LBs ... Falls einer der Clients ausfällt, hat nur dies Auswirkungen und niemand anderes.
Es ist schwierig, LB auf jedem Knoten aufrechtzuerhalten. Wenn Sie eine LB auf 12 Servern installieren und dann etwas ändern möchten (Adresse einer der DBs oder eine DB oder etwas hinzufügen), werden Sie das Problem bemerken. Ich tat.
1

Connector / J kann Abfragen auf mehrere Server verteilen. Dies ist in erster Linie für MySQL NDB-Cluster gedacht, bei denen alle SQL-Knoten eine konsistente Ansicht der Daten haben. Wenn Sie jedoch sicherstellen können, dass die Datenbank mit zwei Mastern zwischen diesen beiden Mastern einigermaßen konsistent ist, ist dies möglicherweise für Ihre Anwendung sicher.

Die Verbindungszeichenfolge würde ungefähr so ​​aussehen:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000


quelle
0

Durch das Aufteilen von Schreibvorgängen werden die Server nicht entlastet, da die Schreibvorgänge noch repliziert werden müssen.

Wenn Sie nur 2 Server verwenden, verwenden Sie Heartbeat mit drbd und lassen Sie drbd die Replikation durchführen. Wenn der erste Server ausfällt, übernimmt der zweite Server. Wenn Sie den zweiten Server verwenden möchten, können Sie gfs über drbd verwenden und dann den zweiten Server als schreibgeschützt ausführen und als Leseserver verwenden. Wenn ein Failover auftritt, ändern Sie den Server in Lesen / Schreiben.

re: wackamole - wackamole ist nicht auf 2 Server beschränkt

Ich arbeite an einer Tutorial-Serie, die dies behandelt, aber die Einrichtung ist sehr einfach.


quelle
Ja, theoretisch kann Wackamole mehr als 2 Server unterstützen, aber haben Sie dies jemals in der Produktion versucht? Wir machten. Wir bedauern es jetzt.
Bisher hatte ich keine Probleme, außer der Tatsache, dass ich es nicht dazu bringen kann, unter Centos 5 64 Bit zu kompilieren
0

Um eine neuere Antwort auf diese Frage zu geben, wurden mit der Version 5.6 von MySQL GTID (Global Transaction Identifieres) eingeführt, die darauf abzielen, die asynchrone Replikation robuster zu machen und MySQL erneut in den Wettlauf um HA (High Availability) zu bringen.

In diesem Abschnitt wird die transaktionsbasierte Replikation mithilfe globaler Transaktionskennungen (GTIDs) erläutert. Bei Verwendung von GTIDs kann jede Transaktion identifiziert und verfolgt werden, wenn sie auf dem Ursprungsserver festgeschrieben und von beliebigen Slaves angewendet wird. Dies bedeutet, dass es bei Verwendung von GTIDs nicht erforderlich ist, beim Starten eines neuen Slaves oder beim Failover auf einen neuen Master auf Protokolldateien oder Positionen in diesen Dateien zu verweisen, was diese Aufgaben erheblich vereinfacht. Da die GTID-basierte Replikation vollständig transaktionsbasiert ist, kann einfach festgestellt werden, ob Master und Slaves konsistent sind. Solange alle auf einem Master festgeschriebenen Transaktionen auch auf einem Slave festgeschrieben sind, ist die Konsistenz zwischen beiden garantiert. Sie können entweder anweisungsbasierte oder zeilenbasierte Replikation mit GTIDs verwenden (siehe Abschnitt 16.2.1, „Replikationsformate“). Für beste Ergebnisse jedoch

Referenz: 16.1.3 Replikation mit globalen Transaktionskennungen (MySQL-Dokumentation)

Ich dachte, dass die Verwendung von HAProxy zum Lastenausgleich von Abfragen einen SPOF (Single Point Of Failure) einführt und das Hinzufügen von Heartbeat diese Lösung umständlich macht.

Eine einfachere Lösung besteht darin, eine Verbindung über den Java-Connector JConnector herzustellen, der darauf abzielt, Lastausgleichsabfragen über eine JDBC-URL mit allen MySQL-Knoten durchzuführen. Es kann Master / Slave- oder Master / Master- Setups verarbeiten.

Dies ermöglicht die sofortige Einrichtung einer HA-Cluster-Lösung mit MySQL.

Jérôme B.
quelle