In het eerste deel van de serie hebben we u laten zien hoe u een MySQL-replicatie-installatie implementeert met ProxySQL met WHM en cPanel. In dit deel laten we enkele bewerkingen na de implementatie zien voor onderhoud, beheer, failover en voordelen ten opzichte van de stand-alone installatie.
MySQL-gebruikersbeheer
Als deze integratie is ingeschakeld, moet MySQL-gebruikersbeheer worden gedaan vanuit WHM of cPanel. Anders zou de ProxySQL mysql_users-tabel niet synchroniseren met wat is geconfigureerd voor onze replicatiemaster. Stel dat we al een gebruiker hebben aangemaakt met de naam meerderen_user1 (de MySQL-gebruikersnaam wordt automatisch voorafgegaan door cPanel om te voldoen aan de MySQL-beperking), en we zouden verschillenden_db1 aan database willen toewijzen, zoals hieronder:
Het bovenstaande zal resulteren in de volgende mysql_users tabeluitvoer in ProxySQL:
Als u MySQL-bronnen buiten cPanel wilt maken, kunt u ClusterControl -> Beheren -> Schema's en gebruikers gebruiken en importeer vervolgens de databasegebruiker in ProxySQL door naar ClusterControl -> Nodes -> kies het ProxySQL-knooppunt -> Gebruikers -> Gebruikers importeren .
De Proxysqlhook-module die we gebruiken om ProxySQL-gebruikers te synchroniseren, stuurt de foutopsporingslogboeken naar /usr/local/cpanel/logs/error_log. Gebruik dit bestand om te inspecteren en te begrijpen wat er achter de schermen gebeurt. De volgende regels zouden in het cPanel-logbestand verschijnen als we een webtoepassing genaamd Zikula zouden installeren met Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****U zou enkele herhaalde regels zien, zoals "Controleren of {DB-gebruiker} bestaat" omdat WHM meerdere MySQL-gebruikers/hosts aanmaakt voor elk gebruikersverzoek voor het maken van een database. In ons voorbeeld zou WHM deze 3 gebruikers maken:
ProxySQL heeft alleen de gebruikersnaam, het wachtwoord en de standaard hostgroepinformatie nodig bij het toevoegen van een gebruiker. Daarom zijn de controleregels er om meerdere invoegingen van exact dezelfde gebruiker te vermijden.
Als u de module wilt wijzigen en er enkele verbeteringen in wilt aanbrengen, vergeet dan niet de module opnieuw te registreren door het volgende commando uit te voeren op de WHM-server:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookQuery Monitoring en Caching
Met ProxySQL kunt u alle query's volgen die afkomstig zijn van de toepassing die zijn doorgegeven of er doorheen gaan. De standaard WHM biedt dit detailniveau niet in MySQL-querymonitoring. Het volgende toont alle MySQL-query's die zijn vastgelegd door ProxySQL:
Met ClusterControl kunt u eenvoudig de meest herhaalde zoekopdrachten opzoeken en in de cache plaatsen via de ProxySQL-querycachefunctie. Gebruik de vervolgkeuzelijst "Order By" om de zoekopdrachten te sorteren op "Count Star", ga naar de query die u in de cache wilt plaatsen en klik op de knop "Query cachen" eronder. Het volgende dialoogvenster verschijnt:
De resultatenset van query's in de cache wordt opgeslagen en bediend door de ProxySQL zelf, waardoor het aantal hits naar de backend wordt verminderd, waardoor uw MySQL-replicatiecluster als geheel wordt ontlast. De implementatie van ProxySQL-querycache verschilt fundamenteel van de MySQL-querycache. Het is een op tijd gebaseerde cache en zal verlopen na een time-out genaamd "Cache TTL". In deze configuratie willen we de bovenstaande query gedurende 5 seconden (5000 ms) in de cache opslaan om de lezersgroep te bereiken waar de doelhostgroep 20 is.
Lezen/schrijven splitsen en balanceren
Door te luisteren naar MySQL-standaardpoort 3306, gedraagt ProxySQL zich een beetje als de MySQL-server zelf. Het spreekt MySQL-protocollen op zowel frontend als backend. De queryregels die door ClusterControl zijn gedefinieerd bij het instellen van de ProxySQL, splitsen automatisch alle leesbewerkingen (^SELECT .* in Regex-taal) naar hostgroep 20, de lezersgroep, en de rest wordt doorgestuurd naar de schrijver-hostgroep 10, zoals weergegeven in de volgende sectie met zoekregels:
Met deze architectuur hoeft u zich geen zorgen te maken over het opsplitsen van lees-/schrijfquery's, aangezien ProxySQL het werk voor u zal doen. De gebruikers hebben minimale tot geen wijzigingen in de code, waardoor de hostinggebruikers alle applicaties en functies van WHM en cPanel native kunnen gebruiken, vergelijkbaar met het verbinden met een zelfstandige MySQL-installatie.
In termen van verbindingsbalancering, als u meer dan één actief knooppunt in een bepaalde hostgroep hebt (zoals lezer hostgroep 20 in dit voorbeeld), zal ProxySQL automatisch de belasting tussen hen verdelen op basis van een aantal criteria - gewichten, replicatievertraging, gebruikte verbindingen , algehele belasting en latentie. Van ProxySQL is bekend dat het zeer goed is in een omgeving met hoge gelijktijdigheid door een geavanceerd pooling-mechanisme voor verbindingen te implementeren. Geciteerd uit de ProxySQL-blogpost, implementeert ProxySQL niet alleen Persistent Connection, maar ook Connection Multiplexing. ProxySQL kan in feite honderdduizenden clients aan, maar stuurt al hun verkeer door naar enkele verbindingen naar de backend. ProxySQL kan dus N clientverbindingen en M backendverbindingen aan, waarbij N> M (zelfs N duizenden keren groter dan M).
MySQL-failover en herstel
Omdat ClusterControl het replicatiecluster beheert, wordt failover automatisch uitgevoerd als automatisch herstel is ingeschakeld. In geval van een masterfout:
- ClusterControl zal de masterfout detecteren en verifiëren via MySQL-client, SSH en ping.
- ClusterControl wacht 3 seconden voordat een failover-procedure wordt gestart.
- ClusterControl zal de meest up-to-date slave promoten om de volgende master te worden.
- Als de oude master weer online komt, wordt deze gestart als alleen-lezen, zonder deel te nemen aan de actieve replicatie.
- Het is aan gebruikers om te beslissen wat er met de oude master gebeurt. Het zou terug kunnen worden geïntroduceerd in de replicatieketen door gebruik te maken van de "Rebuild Replication Slave"-functionaliteit in ClusterControl.
- ClusterControl zal slechts één keer proberen de masterfailover uit te voeren. Als het niet lukt, is tussenkomst van de gebruiker vereist.
U kunt het hele failover-proces volgen onder ClusterControl -> Activiteit -> Jobs -> Failover naar een nieuwe master zoals hieronder weergegeven:
Tijdens de failover worden alle verbindingen met de databaseservers in de wachtrij geplaatst in ProxySQL. Ze worden pas beëindigd na time-out, beheerd door mysql-default_query_timeout variabele die 86400000 milliseconden of 24 uur is. De applicaties zullen op dit moment hoogstwaarschijnlijk geen fouten of storingen in de database zien, maar de afweging is een verhoogde latentie, binnen een configureerbare drempel.
Op dit punt zal ClusterControl de topologie presenteren zoals hieronder:
Als we willen toestaan dat de oude master weer deelneemt aan de replicatie nadat deze is geactiveerd en beschikbaar is, moeten we deze opnieuw opbouwen als een slaaf door naar ClusterControl -> Nodes -> kies de oude master -> Rebuild Replication Slave -> kies de nieuwe master -> Doorgaan . Zodra het opnieuw opbouwen is voltooid, zou u de volgende topologie moeten krijgen (merk op dat 192.168.0.32 nu de master is):
Serverconsolidatie en databaseschaling
Met deze architectuur kunnen we veel MySQL-servers die zich op elke WHM-server bevinden, consolideren in één enkele replicatie-installatie. U kunt meer databaseknooppunten schalen naarmate u groeit, of meerdere replicatieclusters hebben om ze allemaal te ondersteunen en beheerd door een enkele ClusterControl-server. Het volgende architectuurdiagram illustreert of we twee WHM-servers hebben die zijn verbonden met één enkel MySQL-replicatiecluster via ProxySQL-socketbestand:
Het bovenstaande stelt ons in staat om de twee belangrijkste lagen in ons hostingsysteem te scheiden - applicatie (front-end) en database (back-end). Zoals u wellicht weet, leidt het co-lokaliseren van MySQL op de WHM-server gewoonlijk tot uitputting van bronnen, aangezien MySQL vooraf een enorme RAM-toewijzing nodig heeft om op te starten en goed te presteren (meestal afhankelijk van de innodb_buffer_pool_size variabel). Aangezien de schijfruimte voldoende is, kunt u met de bovenstaande configuratie meer hostingaccounts per server hebben, waarbij alle serverbronnen kunnen worden gebruikt door de front-end-laagtoepassingen.
Het opschalen van het MySQL-replicatiecluster zal veel eenvoudiger zijn met een aparte laagarchitectuur. Als laten we zeggen dat de master een opschaling (upgrade van RAM, harde schijf, RAID, NIC) onderhoud nodig heeft, kunnen we de masterrol overschakelen naar een andere slave (ClusterControl -> Nodes -> kies een slave -> Slave promoten ) en voer vervolgens de onderhoudstaak uit zonder de MySQL-service als geheel te beïnvloeden. Voor scale-out-bewerking (meer slaves toevoegen), kunt u dat uitvoeren zonder zelfs de master te beïnvloeden door de staging rechtstreeks vanaf een actieve slave uit te voeren. Met ClusterControl kunt u zelfs een nieuwe slave maken van een bestaande MySQL-back-up (alleen PITR-compatibel):
Het opnieuw opbouwen van een slave vanaf een back-up brengt geen extra last voor de master met zich mee. ClusterControl kopieert het geselecteerde back-upbestand van de ClusterControl-server naar het doelknooppunt en voert het herstel daar uit. Als dit klaar is, maakt het knooppunt verbinding met de master en begint het alle ontbrekende transacties sinds de hersteltijd op te halen en de master in te halen. Wanneer het achterblijft, zal ProxySQL het knooppunt niet in de taakverdelingsset opnemen totdat de replicatievertraging minder dan 10 seconden is (configureerbaar bij het toevoegen van een mysql_servers-tabel via de ProxySQL-beheerdersinterface).
Laatste gedachten
ProxySQL breidt de mogelijkheden van WHM cPanel uit bij het beheren van MySQL-replicatie. Nu ClusterControl uw replicatiecluster beheert, zijn alle complexe taken die nodig zijn om het replicatiecluster te beheren nu eenvoudiger dan ooit tevoren.