ProxySQL is een speciale load balancer voor MySQL die wordt geleverd met een verscheidenheid aan functies, waaronder, maar niet beperkt tot, het omleiden van zoekopdrachten, het cachen van zoekopdrachten of het vormgeven van verkeer. Het kan worden gebruikt om eenvoudig een lees-schrijf-splitsing in te stellen en query's om te leiden naar afzonderlijke backend-knooppunten. Als gevolg hiervan biedt het veel dwingende redenen om te gebruiken. Aan de andere kant is HAProxy een geweldige load balancer, maar het is niet bedoeld voor databases en hoewel het kan worden gebruikt, kan het qua functionaliteit niet echt worden vergeleken met ProxySQL. Dit kan de reden zijn dat omgevingen die nog steeds afhankelijk zijn van HAProxy, proberen te migreren naar ProxySQL.
In deze korte blogpost zullen we een aantal suggesties delen met betrekking tot het migratieproces.
Uw upgrade plannen
Dit is vrij duidelijk en zou zonder twijfel moeten gaan, maar we zouden het toch graag op schrift willen hebben. Plan je upgrade. Zorg dat je bekend bent met het proces, dat je alles uitgebreid hebt getest. Stel een testomgeving in waarin u verschillende benaderingen van de upgrade kunt verifiëren en kunt beslissen welke het beste voor u werkt.
Test lezen/schrijven splitsen in ProxySQL als u overweegt het te gebruiken
Afhankelijk van uw vereisten, kunt u overwegen om lezen/schrijven splitsen in ProxySQL te gebruiken. Dit is waarschijnlijk een van de meest dwingende redenen om te upgraden. In plaats van het aan de toepassingskant te implementeren (of helemaal niet te implementeren als u het niet in de toepassing kunt bereiken), kunt u vertrouwen op ProxySQL om de lees-/schrijfsplitsing voor u uit te voeren. De installatie is heel eenvoudig, vooral als u ProxySQL implementeert met ClusterControl - het gebeurt vrijwel automatisch.
Zolang u geen impliciete transacties gebruikt, zal ClusterControl de lees/schrijf-splitsing voor u met behulp van een reeks zoekregels:
Hoewel het heel eenvoudig is om lees-/schrijfsplitsing te implementeren, moet u wees voorzichtig wanneer u van plan bent dit te doen. Toepassingen kunnen afhankelijk zijn van functionaliteit die niet echt direct werkt in ProxySQL. In de meeste gevallen kunt u met aanvullende configuratie profiteren van deze functie, maar het is erg belangrijk om tijdens de testfase te bepalen of uw app gewoon werkt of dat u een aangepaste configuratie moet toevoegen. Vooral lastige onderdelen zijn lees-na-schrijfproblemen - in dat geval moet u ProxySQL mogelijk opnieuw configureren om verbindingsmultiplexing voor sommige van de vragen uit te schakelen.
Vergeet het configuratiebestand in ProxySQL
Dit is een van de dingen die als een verrassing komen voor nieuwe gebruikers van ProxySQL. Het gebruikt niet echt configuratiebestanden. Er is er een, ja, maar het fungeert vrijwel als een manier om ProxySQL tijdens de eerste start op te starten. ProxySQL gebruikt een SQLite-database die de configuratie bevat en de juiste manier om configuratiewijzigingen aan te brengen is via een MySQL-client die is aangesloten op de beheerpoort van ProxySQL. Van daaruit kunt u de configuratiewijzigingen in runtime maken, vrijwel zonder dat u ProxySQL opnieuw hoeft te starten.
Natuurlijk kunt u met de gebruikersinterface van ClusterControl ook de ProxySQL opnieuw configureren:
ProxySQL-implementatiepatronen
Er zijn twee manieren waarop u ProxySQL wilt implementeren. U kunt ofwel een dedicated server gebruiken om ProxySQL te implementeren op:
Of u kunt ProxySQL samenvoegen met toepassingsservers:
Hierdoor kan uw toepassing verbinding maken met de lokale ProxySQL-instantie via Unix-socket, die is qua prestaties beter dan het gebruik van een externe TCP-verbinding. Het vereenvoudigt ook de installatie - het is niet nodig om Keepalive of een andere virtuele IP-provider te implementeren om de belasting over ProxySQL-instanties te verdelen. Applicatie maakt alleen verbinding met de lokale ProxySQL en dat is het zo'n beetje.
Gebruik ProxySQL-clusters voor grotere implementaties
Ervoor zorgen dat uw ProxySQL-instanties altijd dezelfde configuratie bevatten, kan een uitdaging zijn, vooral als ze groot zijn. Er zijn talloze manieren om met dergelijke uitdagingen om te gaan - Ansible/Chef/Puppet, shellscripts enzovoort. We raden u aan te vertrouwen op de ingebouwde oplossing - ProxySQL-cluster. Met slechts een paar configuratiewijzigingen kunt u ProxySQL-knooppunten configureren om een cluster te vormen waarbij een configuratiewijziging op een van de knooppunten wordt verspreid over alle leden van het cluster.
Knutselen met SO_REUSEPORT voor gracieus schakelen tussen load balancers
Een van de meer uitdagende onderdelen zou kunnen zijn om ervoor te zorgen dat u het verkeer van HAProxy naar ProxySQL schakelt op een manier die de impact op de toepassing minimaliseert. Normaal gesproken zou u ten minste één instelling moeten wijzigen - hostnaam of poort waarmee de toepassing verbinding moet maken. Afhankelijk van uw omgeving is dit misschien niet ideaal, vooral als de configuratie van de databaseverbinding in de toepassing is ingebouwd. Het zou vrijwel nodig zijn om een wijziging in de codebasis aan te brengen en een nieuwe code naar de productie te pushen. Niet de grootste deal, maar je kunt beter doen dan dat.
Het interessante is dat zowel ProxySQL als recente versies van HAProxy (vanaf 1.8) SO_REUSEPORT kunnen gebruiken. Deze socketoptie is beschikbaar in Linux vanaf de 3.9-kernel en maakt het mogelijk dat meerdere processen dezelfde poort delen. ProxySQL kan het gebruiken voor elegante upgrades tussen ProxySQL-versies, HAProxy gebruikt het om de configuratie opnieuw te laden zonder enige impact op de applicatie. Wat interessant is, is dat het mogelijk is om ProxySQL te configureren om de poort te delen met HAProxy voor een naadloze migratie tussen die twee load balancers.
Er zijn een aantal dingen waarmee u rekening moet houden wanneer u dit probeert te doen - ten eerste gebruikt ProxySQL deze optie niet standaard, u moet bij het opstarten de vlag -r aan ProxySQL toevoegen. U kunt dat doen door het ProxySQL systemd unit-bestand te bewerken:
[email protected]:~# systemctl edit proxysql --fullen het wijzigen van de ExecStart-richtlijn in:
ExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rEen andere beperking waarvan u zich bewust moet zijn in Linux, is dat alleen processen die met hetzelfde gebruikers-ID zijn gestart, de poort mogen delen. Dit betekent dat u ProxySQL opnieuw moet configureren om te worden uitgevoerd als een "haproxy" -gebruiker.
Zoals gewoonlijk wil je misschien tests uitvoeren voordat je deze bewerking in een productieomgeving probeert uit te voeren. Het is zeker mogelijk om deze prestatie te bereiken, maar je moet voorzichtig zijn en dubbel controleren of dit geen invloed heeft op je productie vanwege een of andere niet-standaard configuratie die verband houdt met je omgeving.
We hopen dat deze korte blog je enig inzicht geeft in het migratieproces van HAProxy naar ProxySQL. Voor de database-backends zal deze wijziging zeer gunstig zijn, zelfs als het voorbereidende gedeelte tijdrovend kan zijn. Als je de juiste tests uitvoert, zou de uiteindelijke migratie redelijk eenvoudig en veilig moeten zijn.