MySQL High Availability Framework erklärt – Teil I:Einführung

In dieser dreiteiligen Blogserie erläutern wir die Details und Funktionen eines High Availability (HA)-Frameworks für MySQL-Hosting unter Verwendung der semisynchronen MySQL-Replikation und des Corosync plus Pacemaker-Stacks. In Teil I führen wir Sie durch die Grundlagen der Hochverfügbarkeit, die Komponenten eines HA-Frameworks und stellen Ihnen dann das HA-Framework für MySQL vor.

Was ist Hochverfügbarkeit?

Die Verfügbarkeit eines Computersystems ist der Prozentsatz der Zeit, in der seine Dienste während eines bestimmten Zeitraums verfügbar sind. Es wird im Allgemeinen als eine Reihe von Neunen ausgedrückt. Die folgende Tabelle zeigt beispielsweise die Verfügbarkeit und die entsprechende Ausfallzeit, gemessen über ein Jahr.

Die Bedeutung von Hochverfügbarkeit hängt von den Anforderungen Ihrer Anwendung und Ihres Unternehmens ab. Wenn Sie sich beispielsweise eine Ausfallzeit von mehr als ein paar Minuten pro Jahr in Ihrem Dienst nicht leisten können, sagen wir, dass der Dienst eine Hochverfügbarkeit von 99,999 % aufweisen muss.

Komponenten eines HA-Frameworks

Das Wesentliche an hoher Verfügbarkeit ist die Fähigkeit, sich nach Ausfällen, die in irgendeinem Teil eines Systems auftreten können, sofort zu erholen. Es gibt vier äußerst wichtige Komponenten in jedem HA-Framework, die automatisiert zusammenarbeiten müssen, um diese Wiederherstellbarkeit zu ermöglichen. Sehen wir uns diese Komponenten im Detail an:

1. Redundanz in Infrastruktur &Daten

Damit ein Dienst hochverfügbar ist, müssen wir sicherstellen, dass es eine Redundanz im Infrastruktur-Hosting sowie eine aktuelle Redundanz gibt Kopie der Daten, die der Dienst verwendet oder bereitstellt. Dies fungiert als Standby-Dienst, der bereit ist, zu übernehmen, falls der primäre Dienst von Ausfällen betroffen ist.

2. Fehlererkennungs- und Korrekturmechanismus

Es ist äußerst wichtig, sofort alle Ausfälle in irgendeinem Teil des primären Systems zu erkennen, die seine Verfügbarkeit beeinträchtigen könnten. Dadurch kann das Framework entweder Korrekturmaßnahmen auf demselben primären System ergreifen oder die Dienste auf ein Standby-System umschalten.

3. Failover-Mechanismus

Diese Komponente übernimmt die Verantwortung für das Failover der Dienste auf Ihre Standby-Infrastruktur. Bitte beachten Sie, dass, falls mehrere redundante Systeme verfügbar sind, diese Failover-Mechanismus-Komponente das am besten geeignete System unter diesen identifizieren und als primären Dienst bewerben muss.

4. Anwendungs-/Benutzerumleitungsmechanismus

Sobald die Standby-Systeme die primäre Rolle übernommen haben, stellt diese Komponente sicher, dass alle Anwendungs- und Benutzerverbindungen mit der neuen primären beginnen.

Erklärung des MySQL-Hochverfügbarkeits-Frameworks – Teil IClick To Tweet

Das HA-Framework für MySQL

Basierend auf dem obigen Modell verwenden wir das folgende HA-Framework für unser MySQL-Hosting bei ScaleGrid:

• Ein 3-Knoten-Master-Slave-Setup mit halbsynchroner MySQL-Replikation, um Infrastruktur- und Datenredundanz bereitzustellen.
• Der Corosync plus Pacemaker-Stack zur Bereitstellung von Fehlererkennungs-, Korrektur- und Failover-Mechanismen.
• Eine DNS-Zuordnung oder eine virtuelle IP-Komponente, um den Anwendungs- und Benutzerumleitungsmechanismus bereitzustellen.

Schauen Sie sich das folgende Diagramm an, um den Software-Stack dieser Architektur zu visualisieren:

Sehen wir uns die Funktionalität einiger Schlüsselkomponenten in diesem Framework an.

1. Corosync

   Corosync bietet einen Kommunikationsrahmen für die Knoten mit zuverlässiger Nachrichtenübermittlung zwischen ihnen. Es bildet einen Cluster-Ring von Knoten und verfolgt die Knoten, die dem Cluster beitreten und ihn verlassen, durch die Cluster-Mitgliedschaft. Corosync arbeitet eng mit Pacemaker zusammen, um über die Knotenverfügbarkeit zu kommunizieren, damit Pacemaker geeignete Entscheidungen treffen kann.

2. Herzschrittmacher

   Auch als Cluster Resource Manager (CRM) bekannt, stellt Pacemaker die Hochverfügbarkeit für MySQL sicher, das auf dem Cluster ausgeführt wird, und erkennt und behandelt Ausfälle auf Knotenebene durch eine Schnittstelle mit Corosync. Es erkennt und behandelt auch Ausfälle von MySQL, indem es eine Schnittstelle mit dem Resource Agent (RA) bildet. Pacemaker konfiguriert und verwaltet die MySQL-Ressource durch Start-, Stopp-, Überwachungs-, Hochstufungs- und Herabstufungsvorgänge.

3. Ressourcenagent

   Der Resource Agent fungiert als Schnittstelle zwischen MySQL und Pacemaker. Es implementiert Start-, Stopp-, Heraufstufungs-, Herabstufungs- und Überwachungsoperationen, die vom Pacemaker aufgerufen werden. Es gibt einen voll funktionsfähigen Ressourcenagenten namens Percona Replication Manager (PRM) für MySQL, der von Percona implementiert wurde. Dies wurde von ScaleGrid verbessert und ist auf unserer GitHub-Seite verfügbar.

4. DNS-Mapping-Komponente

   Der Ressourcenagent ruft nach Abschluss eines erfolgreichen Failovers diese Komponente auf, die die DNS-Einträge des Master-MySQL-Servers mit der IP-Adresse des neuen Masters aktualisiert. Beachten Sie, dass Clients immer einen Master-DNS-Namen verwenden, um sich mit dem MySQL-Server zu verbinden, und indem wir die Zuordnung dieses DNS-Namens zur IP-Adresse des aktuellen Masters verwalten, können wir sicherstellen, dass Clients ihre Verbindungszeichenfolgen oder Eigenschaften wann nicht ändern müssen es gibt ein Failover.

In Teil II dieser Blogserie erfahren Sie mehr über die kritische Datenredundanzkomponente, die durch die semisynchrone MySQL-Replikation erreicht wird. Wir werden auch tief in die Details und Konfigurationen der halbsynchronen Replikation eintauchen, die wir verwenden, um unsere Hochverfügbarkeitsunterstützung zu erreichen, und schließlich verschiedene Fehlerszenarien in Teil III und die Art und Weise überprüfen, wie das Framework auf diese Bedingungen reagiert und sich von diesen erholt.