Lastausgeglichener MySQL-Cluster ohne Load Balancer

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?

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 .

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

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 ;-)

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.

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

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.

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

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.

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.