Was ist MySQL Fabric?

MySQL Fabric ist ein erweiterbares Framework zur Verwaltung von MySQL-Servergruppen. Es handelt sich um GPL-Open-Source-Software, das heißt, Benutzer können diese Software gemäß den GPL-Spezifikationen frei verwenden und ändern. MySQL Fabric ist der Prozess, der alle Verwaltungsanforderungen verarbeitet. Wenn Sie die HA-Funktion verwenden, können Sie diesen Prozess für die Überwachung des Master-Servers verantwortlich machen und im Falle eines Fehlers ein Failover einleiten und den Slave-Server zum Master-Server aktualisieren.

Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.

Einführung in MySQL Fabric

MySQL Fabric ist ein erweiterbares Framework für die Verwaltung von MySQL-Serverfarmen.

MySQL Fabric kann mehrere MySQL-Datenbanken „organisieren“. Das Anwendungssystem verteilt Tabellen, die größer als mehrere TB sind, auf mehrere Datenbanken, d. h. Data Shard. Derselbe Shard kann mehrere Datenbanken enthalten, und Fabric wählt automatisch eine geeignete Datenbank als Master-Datenbank aus, und die anderen Datenbanken werden als Slave-Datenbanken für die Master-Slave-Replikation konfiguriert. Wenn die Master-Datenbank hängt, wird eine der Slave-Datenbanken ausgewählt und zur Master-Datenbank hochgestuft. Anschließend werden andere Slave-Datenbanken in die neue Primärdatenbank übertragen, um die neuen Daten zu kopieren. Hinweis: Das hier erwähnte „Automatisch“ bedeutet, dass MySQL Fabric es im Hintergrund ausführt, ohne dass der Benutzer die Konfiguration manuell ändern muss. Das Wichtigste ist, dass MySQL Fabric eine GPL-Open-Source-Software ist, was bedeutet, dass Sie diese Software gemäß den GPL-Spezifikationen frei verwenden und ändern können.

Das Fabric-Framework implementiert zwei Funktionen: Hochverfügbarkeit (Hochverfügbarkeit) und horizontale Erweiterung (Sharding) mithilfe von Daten-Sharding. Diese beiden Funktionen können einzeln oder in Kombination verwendet werden.

Beide Funktionen werden auf der Grundlage der folgenden zwei Ebenen implementiert:

MySQL-Fabric ist der Prozess, der alle Verwaltungsanforderungen verarbeitet. Wenn Sie die HA-Funktion verwenden, können Sie diesen Prozess auch den Master-Server überwachen lassen und bei einem Fehler ein Failover einleiten, wodurch der Slave-Server zum Master-Server hochgestuft wird. Der MySQL Fabric-fähige Connector speichert die von MySQL Fabric erhaltenen Routing-Informationen in einem Cache und verwendet diese Informationen dann, um die Transaktion oder Abfrage an den richtigen MySQL-Server zu senden.

Hohe Verfügbarkeit

HA-Gruppe besteht jederzeit aus zwei oder mehr MySQL-Servern, ein Server fungiert als Master-Server (der Master-Server der MySQL-Replikationsfunktion) und die anderen Server fungieren als Slave-Server (MySQL). Replikationsfunktion) Funktioneller Slave-Server). Die Rolle der HA-Gruppe besteht darin, sicherzustellen, dass die in der Gruppe gespeicherten Daten jederzeit zugänglich sind. Die Replikationsfunktion von MySQL gewährleistet die Datensicherheit durch Replikation, und die Hochverfügbarkeitslösung von MySQL Fabric bietet auf dieser Basis zwei wesentliche zusätzliche Elemente:

Fehlererkennung und Upgrade – MySQL Fabric überwacht den Master-Server in der HA-Gruppe, wählt einen Slave aus und befördert ihn zum Master im Falle eines Master-Ausfalls – die Weiterleitung von Schreibanforderungen an den Master und die Lastverteilung von Leseanforderungen über mehrere Slaves hinweg ist für die Anwendung transparent, selbst wenn sich die Topologie während des Failovers ändert Wenn die Kapazitäts- oder Schreibleistungsgrenzen eines MySQL-Servers (oder einer HA-Gruppe) erreicht werden, kann MySQL Fabric auf mehrere MySQL-Server skaliert werden. Die Daten werden innerhalb von Server-„Gruppen“ partitioniert, um die Skalierung von Datenbankservern zu unterstützen. Beachten Sie, dass eine Gruppe nur einen MySQL-Server enthalten kann oder eine HA-Gruppe sein kann. Der Administrator definiert, wie die Daten zwischen diesen Servern aufgeteilt werden; er gibt an, welche Tabellenspalten als Sharding-Schlüssel verwendet werden sollen und ob diese Schlüssel mithilfe der HASH-Zuordnung oder der RANGE-Zuordnung den richtigen Shards zugeordnet werden sollen, falls ein weiteres Sharding erforderlich ist Vorhandene Shards aufteilen; außerdem können Shards neu zugewiesen werden.

Von MySQL Fabric zu lösende Probleme

Warum Daten-Sharding? Data Shard ist oft notwendig, wenn Ihre Anwendung Tabellen mit mehr als 1 TB Daten verarbeiten muss. Eine so große Tabelle verursacht große Probleme hinsichtlich der Abfrage- und Aktualisierungseffizienz oder der Zeit, die zum Sichern und Ändern der Struktur erforderlich ist. Wenn Sie jedoch eine so große Tabelle auf mehrere Datenbankserver verteilen, kann jeder Datenbankserver eine einzelne Fehlerquelle darstellen. Solange ein Gerät hängen bleibt, kommt es zu Problemen im Betrieb des gesamten Systems . Andererseits wird das anwendungsseitige Programm auch komplizierter, da jede Abfrage entsprechend ihren Abfragebedingungen (dem Inhalt der where-Klausel) auf unterschiedliche Datenbanken verweisen muss. Wenn sich außerdem die Struktur des Daten-Shardings ändert (z. B. das Hinzufügen einer Datenbank), müssen alle Programme auf der Anwendungsseite geändert werden, was die Wartung äußerst kompliziert macht.

Um das Problem der zunehmenden Anwendungskomplexität zu lösen, fügt jemand einen Proxy (Proxy) hinzu oder wird zum Schalter zwischen der Anwendung und dem Datenbankserver. Alle Anweisungen an die Datenbank werden zunächst an den Proxy gesendet , und dann bestimmt Proxy, in welche Datenbank übertragen werden soll. Das Bild unten ist ein schematisches Diagramm dieses Plans. Dies kann das Problem der schwierigen Wartung von Anwendungen lösen, aber wenn die Anzahl der Anwendungen zunimmt, die Datenbankfragmentierung zunimmt oder der Systemdruck zunimmt, wird dieser Schalter zu einem Kapazitäts- und Leistungsengpass. Es gibt einen einzigen Fehlerpunkt (wenn er ausfällt). , die Anwendung kann die Datenbank nicht finden) und alle Datenbankanweisungen müssen zweimal übergeben werden (zuerst an den Switch und dann an die Datenbank). Jede Abfrage erzeugt zusätzliche Last.

Die Architektur von MySQL Fabric

MySQL Fabric verfolgt einen anderen Ansatz und seine Architektur ist in der folgenden Abbildung dargestellt. Das Hauptmerkmal besteht darin, Switches in Anschlüssen auf jeder Anwendungsseite zusammenzuführen, um den Single Point of Failure und Leistungsengpass eines einzelnen Switches zu beheben.

MySQL Fabric besteht aus drei Teilen:

1. MySQL Fabric-Verwaltungsknoten:

ist ein Python-Skript, das den Kern der gesamten Architektur bildet.

Die Hauptfunktion des MySQL Fabric-Verwaltungsknotens besteht darin, die gesamte Datenbankserverfarm zu verwalten. Beim Start findet er die Konfigurationsdatei /etc/mysql/fabric.cnf, die angibt, dass die Fabric dahinter sein soll Wird zum Speichern der Serverfarm-Architektur und zum Konfigurieren des MySQL-Datenbankstandorts, des Ports, des Verbindungskontos und anderer Informationen des Repositorys verwendet.

Wenn Fabric initialisiert wird (führen Sie den Befehl „mysqlfabric manage setup“ aus), öffnet es ein Schema in der MySQL-Datenbank (normalerweise eine Datenbank mit dem Namen „fabric“), um konfigurationsbezogene Informationen zur Serverfarm zu speichern, z. B. welche Servergruppen sich zusammensetzen welche Datenbanken, welche sind die Master- und Slave-Server in jeder Servergruppe usw.

Beim Einrichten der Konfiguration gibt der MySQL Fabric-Knoten Befehle aus, um eine Master-Slave-Replikation für jede Datenbank in der Serverfarm einzurichten (die rote Linie im Bild oben).

Pingen Sie während des normalen Betriebs regelmäßig den Master-Server jeder Gruppe. Wenn festgestellt wird, dass die Master-Datenbank nicht normal läuft, wird das Failover-Programm gestartet und ein geeigneter Promotion-Server in der Slave-Datenbank der Serverfarm gesucht der Master-Server sein. Andere Slave-Datenbanken wenden sich an die neue Master-Datenbank, um die Datenreplikation fortzusetzen.

2. Datenbankserverfarm

In herkömmlichen Datenbankanwendungen handelt es sich um eine einzelne MySQL-Datenbank, während MySQL Fabric mehrere Datenbanken (TB-Ebene oder höher) unterstützt. und Anforderungen an Hochverfügbarkeitsdatenbanken. Diese Datenbanken sind in mehrere Hochverfügbarkeitsgruppen (HA-Gruppe) unterteilt. Jede Gruppe enthält mehr als einen Datenbankserver. Die unteren grauen und hellblauen Quadrate in der Abbildung oben stellen Hochverfügbarkeitsgruppen dar. Wenn sich in der Hochverfügbarkeitsgruppe mehrere Datenbanken befinden, wählt MySQL Fabric (verwenden Sie den Befehl mysqlfabric group promote), um eine davon zur Master-Datenbank (Master) heraufzustufen, und die anderen Datenbanken werden zu Slave-Datenbanken (Slave). kopiert die Änderungen der Master-Datenbank und schließt die Master-Slave-Replikation innerhalb derselben Hochverfügbarkeitsgruppe ab. Zukünftig wird Fabric regelmäßig auf diese Hauptdatenbank zugreifen. Wenn die Primärdaten ausfallen, wählt Fabric eine aus der Hochverfügbarkeitsgruppe aus und stuft sie in die Primärdatenbank hoch. Andere Datenbanken wenden sich dann an diese neue Primärdatenbank, um die Replikation fortzusetzen.

Andererseits verwendet MySQL Fabric den Connector nur auf der Anwendungsseite, um das Lesen und Schreiben dieser Master-Slave-Datenbanken zu trennen. Wenn die Anwendung sowohl Lese- als auch Schreibvorgänge für die Datenbank ausführt, übermittelt der Connector die Anweisung in die Masterdatenbank. Wenn die Anwendung nur Lesevorgänge auf der Datenbank ausführt und der Parameter read_only der Verbindung auf „ON“ gesetzt ist, werden alle Abfragen der Reihe nach an diese Datenbanken gesendet. Durch die Trennung von Lesen und Schreiben können die Datenverarbeitungsfähigkeiten des Anwendungssystems erhöht werden. Darüber hinaus kann MySQL Fabric, wie bereits erwähnt, auch Tabellen (Sharding-Tabellen) verarbeiten, die auf mehrere Datenbankserver aufgeteilt werden müssen. Jede Hochverfügbarkeitsgruppe kann einen Teil der Daten der Shard-Tabelle speichern. Der Konnektor auf der Anwendungsseite sendet die Anweisungen für die Shard-Tabelle entsprechend den Einstellungen des MySQL Fabric-Verwaltungsknotens an verschiedene Hochverfügbarkeitsgruppen. Dadurch kann die Datenbankkapazität mit zunehmender Anzahl von Hochverfügbarkeitsgruppen wachsen. Gleichzeitig werden die Anweisungen und alle für die nicht geteilte Tabelle ausgegebenen DDLs vom Connector an die globale Gruppe Hochverfügbarkeitsgruppe (globale Gruppe) gesendet. Die Hauptdatenbank der globalen Hochverfügbarkeitsgruppe wird festgelegt zu anderen Hochverfügbarkeitsgruppen über die MySQL Fabric-Hauptdatenbank. Die Primärdatenbanken aller Hochverfügbarkeitsgruppen, die geteilte Tabellen speichern, replizieren die Änderungen in der globalen Gruppe, sodass andere Hochverfügbarkeitsgruppen über eine Kopie der nicht geteilten Tabellendaten verfügen. Dies erleichtert die JOIN-Operation geteilter Tabellen für nicht geteilte Tabellen in SQL.

3. Connector

Wenn das Anwendungssystem läuft, wird jeder SQL-Befehl über den Connector an die Datenbank gesendet. Der Connector, mit dem MySQL Fabric ausgestattet ist, ist derselbe wie die allgemeine eigenständige MySQL-Datenbank, mit der Ausnahme, dass es sich bei der neueren Version des Connectors um den Fabric-fähigen Connector handelt, der über mehr Funktionen verfügt, die Datenbankserverfarmen verarbeiten können. Dies ermöglicht es ihnen, die Konfiguration der Serverfarm im Verwaltungsknoten von MySQL Fabric mithilfe des XML-RPC-Protokolls beim Herstellen einer Datenbankverbindung zu überprüfen, und dann können Abfragen unter der Verbindung gemäß den Anweisungen der Fabric an die entsprechende Datenbank gesendet werden .

Auf diese Weise wird der Proxy, der bei gängigen Datenbank-Shard-Lösungen zu Leistungsengpässen führen kann, im Connector platziert und so dieses Problem gelöst. Derzeit umfassen die von MySQL Fabric unterstützten Technologien Java, Python und PHP, d. h. Connector/J, Connector/Python und Connector/PHP sind alle Fabric-fähig.

Nehmen Sie Java als Beispiel. Der JDBC-Treiber muss Connector/J 5.1.30 oder höher sein. Das Java-Programm von Fabric ähnelt dem allgemeinen Java-Programm zum Abfragen von eigenständigem MySQL, außer dass beim Einrichten eines Datenbankverbindungsobjekts Die Datenbankverbindungs-URL lautet nicht „Zeigen Sie auf die Datenbank“, sondern auf den MySQL Fabric-Verwaltungsknoten (die IP-Adresse und der Port des Servers lauten normalerweise 32274).

Wenn es sich bei der abgefragten Tabelle um eine globale Tabelle (ohne Tabellen-Shard) oder eine DDL (z. B. beim Erstellen einer Tabelle oder beim Ändern der Tabellenstruktur) handelt, muss beim Herstellen des Verbindungsobjekts der Parameter „fabricServerGroup=" hinzugefügt werden Der Parameter „fabricServerGroup=" wird zum Erstellen des Verbindungsobjekts verwendet. Der ausgegebene SQL-Befehl wird an die Hauptdatenbank der globalen Gruppe gesendet, und dann wird die Datenbank in andere Hochverfügbarkeitsgruppen (Shard) kopiert

Wenn es sich bei der vom SQL-Befehl zu bedienenden Tabelle um eine partitionierte Tabelle (Shard-Tabelle) handelt, wird ein Verbindungsobjekt hergestellt. Fügen Sie dem Parameter den Parameter ''fabricShardTable=" hinzu. Anschließend werden die über dieses Verbindungsobjekt ausgegebenen SQL-Befehle ausgeführt werden gemäß dem von MySQL Fabric festgelegten Shard-Prinzip an die Hochverfügbarkeitsgruppe jeder Partition (Shard) gesendet.

Auf diese Weise muss das Anwendungsprogramm, wenn es SQL-Anweisungen unter diesen Shard-Tabellen ausgibt, nicht bestimmen, an welche Datenbank in SQL gesendet werden soll. Es liegt vollständig beim Connector, den von MySQL gefundenen Server zu überprüfen Fabric wird beim Herstellen einer Datenbankverbindung durch die Konfigurationsinformationen der Farm bestimmt (welche Datenbank zu welcher Shard-Gruppe gehört, das Aufteilungsprinzip jeder Shard-Tabelle usw.). Und diese Konfiguration wird auf der Anwendungsseite zwischengespeichert, wo sich der Connector befindet, nachdem die Hauptverbindung hergestellt wurde.

Auf diese Weise ist es nicht erforderlich, den MySQL Fabric-Verwaltungsknoten jedes Mal erneut abzufragen, wenn ein SQL-Befehl ausgegeben wird, und die Sharding-Konfiguration, die von der Anwendungsseite abhängt, wird direkt an die richtige Datenbank gesendet. Die Effizienz der Anwendung wird durch die Tabellenaufteilung in keiner Weise beeinträchtigt.

【Verwandte Empfehlungen: MySQL-Video-Tutorial】

Das obige ist der detaillierte Inhalt vonWas ist MySQL Fabric?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!