Skyen giver meget fleksible miljøer at arbejde med. Du kan nemt skalere det op og ned ved at tilføje eller fjerne noder. Hvis der er et behov, kan du nemt oprette en klon af dit miljø. Dette kan bruges til processer som opgraderinger, belastningstest, katastrofegendannelse. Det største problem, du skal forholde dig til, er, at applikationer skal oprette forbindelse til databaserne på en eller anden måde, og fleksible opsætninger kan være vanskelige for databaser - især med master-slave-opsætninger. Heldigvis er der nogle muligheder for at gøre denne proces lettere.
En måde er at bruge en databaseproxy. Der er flere proxyer at vælge imellem, men i dette blogindlæg vil vi bruge ProxySQL, en velkendt proxy tilgængelig for MySQL og MariaDB. Vi skal vise, hvordan du kan bruge det til effektivt at flytte trafik mellem MySQL-noder uden synlig påvirkning af applikationen. Vi vil også forklare nogle begrænsninger og ulemper ved denne tilgang.
Initial Cloud-opsætning
Lad os først diskutere opsætningen. Vi vil bruge AWS EC2-instanser til vores miljø. Da vi kun tester, er vi ligeglade med høj tilgængelighed udover det, vi gerne vil vise som muligt - sømløse masterændringer. Derfor vil vi bruge en enkelt applikationsknude og en enkelt ProxySQL-knude. I henhold til god praksis samler vi ProxySQL på applikationsknuden, og applikationen vil blive konfigureret til at oprette forbindelse til ProxySQL via Unix-socket. Dette vil reducere overhead relateret til TCP-forbindelser og øge sikkerheden - trafik fra applikationen til proxy'en vil ikke forlade den lokale instans, hvilket kun efterlader ProxySQL -> MySQL-forbindelse til at kryptere. Igen, da dette er en simpel test, vil vi ikke opsætte SSL. I produktionsmiljøer vil du gerne gøre det, selvom du bruger VPC.
Miljøet vil se ud som i diagrammet nedenfor:
Som applikationen vil vi bruge Sysbench - et syntetisk benchmarkprogram til MySQL . Det har en mulighed for at deaktivere og aktivere brugen af transaktioner, som vi vil bruge til at demonstrere, hvordan ProxySQL håndterer dem.
Installation af en MySQL-replikeringsklynge ved hjælp af ClusterControl
For at gøre implementeringen hurtig og effektiv vil vi bruge ClusterControl til at implementere MySQL-replikeringsopsætningen for os. Installationen af ClusterControl kræver blot et par trin. Vi vil ikke gå i detaljer her, men du bør åbne vores hjemmeside, registrering og installation af ClusterControl burde være ret ligetil. Husk, at du skal konfigurere adgangskodefri SSH mellem ClusterControl-instansen og alle noder, som vi skal administrere med den.
Når ClusterControl er blevet installeret, kan du logge ind. Du vil blive præsenteret for en implementeringsguide:
Da vi allerede har forekomster, der kører i skyen, vil vi derfor bare gå med "Deploy" mulighed. Vi vil blive præsenteret for følgende skærmbillede:
Vi vælger MySQL-replikering som klyngetype, og vi skal sørge for tilslutningsmuligheder detaljer. Det kan være forbindelse ved hjælp af root-bruger, eller det kan lige så godt være en sudo-bruger med eller uden adgangskode.
I det næste trin skal vi træffe nogle beslutninger. Vi vil bruge Percona Server til MySQL i sin seneste version. Vi skal også definere en adgangskode for root-brugeren på de noder, vi vil implementere.
I det sidste trin skal vi definere en topologi - vi vil gå med hvad vi foreslog i begyndelsen - en herre og tre slaver.
ClusterControl starter implementeringen - vi kan spore den på fanen Aktivitet, som vist på skærmbilledet ovenfor.
Når implementeringen er afsluttet, kan vi se klyngen på klyngelisten:
Installation af ProxySQL 2.0 ved hjælp af ClusterControl
Det næste trin vil være at implementere ProxySQL. ClusterControl kan gøre dette for os.
Vi kan gøre dette i Administrer -> Load Balancer.
Da vi bare tester tingene, vil vi genbruge ClusterControl-forekomsten til ProxySQL og Sysbench. I det virkelige liv vil du sikkert gerne bruge din "rigtige" applikationsserver. Hvis du ikke kan finde den i rullemenuen, kan du altid skrive serveradressen (IP eller værtsnavn) i hånden.
Vi ønsker også at definere legitimationsoplysninger for overvågning og administrative brugere. Vi har også dobbelttjekket, at ProxySQL 2.0 vil blive implementeret (du kan altid ændre det til 1.4.x, hvis du har brug for det).
På den nederste del af guiden vil vi definere den bruger, der skal oprettet i både MySQL og ProxySQL. Hvis du har en eksisterende applikation, vil du sandsynligvis bruge en eksisterende bruger. Hvis du bruger adskillige brugere til din applikation, kan du altid importere resten af dem senere, efter at ProxySQL vil blive implementeret.
Vi ønsker at sikre, at alle MySQL-forekomster bliver konfigureret i ProxySQL. Vi vil bruge eksplicitte transaktioner, så vi indstiller kontakten i overensstemmelse hermed. Dette er alt, hvad vi behøvede at gøre - resten er at klikke på knappen "Deploy ProxySQL" og lade ClusterControl gøre sit.
Når installationen er fuldført, vises ProxySQL på listen over noder i klyngen. Som du kan se på skærmbilledet ovenfor, har den allerede registreret topologien og distribueret noder på tværs af læser- og skribentværtsgrupper.
Installation af Sysbench
Det sidste trin vil være at oprette vores "applikation" ved at installere Sysbench. Processen er ret enkel. Først skal vi installere forudsætninger, biblioteker og værktøjer, der kræves for at kompilere Sysbench:
[email protected]:~# apt install git automake libtool make libssl-dev pkg-config libmysqlclient-devSå vil vi klone sysbench-lageret:
[email protected]:~# git clone https://github.com/akopytov/sysbench.gitTil sidst vil vi kompilere og installere Sysbench:
[email protected]:~# cd sysbench/
[email protected]:~/sysbench# ./autogen.sh && ./configure && make && make installDet er det, Sysbench er blevet installeret. Vi skal nu generere nogle data. Til det skal vi først oprette et skema. Vi vil oprette forbindelse til lokal ProxySQL, og gennem det vil vi oprette et 'sbtest'-skema på masteren. Bemærk venligst, at vi brugte Unix-socket til forbindelse med ProxySQL.
[email protected]:~/sysbench# mysql -S /tmp/proxysql.sock -u sbtest -psbtest
mysql> CREATE DATABASE sbtest;
Query OK, 1 row affected (0.01 sec)Nu kan vi bruge sysbench til at udfylde databasen med data. Igen bruger vi Unix-socket til forbindelse med proxyen:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --events=0 --time=3600 --mysql-socket=/tmp/proxysql.sock --mysql-user=sbtest --mysql-password=sbtest --tables=32 --report-interval=1 --skip-trx=on --table-size=100000 --db-ps-mode=disable prepareNår dataene er klar, kan vi fortsætte til vores test.
Konklusion
I den anden del af denne blog vil vi diskutere ProxySQL's håndtering af forbindelser, failover og dets indstillinger, der kan hjælpe os med at administrere hovedswitchen på en måde, der vil være mindst påtrængende for applikationen.