MySQL HA Lsungen fr Back- und Frontend ? MySQL HA Lsungen fr Back- und Frontend Matthias

  • Published on
    23-Dec-2018

  • View
    212

  • Download
    0

Transcript

Red Stack Magazin 06/2018 17MySQL HA Lsungen fr Back- und FrontendMatthias Klein, InnoGames GmbH Bereits seit dem Jahr 2001 bietet MySQL Replikations-Lsungen an. Whrend diese auf der Datenbank-Ebene bereits sehr ausgereift sind und stetig verbessert werden, muss man zur Anbindung seiner Anwen-dung meist noch auf Software von Drittanbietern zurckgreifen. Je nach Anwendungsfall ergeben sich hier unterschiedliche Mglichkeiten und Empfehlungen.18 www.aoug.at www.doag.org www.soug.chOpen-Source-DatenbankenSchon mit Einfhrung der Replikation vor etwa siebzehn Jahren konnte man zwischen einer synchronen und einer asynchronen Variante whlen. Whrend die synchrone Variante mit der ndb-En-gine sehr spezielle Voraussetzungen be-zglich Hardware und an die eingesetzte Anwendung hat, funktioniert die asyn-chrone Replikation grundstzlich mit al-len Engines.In der jngeren Vergangenheit hat Co-dership Oy die Galera Cluster entwickelt. Damit stand erstmals eine synchrone Va-riante der Replikation zur Verfgung, die sich durch Untersttzung der InnoDB-Engine und eine recht einfache Konfigu-ration auszeichnet. Die Einschrnkungen hinsichtlich der zugreifenden Anwendung sind im Gegensatz zu ndb nicht mehr existent, auch ist ein Betrieb mit schw-cherer Hardware mglich.Mit MySQL 5.7 fhrte Oracle ebenfalls eine zustzliche Cluster-Variante (Group Replication, GRE) ein. Diese integriert sich besser in die bisher bekannten Ablufe, so kann sie zum Beispiel analog zur asyn-chronen Replikation mit START GROUP_REPLICATION gestartet werden. Um aber eine Anwendung an die Datenbank an-binden zu knnen, kann man (mit Aus-nahme von MySQL Fabric) auf eine Soft-ware von Drittanbietern zurckgreifen. Die meisten dieser Varianten haben al-lerdings den Nachteil, dass sie nicht von sich aus hochverfgbar sind. Bei einigen Varianten vermindert das die Ausfallsi-cherheit nicht wesentlich, bei anderen jedoch enorm. Welche Manahmen da-gegen ergriffen werden knnen, ist ab-schlieend aufgezeigt.Abbildung 1: Asynchrone ReplikationAsynchrone ReplikationDiese Art der Replikation zeichnet sich da-durch aus, dass sie unabhngig von der verwendeten Datenbank-Engine arbei-tet. Es sind sogar unterschiedliche Engi-nes auf Master und Slave fr eine Tabelle mglich. Auerdem besteht die Mglich-keit, Datenbanken und/oder Tabellen von der Replikation auszuschlieen, diese nur auf bestimmten Replikaten zu replizieren oder auf dem Replikat einen anderen Na-men zu verwenden.Die asynchrone Replikation verwen-det binlog auf dem Master und relay-log auf dem Slave, um die nderungen zu bertragen. Dabei wird nach erfolgrei-chem Anwenden einer nderung in der Datenbank diese auf dem Master in das binlog geschrieben. Der Slave schreibt nun diese nderungen in sein relaylog und wendet sie lokal an.Dies kann ber das ausgefhrte SQL (Statement-based) geschehen oder es werden die Zeilen vor und nach der n-derung (Row-based) bertragen. Generell bentigt die Statement-Methode weniger Platz in den Logs, ist aber fehleranfllig, wenn LIMIT- oder GROUP-Funktio-nen zum Einsatz kommen. Hier besteht die Mglichkeit, mittels MIXED derarti-ge Statements Row-based zu replizieren. Die Row-based Replikation bentigt zwar mehr Platz in den Logs, jedoch muss der Slave das SQL nicht mehr ausfhren und kann die nderungen direkt anwenden (siehe Abbildung 1).Aus dieser Art der Replikation ergeben sich hauptschlich Probleme mit der An-wendung der nderungen auf dem Sla-ve. So kann es hier zu Verzgerungen kommen, da der Slave nur einen Thread zum Anwenden der nderungen benut-zen kann, der Master jedoch mit mehre-ren gleichzeitig nderungen durchfhrt. Hier kann man sich zwar mit der Option slave_parallel_workers behelfen, jedoch nutzt das nur dann, wenn mehrere Da-tenbanken repliziert werden.Auch ist es per Default mglich, auf ei-nen Slave zu schreiben. Dies kann dazu fhren, dass der Slave die Replikation unterbricht und der Administrator ent-scheiden muss, welcher Datenstand der richtige ist. Allerdings kann dies auch un-bemerkt passieren, wenn dieser Daten-satz nicht wieder angefasst wird. Um dies zu verhindern, sollten alle Slaves read_only (ab Version 5.7 auch super_read_only) aktiviert haben.Synchrone ReplikationObwohl die ndb-Engine die lteste Form der synchronen Replikation von MySQL ist, fhrt sie eher ein Nischendasein. Dies liegt vor allem an den speziellen Anforde-rungen, die sie an Hardware und Anwen-dung stellt, um noch performant zu sein. Die Daten sind ber mindestens zwei Knoten verteilt, wovon einer immer eine Kopie der Daten hlt. Die ndb-Engine partitioniert die Da-ten automatisch auf die vorhandenen Knoten. Zustzlich ist noch mindestens ein System fr das Management erfor-derlich sowie mindestens ein SQL-Kno-ten, der die Anfragen der Anwendung entgegennimmt. Konnten die Daten ur-Red Stack Magazin 06/2018 19Abbildung 2: Schreib-Prozess bei Galera Clustersprnglich ausschlielich im RAM der Datenknoten abgelegt werden, ist das mittlerweile auf Kosten der Performance auch auf Festplatte mglich.Bei der ndb-Engine bestehen meist Performance-Probleme. Gerade bei vie-len Datenknoten sind die Daten stark par-titioniert, was zum Beispiel Joins extrem teuer macht. Diese Operationen werden von den Datenknoten an den SQL-Knoten hochgereicht, der dann das endgltige Er-gebnis noch berechnen muss. Dies lsst sich nur durch entsprechende Anpassung des Schemas und der Anwendung verhin-dern. Ebenfalls problematisch sind Sche-ma-nderungen, die erst seit der ndb-Version 7.5 online erfolgen knnen. Verglichen mit InnoDB dauern diese auch deutlich lnger.Seit etwa fnf Jahren gibt es mit Galera Cluster eine stabile synchrone Replikation, die auf InnoDB basiert. Oracle hat mit My-SQL 5.7 die Group Replication (GRE) einge-fhrt. Beide Methoden unterscheiden sich in den technischen Details, die Konzepte sind jedoch so hnlich, dass beide zusam-men betrachtet werden knnen. Die Anwendung der nderung im Clus-ter erfolgt in einem mehrstufigen Pro-zess. Dabei werden die nderungen erst lokal auf dem Server verarbeitet. Sobald der Commit erfolgt, findet auf den an-deren Servern ein Zertifizierungsprozess statt. Dieser prft, ob die nderungen an-wendbar sind, und sendet das Ergebnis zurck. Da hier tatschlich keine Daten geschrieben werden, ist er sehr schnell. Lassen sich die nderungen auf allen Servern durchfhren, werden dem Cli-ent der Commit besttigt und die Daten endgltig geschrieben, im Fehlerfall die Daten nicht geschrieben und der Client bekommt eine entsprechende Meldung. Hier zeigt sich der Unterschied zwischen Galera und GRE deutlich: Whrend Ga-lera nur ein generisches DEADLOCK zu-rckliefert, konnte Oracle entsprechen-de Fehlercodes implementieren (siehe Abbildung 2).Ob sich am Ende Galera oder GRE durchsetzen oder beide eine Koexistenz fhren werden, ist im Moment noch un-klar. Galera profitiert durch den frhe-ren Start. So konnte Codership bereits mehr Erfahrungen sammeln und seine Implementierung weiter verbreiten. My-SQL punktet durch die direkte Imple-mentierung im Code, was sich durch eine angenehmere Bedienung ber mysql cli zeigt. Es ist davon auszugehen, dass Oracle fehlende Features in naher Zu-kunft nachrsten wird. So kann man bei Galera mit einem Arbitrator Ressourcen sparen. Auch gibt es hier Mglichkeiten, die Kommunikation des Clusters ber WAN-Verbindungen zu beschleunigen. Al-lerdings ist bei GRE die Kommunikation des Clusters untereinander deutlich Res-sourcen-schonender und wird mit mehr Servern auch nicht sprbar langsamer.Synchrone Replikation sollte immer mit einem dedizierten Server fr Schreib-zugriffe betrieben werden. Obwohl die Cluster-Software das zeitgleiche Schrei-ben auf unterschiedlichen Cluster-Nodes untersttzt, bringt dies am Ende keine Vorteile. Da die Daten auf jedem Node geschrieben werden mssen, werden Schreib-Operationen nicht schneller. Je mehr gleichzeitig auf unterschiedliche Nodes geschrieben wird, desto hher ist die Chance, dass der Zertifizierungs-prozess fehlschlgt. Auch sollte darauf geachtet werden, dass die zu schreiben-den nderungen mglichst klein sind, da sonst der Zertifizierungsprozess und die Anwendung der nderung sehr langsam werden, was unter Umstnden den kom-pletten Cluster blockieren kann. Die bei Galera empfohlenen Grenzen liegen hier 20 www.aoug.at www.doag.org www.soug.chOpen-Source-Datenbankenbei 128 KB pro Zeile beziehungsweise 1 GB pro Transaktion.Ein wichtiger Faktor beim Einsatz von Cluster-Systemen ist die Hardware. Der gesamte Cluster ist nur so schnell wie sein schwchstes Mitglied. Es wird auch eine ungerade Anzahl von Nodes (min-destens drei) empfohlen, um Split-Brain-Szenarien vorzubeugen. Dabei handelt es sich um Situationen, in denen die eine Hlfte der Nodes nicht mehr mit der an-deren kommunizieren kann. Dabei wird der Cluster funktionsunfhig, da die No-des keine Mehrheit fr die Masterwahl mehr herstellen knnen.Failover mittels MySQL FabricDie Hochverfgbarkeit auf der Daten-bank-Ebene ist einfach herzustellen und arbeitet stabil. Um jedoch die Anwen-dung anzubinden, ist in den meisten Fl-len Drittanbieter-Software oder eigene Programmierarbeit notwendig.Oracle selbst bietet mit MySQL Fab-ric eine eigene Lsung an. Diese erfor-dert allerdings einen speziellen Treiber fr die Anwendung und ist nur fr asyn-chrone Replikation geeignet. Auch der Management-Server, der die Koordina-tion bernimmt, ist selbst nicht hoch-verfgbar. Dessen Ausfall wrde den alten Status beibehalten. Ein zustzli-cher Ausfall des Masters wrde zu einer Downtime fhren, was jedoch recht un-wahrscheinlich ist.Neben dem Routing kmmert sich Fa-bric auch um die Wiederherstellung der Replikation. So wird im Fehlerfall aus ei-nem Pool von Servern ein neuer Master bestimmt und alle verbliebenen Server als dessen Slave konfiguriert. Unschn ist an dieser Stelle, dass der ausgefalle-ne Server nach seiner Wiederherstellung manuell in Fabric wieder aktiviert werden muss. Damit ist man zwar auf der siche-ren Seite, wenn man auf diesem Server Daten wiederherstellen musste; wenn je-doch nur ein Neustart etwa aufgrund von Softwareaktualisierungen stattgefunden hat, ist das Ganze recht umstndlich.Failover mittels MHA oder OrchestratorEinen hnlichen Weg gehen Master High Availability Manager (MHA) und Orchest-rator. Beide Tools knnen asynchrone Topologien managen, also im Fehlerfall einen neuen Master bestimmen und die Slaves entsprechend konfigurieren. Bei-de bentigen eine Management-Instanz. Nicht per Default integriert ist allerdings, die Anwendung ber die Topologie-n-derung zu informieren (wie bei Fabric) beziehungsweise auf eine Art den Be-trieb sicherzustellen. Dies liegt an den verschiedenen Mglichkeiten, mit Feh-lersituationen umzugehen. So kann man beispielsweise die Anwendung per API ber die nderung informieren, sofern sie dies untersttzt, oder einfach de-ren Konfiguration austauschen. Falls ein Proxy benutzt wird, kann dieser die n-derung abfragen. Die am hufigsten verwendete Me-thode ist jedoch, den Wechsel mithilfe einer virtuellen IP zu vollziehen. Dabei ist die IP-Adresse, die die Anwendung zur Verbindung nutzt, nicht fest an einen Da-tenbank-Server gebunden, sondern wird je nach Bedarf und Topologie zustzlich vergeben. MHA und Orchestrator haben bei un-terschiedlichen Ereignissen (wie Mas-ter up/down) Hooks integriert, ber die man dann passende Skripte ausfhren kann. Dies berlsst dem Administrator die volle Kontrolle ber die zu treffenden Manahmen; so kann hier beispielsweise auch der ausgefallene Master nach der Wiederherstellung automatisch als Sla-ve weiterlaufen. Dazu liefern beide Tools Beispiel-Skripte mit, die schnell an die ei-genen Anforderungen angepasst sind.Wie auch bei Fabric fhrt der Ausfall der Management-Instanz nur dazu, dass im Fehlerfall kein automatischer Failover stattfinden kann.Whrend MHA einzig auf der Kom-mandozeile zu bedienen ist, bietet Or-chestrator ein Web-Interface, ber das man einen berblick ber die aktuelle Si-tuation erhalten kann. Auch nderungen der Topologie sind mit Drag&Drop mg-lich, zudem lassen sich Server-Parameter einsehen und ndern. Zustzlich sind die-se Funktionen auch ber ein Web-API zu-gnglich (siehe Abbildung 3).Als einziges vorgestelltes Tool kann Or-chestrator von sich aus Hochverfgbar-keit herstellen. Dazu gengt es, mehrere Instanzen zu installieren und ein gemein-sames Backend zu nutzen.Failover mittels ProxyEine weitere Mglichkeit, eine Anwen-dung an die Datenbanken anzubinden, besteht darin, einen Proxy zu verwenden. Abbildung 3: Orchestrator-Web-OberflcheRed Stack Magazin 06/2018 21Dabei wird in der Anwendung der Proxy als Ziel konfiguriert und dieser kmmert sich um die Weiterleitung der Verbin-dung. Hier bieten sich zum Beispiel ha-proxy oder ProxySQL an. Allerdings ist bei einer Proxy-Lsung auch dafr zu sor-gen, dass diese selbst hochverfgbar ist. Weitverbreitet ist die Nutzung von keep-alived fr diesen Zweck, jedoch ist auch die Kombination aus heartbeat und pacemaker mglich. Entsprechende An-leitungen sind in der Dokumentation der jeweiligen Proxy-Software verfgbar. Mit Proxy lassen sich auch synchron replizie-rende Systeme anbinden.Haproxy ist ein generischer Proxy, der fr alle Dienste verwendet werden kann. In der einfachsten Variante wird lediglich berprft, ob die Datenbank erreichbar ist. Dies ist allerdings in Replikations-Sze-narien nicht ausreichend, da auch ber-prft werden muss, ob der Server richtig repliziert und dessen Daten gengend ak-tuell sind. Realisieren kann man das mit eigenen Skripten, die von haproxy via xinetd gestartet werden.Die bessere Wahl ist ProxySQL. Wich-tig ist dabei, dass ProxySQL nicht allein arbeiten kann. Standardmig wird ber-prft, welche Datenbank in der Topolo-gie schreibbar ist. Auf diese werden dann die Schreib-Operationen geleitet, die an-deren werden zum Lesen genutzt. Dies funktioniert sehr gut, wenn GRE benutzt wird. Standardmig wird nur ein Node des Clusters zum Schreiben freigegeben und die Cluster-Software kmmert sich selbst um die Topologie. Bei einer asyn-chronen Replikation gibt es eine solche Funktionalitt jedoch nicht. Hier helfen MHA oder Orchestrator, die nach einem Failover die entsprechenden Einstellun-gen vornehmen. Zustzlich bietet Pro-xySQL Query Routing und Firewall. So knnen Anfragen auf den fr sie besten Server umgeleitet oder problematische Anfragen unterdrckt werden.FazitWelches die richtige Replikationsmetho-de ist, hngt von der jeweiligen Anwen-dung ab. Grundstzlich ist aufgrund der Robustheit eine Cluster-Lsung zu emp-fehlen. Hier empfiehlt sich die Group Re-plication, da sie sich besser in das beste-hende System integriert. Auch dass hier Hosts automatisch auf read_only ge-setzt werden, hilft bei der Anbindung von Anwendungen mittels ProxySQL.Wer ber mehrere Rechenzentren ein Cluster bilden muss, sollte momentan noch zu Galera greifen. Hier berwiegen die Vorteile der von Codership implemen-tierten WAN-Optimierungen deutlich. Man kann aber hier auch berlegen, ob man in den Rechenzentren GRE nutzt und diese untereinander durch asynchrone Replikation anbindet. Die asynchrone Re-plikation bietet sich an, wenn man wenig Hardware zur Verfgung hat oder groe Datenstze schreiben muss.Welches Tool zum Anbinden der An-wendung genutzt wird, richtet sich hauptschlich nach der Replikationsme-thode. Bei synchroner Replikation emp-fiehlt sich ProxySQL. Bei asynchroner Re-plikation bevorzugt der Autor aufgrund der besseren bersicht im Web-Inter-face Orchestrator.Matthias Kleinmatthias.klein@innogames.com

Recommended

View more >