Uw HA-topologie kiezen
Er zijn verschillende manieren om een hoge beschikbaarheid te behouden met databases. U kunt virtuele IP's (VRRP) gebruiken om de beschikbaarheid van de host te beheren, u kunt resourcemanagers zoals Zookeeper en Etcd gebruiken om uw applicaties te (her)configureren of load balancers/proxy's gebruiken om de werklast over alle beschikbare hosts te verdelen.
De virtuele IP's hebben ofwel een applicatie nodig om ze te beheren (MHA, Orchestrator), wat scripting (Keepalived, Pacemaker/Corosync) of een technicus om handmatig een failover uit te voeren en de besluitvorming in het proces kan complex worden. De virtuele IP-failover is een rechttoe rechtaan en eenvoudig proces door het IP-adres van de ene host te verwijderen, aan een andere toe te wijzen en arping te gebruiken om een gratis ARP-antwoord te verzenden. In theorie kan een virtueel IP-adres in een seconde worden verplaatst, maar het duurt een paar seconden voordat de failoverbeheertoepassing zeker weet dat de host is uitgevallen en dienovereenkomstig handelt. In werkelijkheid zou dit ergens tussen de 10 en 30 seconden moeten zijn. Een andere beperking van virtuele IP's is dat sommige cloudproviders u niet toestaan om uw eigen virtuele IP's te beheren of helemaal niet toe te wijzen. Google staat u bijvoorbeeld niet toe dat te doen op hun rekenknooppunten.
Resourcemanagers zoals Zookeeper en Etcd kunnen uw databases bewaken en uw applicaties (her)configureren zodra een host faalt of een slave wordt gepromoveerd tot master. Over het algemeen is dit een goed idee, maar het uitvoeren van uw controles bij Zookeeper en Etcd is een complexe taak.
Een load balancer of proxy zit tussen de applicatie en de databasehost en werkt transparant alsof de client rechtstreeks verbinding zou maken met de databasehost. Net als bij de virtuele IP- en resourcemanagers, moeten de load balancers en proxy's ook de hosts bewaken en het verkeer omleiden als een host niet beschikbaar is. ClusterControl ondersteunt twee proxy's:HAProxy en ProxySQL en beide worden ondersteund voor MySQL master-slave-replicatie en Galera-cluster. HAProxy en ProxySQL hebben beide hun eigen gebruiksscenario's, we zullen ze ook in dit bericht beschrijven.
Waarom heb je een load balancer nodig?
In theorie heb je geen load balancer nodig, maar in de praktijk zal je er wel de voorkeur aan geven. We zullen uitleggen waarom.
Als je virtuele IP's hebt ingesteld, hoef je alleen maar je applicatie naar het juiste (virtuele) IP-adres te verwijzen en alles zou in orde moeten zijn qua verbinding. Maar stel dat u het aantal leesreplica's hebt uitgeschaald, wilt u misschien ook virtuele IP-adressen opgeven voor elk van die leesreplica's vanwege onderhouds- of beschikbaarheidsredenen. Dit kan een zeer grote pool van virtuele IP's worden die u moet beheren. Als een van die leesreplica's een fout vertoonde, moet u het virtuele IP-adres opnieuw toewijzen aan een andere host, anders maakt uw toepassing verbinding met een host die niet werkt of in het ergste geval met een achterblijvende server met verouderde gegevens. Het is daarom noodzakelijk om de replicatiestatus naar de applicatie die de virtuele IP's beheert te behouden.
Ook voor Galera is er een vergelijkbare uitdaging:je kunt in theorie zoveel hosts toevoegen als je wilt aan je applicatieconfiguratie en er willekeurig een kiezen. Hetzelfde probleem doet zich voor wanneer deze host niet beschikbaar is:u kunt uiteindelijk verbinding maken met een niet-beschikbare host. Ook het gebruik van alle hosts voor zowel lezen als schrijven kan rollbacks veroorzaken vanwege de optimistische vergrendeling in Galera. Als twee verbindingen tegelijkertijd naar dezelfde rij proberen te schrijven, ontvangt een van hen een rollback. Als uw werklast dergelijke gelijktijdige updates heeft, is het raadzaam om slechts één node in Galera te gebruiken om naar te schrijven. Daarom wilt u een beheerder die de interne status van uw databasecluster bijhoudt.
Zowel HAProxy als ProxySQL bieden u de functionaliteit om de MySQL/MariaDB-databasehosts te bewaken en de status van uw cluster en zijn topologie bij te houden. Voor replicatie-instellingen kunnen zowel HAProxy als ProxySQL de verbindingen naar een andere host herdistribueren als een slave-replica niet werkt. Maar als een replicatiemaster niet beschikbaar is, weigert HAProxy de verbinding en geeft ProxySQL een juiste fout aan de client. Voor Galera-configuraties kunnen beide load balancers een masterknooppunt uit het Galera-cluster kiezen en alleen de schrijfbewerkingen naar dat specifieke knooppunt sturen.
Op het eerste gezicht lijken HAProxy en ProxySQL vergelijkbare oplossingen, maar ze verschillen veel in functies en de manier waarop ze verbindingen en query's distribueren. HAProxy ondersteunt een aantal balanceringsalgoritmen zoals minste verbindingen, source, random en round-robin, terwijl ProxySQL verbindingen distribueert met behulp van het op gewicht gebaseerde round-robin-algoritme (gelijk gewicht betekent gelijke verdeling). Omdat ProxySQL een intelligente proxy is, is het databasebewust en kan het ook uw zoekopdrachten analyseren. ProxySQL kan lezen/schrijven splitsen op basis van queryregels, waarbij u de query's kunt doorsturen naar de aangewezen slaves of master in uw cluster. ProxySQL bevat extra functionaliteit zoals het herschrijven van query's, caching en query-firewall met realtime, diepgaande generatie van statistieken over de werklast.
Dat zou voldoende achtergrondinformatie over dit onderwerp moeten zijn, dus laten we eens kijken hoe u zowel load balancers voor MySQL-replicatie als Galera-topologieën kunt inzetten.
HAProxy implementeren
ClusterControl gebruiken om HAProxy op een Galera-cluster te implementeren is eenvoudig:ga naar het relevante cluster en selecteer "Load Balancer toevoegen":
En u kunt een HAProxy-instantie implementeren door het hostadres toe te voegen en de serverinstanties te selecteren die u in de configuratie wilt opnemen:
Standaard wordt de HAProxy-instantie geconfigureerd om verbindingen te verzenden naar de serverinstanties die het minste aantal verbindingen ontvangen, maar u kunt dat beleid wijzigen in round robin of source.
Onder geavanceerde instellingen kunt u time-outs, het maximale aantal verbindingen instellen en zelfs de proxy beveiligen door een IP-bereik voor de verbindingen op de witte lijst te zetten.
Onder het tabblad knooppunten van dat cluster verschijnt het HAProxy-knooppunt:
Nu is uw Galera-cluster ook beschikbaar via de nieuw geïmplementeerde HAProxy-node op poort 3307. Vergeet niet om uw applicatie toegang te verlenen vanaf het HAProxy IP, aangezien het verkeer nu binnenkomt van de proxy in plaats van de applicatiehosts. Vergeet ook niet om uw applicatieverbinding naar de HAProxy-node te richten.
Stel nu dat de ene serverinstantie uitvalt, HAProxy zal dit binnen een paar seconden opmerken en stoppen met het verzenden van verkeer naar deze instantie:
De twee andere knooppunten zijn nog steeds in orde en zullen verkeer blijven ontvangen. Hierdoor blijft het cluster zeer beschikbaar zonder dat de klant het verschil merkt.
Een secundair HAProxy-knooppunt implementeren
Nu we de verantwoordelijkheid voor het behouden van hoge beschikbaarheid over de databaseverbindingen van de client naar HAProxy hebben verplaatst, wat als het proxyknooppunt sterft? Het antwoord is om nog een HAProxy-instantie te maken en een virtueel IP-adres te gebruiken dat wordt beheerd door Keepalive, zoals weergegeven in dit diagram:
Het voordeel ten opzichte van het gebruik van virtuele IP's op de databaseknooppunten is dat de logica voor MySQL zich op proxyniveau bevindt en dat de failover voor de proxy's eenvoudig is.
Laten we dus een secundair HAProxy-knooppunt inzetten:
Nadat we een secundair HAProxy-knooppunt hebben geïmplementeerd, moeten we Keepalive toevoegen:
En nadat Keepalived is toegevoegd, ziet je nodes-overzicht er als volgt uit:
Dus in plaats van uw toepassingsverbindingen rechtstreeks naar het HAProxy-knooppunt te verwijzen, moet u ze in plaats daarvan naar het virtuele IP-adres verwijzen.
In het voorbeeld hier hebben we afzonderlijke hosts gebruikt om HAProxy op uit te voeren, maar u kunt ze ook eenvoudig toevoegen aan bestaande serverinstanties. HAProxy brengt niet veel overhead met zich mee, hoewel u er rekening mee moet houden dat in het geval van een serverstoring, u zowel het databaseknooppunt als de proxy verliest.
ProxySQL implementeren
Het implementeren van ProxySQL op uw cluster gaat op dezelfde manier als HAProxy:"Add Load Balancer" in de clusterlijst op het tabblad ProxySQL.
Geef in de implementatiewizard op waar ProxySQL wordt geïnstalleerd, de beheergebruiker/wachtwoord, de bewakingsgebruiker/het wachtwoord om verbinding te maken met de MySQL-backends. Vanuit ClusterControl kunt u ofwel een nieuwe gebruiker maken die door de toepassing moet worden gebruikt (de gebruiker wordt gemaakt op zowel MySQL als ProxySQL) of u kunt de bestaande databasegebruikers gebruiken (de gebruiker wordt alleen gemaakt op ProxySQL). Stel in of u impliciete transacties gebruikt of niet. Als u SET autocommit=0 niet gebruikt om een nieuwe transactie aan te maken, configureert ClusterControl de lees-/schrijfsplitsing.
Nadat ProxySQL is geïmplementeerd, is het beschikbaar op het tabblad Nodes:
Als u het ProxySQL-knooppuntoverzicht opent, krijgt u de ProxySQL-monitoring- en beheerinterface te zien, dus er is geen reden meer om in te loggen op ProxySQL op het knooppunt. ClusterControl dekt de meeste belangrijke ProxySQL-statistieken zoals geheugengebruik, querycache, queryprocessor enzovoort, evenals andere statistieken zoals hostgroepen, backend-servers, queryregelhits, topquery's en ProxySQL-variabelen. In het ProxySQL-beheeraspect kunt u de queryregels, back-endservers, gebruikers, configuratie en planner rechtstreeks vanuit de gebruikersinterface beheren.
Bekijk onze ProxySQL-zelfstudiepagina die uitgebreid ingaat op het uitvoeren van databasetaakverdeling voor MySQL en MariaDB met ProxySQL.
Garbd implementeren
Galera implementeert een op quorum gebaseerd algoritme om een primaire component te selecteren waarmee het consistentie afdwingt. Het primaire onderdeel moet een meerderheid van stemmen hebben (50% + 1 knooppunt), dus in een systeem met 2 knooppunten zou er geen meerderheid zijn, wat resulteert in gespleten hersenen. Gelukkig is het mogelijk om een garbd (Galera Arbitrator Daemon) toe te voegen, een lichtgewicht stateless daemon die als een oneven node kan fungeren. Het extra voordeel door de Galera Arbitrator toe te voegen, is dat u nu kunt doen met slechts twee knooppunten in uw cluster.
Als ClusterControl detecteert dat uw Galera-cluster uit een even aantal knooppunten bestaat, krijgt u van ClusterControl de waarschuwing/het advies om het cluster uit te breiden naar een oneven aantal knooppunten:
Kies verstandig de host om garbd op te implementeren, omdat deze alle gerepliceerde gegevens zal ontvangen. Zorg ervoor dat het netwerk het verkeer aankan en veilig genoeg is. U kunt een van de HAProxy- of ProxySQL-hosts kiezen om garbd op te implementeren, zoals in het onderstaande voorbeeld:
Houd er rekening mee dat vanaf ClusterControl 1.5.1 garbd niet op dezelfde host als ClusterControl kan worden geïnstalleerd vanwege het risico op pakketconflicten.
Na het installeren van garbd, zie je het verschijnen naast je twee Galera-knooppunten:
Laatste gedachten
We hebben u laten zien hoe u uw MySQL-master-slave- en Galera-clusterconfiguraties robuuster kunt maken en hoge beschikbaarheid kunt behouden met HAProxy en ProxySQL. Garbd is ook een mooie daemon die de extra derde node in je Galera-cluster kan opslaan.
Hiermee is de implementatiekant van ClusterControl voltooid. In onze volgende blog laten we je zien hoe je ClusterControl integreert binnen je organisatie door gebruik te maken van groepen en het toekennen van bepaalde rollen aan gebruikers.