I den första delen av serien visade vi dig hur du distribuerar en MySQL-replikeringsinställning med ProxySQL med WHM och cPanel. I den här delen kommer vi att visa några operationer efter implementeringen för underhåll, hantering, failover samt fördelar jämfört med den fristående installationen.
MySQL-användarhantering
Med denna integration aktiverad måste MySQL-användarhantering göras från WHM eller cPanel. Annars skulle ProxySQL mysql_users-tabellen inte synkroniseras med det som är konfigurerat för vår replikeringsmaster. Anta att vi redan har skapat en användare som heter fleran_user1 (MySQL-användarnamnet får automatiskt prefix av cPanel för att följa MySQL-begränsningen), och vi skulle vilja tilldela databasen fleran_db1 som nedan:
Ovanstående kommer att resultera i följande mysql_users-tabellutdata i ProxySQL:
Om du vill skapa MySQL-resurser utanför cPanel kan du använda ClusterControl -> Hantera -> Schema och användare och importera sedan databasanvändaren till ProxySQL genom att gå till ClusterControl -> Noder -> välj ProxySQL-noden -> Användare -> Importera användare .
Proxysqlhook-modulen som vi använder för att synkronisera ProxySQL-användare skickar felsökningsloggarna till /usr/local/cpanel/logs/error_log. Använd den här filen för att inspektera och förstå vad som händer bakom kulisserna. Följande rader skulle visas i cPanel-loggfilen om vi installerade en webbapplikation som heter Zikula med 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 *****Du skulle se några upprepade rader som "Kontrollerar om {DB-användare} existerar" eftersom WHM skapar flera MySQL-användare/värd för varje skapa databasanvändarförfrågan. I vårt exempel skulle WHM skapa dessa 3 användare:
ProxySQL behöver bara användarnamn, lösenord och standardvärdgruppsinformation när du lägger till en användare. Därför är kontrollraderna till för att undvika flera inlägg av exakt samma användare.
Om du vill modifiera modulen och göra några förbättringar i den, glöm inte att registrera om modulen genom att köra följande kommando på WHM-servern:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookFrågeövervakning och cachelagring
Med ProxySQL kan du övervaka alla frågor som kommer från applikationen som har skickats eller passerar genom den. Standard WHM tillhandahåller inte denna detaljnivå i MySQL-frågeövervakning. Följande visar alla MySQL-frågor som har fångats av ProxySQL:
Med ClusterControl kan du enkelt slå upp de mest upprepade frågorna och cache dem via ProxySQL-frågecache-funktionen. Använd rullgardinsmenyn "Beställ efter" för att sortera frågorna efter "Räkna stjärna", gå över till frågan som du vill cache och klicka på knappen "Cacheförfrågan" under den. Följande dialogruta visas:
Resultatuppsättningen av cachade frågor kommer att lagras och betjänas av själva ProxySQL, vilket minskar antalet träffar till backend som kommer att avlasta ditt MySQL-replikeringskluster som helhet. Implementeringen av ProxySQL-frågecache skiljer sig fundamentalt från MySQL-frågecache. Det är tidsbaserad cache och kommer att löpa ut efter en timeout som kallas "Cache TTL". I den här konfigurationen vill vi cachelagra ovanstående fråga i 5 sekunder (5000 ms) från att träffa läsargruppen där målvärdgruppen är 20.
Läs/skrivdelning och balansering
Genom att lyssna på MySQL standardport 3306, agerar ProxySQL som själva MySQL-servern. Den talar MySQL-protokoll på både frontend och backend. Frågereglerna som definieras av ClusterControl när du ställer in ProxySQL kommer automatiskt att dela upp alla läsningar (^SELECT .* på Regex-språk) till värdgrupp 20 som är läsargruppen, och resten kommer att vidarebefordras till skrivarvärdgrupp 10, som visas i följande avsnitt för frågeregler:
Med den här arkitekturen behöver du inte oroa dig för att dela upp läs/skrivfrågor eftersom ProxySQL kommer att göra jobbet åt dig. Användarna har minimala eller inga ändringar i koden, vilket gör det möjligt för värdanvändarna att använda alla applikationer och funktioner som tillhandahålls av WHM och cPanel, på samma sätt som att ansluta till en fristående MySQL-installation.
När det gäller anslutningsbalansering, om du har mer än en aktiv nod i en viss värdgrupp (som reader hostgroup 20 i det här exemplet), kommer ProxySQL automatiskt att sprida belastningen mellan dem baserat på ett antal kriterier - vikter, replikeringsfördröjning, anslutningar som används , total belastning och latens. ProxySQL är känt för att vara mycket bra i miljöer med hög samtidighet genom att implementera en avancerad anslutningspoolningsmekanism. Citerat från ProxySQL blogginlägg, ProxySQL implementerar inte bara Persistent Connection, utan också Connection Multiplexing. Faktum är att ProxySQL kan hantera hundratusentals klienter, men ändå vidarebefordra all deras trafik till ett fåtal anslutningar till backend. Så ProxySQL kan hantera N klientanslutningar och M backend-anslutningar, där N> M (även N tusentals gånger större än M).
MySQL-failover och återställning
När ClusterControl hanterar replikeringsklustret, utförs failover automatiskt om automatisk återställning är aktiverad. Vid ett masterfel:
- ClusterControl kommer att upptäcka och verifiera huvudfelet via MySQL-klient, SSH och ping.
- ClusterControl väntar i 3 sekunder innan en failover-procedur påbörjas.
- ClusterControl kommer att marknadsföra den mest uppdaterade slaven för att bli nästa master.
- Om den gamla mastern kommer tillbaka online kommer den att startas som skrivskyddad utan att delta i den aktiva replikeringen.
- Det är upp till användarna att bestämma vad som ska hända med den gamla mästaren. Det skulle kunna introduceras tillbaka till replikeringskedjan genom att använda funktionen "Rebuild Replication Slave" i ClusterControl.
- ClusterControl kommer bara att försöka utföra master-failoveren en gång. Om det misslyckas krävs ingripande från användaren.
Du kan övervaka hela failover-processen under ClusterControl -> Aktivitet -> Jobb -> Failover till en ny master som visas nedan:
Under failover kommer alla anslutningar till databasservrarna att stå i kö i ProxySQL. De kommer inte att avslutas förrän timeout, kontrolleras av mysql-default_query_timeout variabel som är 86400000 millisekunder eller 24 timmar. Applikationerna skulle med största sannolikhet inte se fel eller misslyckanden i databasen vid denna tidpunkt, men avvägningen är ökad latens, inom en konfigurerbar tröskel.
Vid denna tidpunkt kommer ClusterControl att presentera topologin enligt nedan:
Om vi skulle vilja tillåta den gamla mastern att gå tillbaka till replikeringen efter att den är uppe och tillgänglig, skulle vi behöva bygga om den som en slav genom att gå till ClusterControl -> Noder -> välj den gamla mastern -> Bygg om replikering Slav -> välj den nya mästaren -> Fortsätt . När ombyggnaden är klar bör du få följande topologi (notera att 192.168.0.32 är master nu):
Serverkonsolidering och databasskalning
Med den här arkitekturen kan vi konsolidera många MySQL-servrar som finns på varje WHM-server till en enda replikeringsuppsättning. Du kan skala fler databasnoder när du växer, eller ha flera replikeringskluster för att stödja dem alla och hanteras av en enda ClusterControl-server. Följande arkitekturdiagram visar om vi har två WHM-servrar anslutna till ett enda MySQL-replikeringskluster via ProxySQL-socketfil:
Ovanstående tillåter oss att separera de två viktigaste nivåerna i vårt värdsystem - applikation (front-end) och databas (back-end). Som du kanske vet leder samlokalisering av MySQL i WHM-servern vanligtvis till resursutmattning eftersom MySQL kräver en enorm RAM-allokering i förväg för att starta upp och prestera bra (mest beroende på innodb_buffer_pool_size variabel). Med tanke på att diskutrymmet är tillräckligt, med ovanstående inställning, kan du ha fler värdkonton värd per server, där alla serverresurser kan utnyttjas av front-end tier-applikationerna.
Att skala upp MySQL-replikeringsklustret blir mycket enklare med en separat tier-arkitektur. Om låt oss säga att mastern kräver en uppskalning (uppgradering av RAM, hårddisk, RAID, NIC) underhåll, kan vi byta över masterrollen till en annan slav (ClusterControl -> Noder -> välj en slav -> Promote slav ) och utför sedan underhållsuppgiften utan att påverka MySQL-tjänsten som helhet. För utskalningsoperation (lägga till fler slavar) kan du utföra det utan att ens påverka mastern genom att utföra iscensättningen direkt från någon aktiv slav. Med ClusterControl kan du till och med iscensätta en ny slav från en befintlig MySQL-säkerhetskopia (endast PITR-kompatibel):
Att bygga om en slav från backup kommer inte att medföra ytterligare börda för mastern. ClusterControl kopierar den valda säkerhetskopian från ClusterControl-servern till målnoden och utför återställningen där. När det är klart kommer noden att ansluta till mastern och börjar hämta alla saknade transaktioner sedan återställningstiden och komma ikapp mastern. När det släpar kommer ProxySQL inte att inkludera noden i belastningsbalanseringsuppsättningen förrän replikeringsfördröjningen är mindre än 10 sekunder (kan konfigureras när en mysql_servers-tabell läggs till via ProxySQL-administratörsgränssnittet).
Sluta tankar
ProxySQL utökar WHM cPanels möjligheter för att hantera MySQL-replikering. Med ClusterControl som hanterar ditt replikeringskluster är alla komplexa uppgifter som är involverade i att hantera replikeringsklustret nu enklare än någonsin tidigare.