I den første del af serien viste vi dig, hvordan du implementerer en MySQL-replikeringsopsætning med ProxySQL med WHM og cPanel. I denne del vil vi vise nogle operationer efter implementering til vedligeholdelse, administration, failover samt fordele i forhold til den selvstændige opsætning.
MySQL-brugerstyring
Med denne integration aktiveret, skal MySQL-brugeradministration udføres fra WHM eller cPanel. Ellers ville ProxySQL mysql_users-tabel ikke synkronisere med det, der er konfigureret til vores replikeringsmaster. Lad os antage, at vi allerede har oprettet en bruger kaldet fleren_user1 (MySQL-brugernavnet bliver automatisk foranstillet af cPanel for at overholde MySQL-begrænsningen), og vi vil gerne tildele databasen severaln_db1 som nedenfor:
Ovenstående vil resultere i følgende mysql_users tabeloutput i ProxySQL:
Hvis du gerne vil oprette MySQL-ressourcer uden for cPanel, kan du bruge ClusterControl -> Administrer -> Skemaer og brugere funktionen og importer derefter databasebrugeren til ProxySQL ved at gå til ClusterControl -> Noder -> vælg ProxySQL-noden -> Brugere -> Importer brugere .
Proxysqlhook-modulet, som vi bruger til at synkronisere ProxySQL-brugere, sender fejlfindingslogfilerne til /usr/local/cpanel/logs/error_log. Brug denne fil til at inspicere og forstå, hvad der sker bag kulisserne. Følgende linjer ville blive vist i cPanel-logfilen, hvis vi installerede en webapplikation kaldet Zikula ved hjælp af 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 vil se nogle gentagne linjer som "Kontrollerer om {DB-bruger} eksisterer", fordi WHM opretter flere MySQL-bruger/vært for hver oprettelse af databasebrugeranmodning. I vores eksempel ville WHM oprette disse 3 brugere:
ProxySQL behøver kun brugernavnet, adgangskoden og standard værtsgruppeoplysninger, når du tilføjer en bruger. Derfor er kontrollinjerne der for at undgå flere indsættelser af nøjagtig samme bruger.
Hvis du gerne vil ændre modulet og lave nogle forbedringer i det, så glem ikke at omregistrere modulet ved at køre følgende kommando på WHM-serveren:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookForespørgselsovervågning og cachelagring
Med ProxySQL kan du overvåge alle forespørgsler, der kommer fra applikationen, som er blevet sendt eller passerer gennem den. Standard WHM giver ikke dette detaljeringsniveau i MySQL-forespørgselsovervågning. Det følgende viser alle MySQL-forespørgsler, der er blevet fanget af ProxySQL:
Med ClusterControl kan du nemt slå de mest gentagne forespørgsler op og cache dem via ProxySQL-forespørgselscache-funktionen. Brug rullemenuen "Bestil efter" til at sortere forespørgslerne efter "Tæl stjerne", rul over til den forespørgsel, du vil cache, og klik på knappen "Cacheforespørgsel" under den. Følgende dialog vises:
Resultatsættet af cachelagrede forespørgsler vil blive gemt og serveret af selve ProxySQL, hvilket reducerer antallet af hits til backend, som vil aflaste din MySQL-replikeringsklynge som helhed. Implementering af ProxySQL-forespørgselscache er fundamentalt forskellig fra MySQL-forespørgselscache. Det er tidsbaseret cache og vil blive udløbet efter en timeout kaldet "Cache TTL". I denne konfiguration vil vi gerne cache ovenstående forespørgsel i 5 sekunder (5000 ms) fra at ramme læsegruppen, hvor destinationsværtsgruppen er 20.
Læse/skriveopdeling og balancering
Ved at lytte til MySQL-standardport 3306 opfører ProxySQL sig ligesom MySQL-serveren selv. Den taler MySQL-protokoller på både frontend og backend. Forespørgselsreglerne defineret af ClusterControl ved opsætning af ProxySQL vil automatisk opdele alle læsninger (^SELECT .* i Regex-sprog) til værtsgruppe 20, som er læsegruppen, og resten vil blive videresendt til forfatterværtsgruppe 10, som vist i følgende afsnit om forespørgselsregler:
Med denne arkitektur behøver du ikke bekymre dig om at opdele læse/skrive-forespørgsler, da ProxySQL vil gøre jobbet for dig. Brugerne har minimale eller ingen ændringer i koden, hvilket giver hostingbrugerne mulighed for at bruge alle de applikationer og funktioner, der leveres af WHM og cPanel indbygget, svarende til at oprette forbindelse til en selvstændig MySQL-opsætning.
Med hensyn til forbindelsesbalancering, hvis du har mere end én aktiv node i en bestemt værtsgruppe (som læserværtsgruppe 20 i dette eksempel), vil ProxySQL automatisk sprede belastningen mellem dem baseret på en række kriterier - vægte, replikeringsforsinkelse, anvendte forbindelser , samlet belastning og latenstid. ProxySQL er kendt for at være meget god i høj samtidighed ved at implementere en avanceret forbindelsespooling-mekanisme. Citeret fra ProxySQL blogindlæg implementerer ProxySQL ikke kun Persistent Connection, men også Connection Multiplexing. Faktisk kan ProxySQL håndtere hundredtusindvis af klienter, men alligevel videresende al deres trafik til få forbindelser til backend. Så ProxySQL kan håndtere N klientforbindelser og M backend-forbindelser, hvor N> M (selv N tusinde gange større end M).
MySQL-failover og gendannelse
Når ClusterControl administrerer replikeringsklyngen, udføres failover automatisk, hvis automatisk gendannelse er aktiveret. I tilfælde af en masterfejl:
- ClusterControl vil opdage og verificere masterfejlen via MySQL-klient, SSH og ping.
- ClusterControl venter i 3 sekunder, før en failover-procedure påbegyndes.
- ClusterControl vil fremme den mest opdaterede slave til at blive den næste master.
- Hvis den gamle master kommer online igen, vil den blive startet som skrivebeskyttet uden at deltage i den aktive replikering.
- Det er op til brugerne at beslutte, hvad der skal ske med den gamle mester. Det kunne introduceres tilbage til replikeringskæden ved at bruge "Rebuild Replication Slave" funktionalitet i ClusterControl.
- ClusterControl vil kun forsøge at udføre master failover én gang. Hvis det mislykkes, er brugerindgreb påkrævet.
Du kan overvåge hele failover-processen under ClusterControl -> Aktivitet -> Jobs -> Failover til en ny master som vist nedenfor:
Under failover vil alle forbindelser til databaseserverne stå i kø i ProxySQL. De bliver ikke afsluttet før timeout, styret af mysql-default_query_timeout variabel, som er 86400000 millisekunder eller 24 timer. Applikationerne vil højst sandsynligt ikke se fejl eller fejl i databasen på dette tidspunkt, men afvejningen er øget latenstid inden for en konfigurerbar tærskel.
På dette tidspunkt vil ClusterControl præsentere topologien som nedenfor:
Hvis vi gerne vil tillade, at den gamle master slutter sig tilbage til replikeringen, efter at den er oppe og tilgængelig, skal vi genopbygge den som en slave ved at gå til ClusterControl -> Noder -> vælg den gamle master -> Genopbygg replikering Slave -> vælg den nye master -> Fortsæt . Når genopbygningen er færdig, bør du få følgende topologi (bemærk 192.168.0.32 er master nu):
Serverkonsolidering og databaseskalering
Med denne arkitektur kan vi konsolidere mange MySQL-servere, som findes på hver WHM-server, til én enkelt replikeringsopsætning. Du kan skalere flere databasenoder, efterhånden som du vokser, eller du kan have flere replikeringsklynger til at understøtte dem alle og administreres af en enkelt ClusterControl-server. Følgende arkitekturdiagram illustrerer, om vi har to WHM-servere forbundet til en enkelt MySQL-replikeringsklynge via ProxySQL-socket-fil:
Ovenstående giver os mulighed for at adskille de to vigtigste niveauer i vores hostingsystem - applikation (front-end) og database (back-end). Som du måske ved, resulterer samlokalisering af MySQL i WHM-serveren normalt til ressourceudmattelse, da MySQL har brug for en enorm forhånds-RAM-allokering for at starte op og yde godt (for det meste afhængigt af innodb_buffer_pool_size variabel). I betragtning af at diskpladsen er tilstrækkelig, kan du med ovenstående opsætning have flere hostingkonti hostet pr. server, hvor alle serverressourcerne kan udnyttes af front-end tier-applikationerne.
Opskalering af MySQL-replikeringsklyngen vil være meget enklere med en separat lagarkitektur. Hvis lad os sige, at masteren kræver en opskalering (opgradering af RAM, harddisk, RAID, NIC) vedligeholdelse, kan vi skifte masterrollen til en anden slave (ClusterControl -> Noder -> vælg en slave -> Promoter slave ) og udfør derefter vedligeholdelsesopgaven uden at påvirke MySQL-tjenesten som helhed. Til udskalering (tilføj flere slaver) kan du udføre det uden at påvirke masteren ved at udføre iscenesættelsen direkte fra en aktiv slave. Med ClusterControl kan du endda iscenesætte en ny slave fra en eksisterende MySQL backup (kun PITR-kompatibel):
Genopbygning af en slave fra backup vil ikke medføre yderligere byrde for masteren. ClusterControl kopierer den valgte backupfil fra ClusterControl-serveren til målknuden og udfører gendannelsen der. Når det er gjort, vil noden oprette forbindelse til masteren og begynder at hente alle de manglende transaktioner siden gendannelsestiden og indhente masteren. Når den halter, vil ProxySQL ikke inkludere noden i belastningsbalanceringssættet, før replikeringsforsinkelsen er mindre end 10 sekunder (kan konfigureres ved tilføjelse af en mysql_servers-tabel via ProxySQL admin-grænseflade).
Sidste tanker
ProxySQL udvider WHM cPanels muligheder til at administrere MySQL-replikering. Med ClusterControl, der administrerer din replikeringsklynge, er alle de komplekse opgaver involveret i at administrere replikeringsklyngen nu nemmere end nogensinde før.