Molnet erbjuder mycket flexibla miljöer att arbeta med. Du kan enkelt skala upp och ned genom att lägga till eller ta bort noder. Om det finns ett behov kan du enkelt skapa en klon av din miljö. Detta kan användas för processer som uppgraderingar, belastningstester, katastrofåterställning. Det största problemet du måste hantera är att applikationer måste ansluta till databaserna på något sätt, och flexibla inställningar kan vara knepiga för databaser - speciellt med master-slave-inställningar. Lyckligtvis finns det några alternativ för att göra denna process enklare.
Ett sätt är att använda en databasproxy. Det finns flera proxyservrar att välja på, men i det här blogginlägget kommer vi att använda ProxySQL, en välkänd proxy tillgänglig för MySQL och MariaDB. Vi kommer att visa hur du kan använda det för att effektivt flytta trafik mellan MySQL-noder utan synlig påverkan för applikationen. Vi kommer också att förklara några begränsningar och nackdelar med detta tillvägagångssätt.
Initial molnkonfiguration
Låt oss först diskutera inställningen. Vi kommer att använda AWS EC2-instanser för vår miljö. Eftersom vi bara testar bryr vi oss egentligen inte om hög tillgänglighet annat än vad vi vill visa vara möjligt - sömlösa masterändringar. Därför kommer vi att använda en enda applikationsnod och en enda ProxySQL-nod. Enligt god praxis kommer vi att samlokalisera ProxySQL på applikationsnoden och applikationen kommer att konfigureras för att ansluta till ProxySQL via Unix-socket. Detta kommer att minska overhead relaterade till TCP-anslutningar och öka säkerheten - trafik från applikationen till proxyn kommer inte att lämna den lokala instansen, lämnar endast ProxySQL -> MySQL-anslutning att kryptera. Återigen, eftersom detta är ett enkelt test kommer vi inte att ställa in SSL. I produktionsmiljöer vill du göra det, även om du använder VPC.
Miljön kommer att se ut som i diagrammet nedan:
Som applikation kommer vi att använda Sysbench - ett syntetiskt benchmarkprogram för MySQL . Den har en möjlighet att inaktivera och aktivera användningen av transaktioner, som vi kommer att använda för att visa hur ProxySQL hanterar dem.
Installera ett MySQL-replikeringskluster med ClusterControl
För att göra distributionen snabb och effektiv kommer vi att använda ClusterControl för att distribuera MySQL-replikeringsinställningen åt oss. Installationen av ClusterControl kräver bara ett par steg. Vi går inte in på detaljer här men du bör öppna vår webbplats, registrering och installation av ClusterControl bör vara ganska enkel. Tänk på att du måste ställa in lösenordslös SSH mellan ClusterControl-instansen och alla noder som vi kommer att hantera med den.
När ClusterControl har installerats kan du logga in. Du kommer att presenteras med en distributionsguide:
Eftersom vi redan har instanser som körs i molnet, så kommer vi bara att gå med Alternativet "Distribuera". Vi kommer att presenteras med följande skärm:
Vi väljer MySQL-replikering som klustertyp och vi måste tillhandahålla anslutningsmöjligheter detaljer. Det kan vara en anslutning med root-användare eller det kan också vara en sudo-användare med eller utan lösenord.
I nästa steg måste vi fatta några beslut. Vi kommer att använda Percona Server för MySQL i sin senaste version. Vi måste också definiera ett lösenord för rotanvändaren på de noder som vi ska distribuera.
I det sista steget måste vi definiera en topologi - vi kommer att gå med vad vi föreslog i början - en herre och tre slavar.
ClusterControl startar distributionen - vi kan spåra den på fliken Aktivitet, som visas på skärmdumpen ovan.
När distributionen har slutförts kan vi se klustret i klusterlistan:
Installera ProxySQL 2.0 med ClusterControl
Nästa steg blir att distribuera ProxySQL. ClusterControl kan göra detta åt oss.
Vi kan göra detta i Manage -> Load Balancer.
Eftersom vi bara testar saker kommer vi att återanvända ClusterControl-instansen för ProxySQL och Sysbench. I verkligheten skulle du förmodligen vilja använda din "riktiga" applikationsserver. Om du inte hittar den i rullgardinsmenyn kan du alltid skriva serveradressen (IP eller värdnamn) för hand.
Vi vill också definiera referenser för övervakning och administrativ användare. Vi dubbelkollade också att ProxySQL 2.0 kommer att distribueras (du kan alltid ändra det till 1.4.x om du behöver).
På den nedre delen av guiden kommer vi att definiera användaren som ska vara skapat i både MySQL och ProxySQL. Om du har en befintlig applikation vill du förmodligen använda en befintlig användare. Om du använder flera användare för din applikation kan du alltid importera resten av dem senare, efter att ProxySQL kommer att distribueras.
Vi vill säkerställa att alla MySQL-instanser kommer att konfigureras i ProxySQL. Vi kommer att använda explicita transaktioner så vi ställer in switchen därefter. Detta är allt vi behövde göra - resten är att klicka på knappen "Deploy ProxySQL" och låta ClusterControl göra sitt.
När installationen är klar kommer ProxySQL att dyka upp på listan över noder i klustret. Som du kan se på skärmdumpen ovan har den redan upptäckt topologin och distribuerade noder över läsar- och skribentvärdgrupper.
Installera Sysbench
Det sista steget blir att skapa vår "applikation" genom att installera Sysbench. Processen är ganska enkel. Först måste vi installera förutsättningar, bibliotek och verktyg som krävs för att kompilera Sysbench:
[email protected]:~# apt install git automake libtool make libssl-dev pkg-config libmysqlclient-devDå vill vi klona sysbench-förvaret:
[email protected]:~# git clone https://github.com/akopytov/sysbench.gitÄntligen vill vi kompilera och installera Sysbench:
[email protected]:~# cd sysbench/
[email protected]:~/sysbench# ./autogen.sh && ./configure && make && make installDet här är det, Sysbench har installerats. Vi behöver nu generera lite data. För det måste vi först skapa ett schema. Vi kommer att ansluta till lokal ProxySQL och genom det kommer vi att skapa ett 'sbtest'-schema på mastern. Observera att vi använde Unix-socket för anslutning till 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 använda sysbench för att fylla databasen med data. Återigen använder vi Unix-socket för anslutning till proxyn:
[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 uppgifterna är klara kan vi gå vidare till våra tester.
Slutsats
I den andra delen av den här bloggen kommer vi att diskutera ProxySQL:s hantering av anslutningar, failover och dess inställningar som kan hjälpa oss att hantera huvudswitchen på ett sätt som kommer att vara minst påträngande för applikationen.