ProxySQL er en af de bedste proxyer derude til MySQL. Det introducerede en masse muligheder for databaseadministratorer. Det gjorde det muligt at forme databasetrafikken ved at forsinke, cache eller omskrive forespørgsler på farten. Det kan også bruges til at skabe et miljø, hvor failovers ikke vil påvirke applikationer og vil være gennemsigtige for dem. Vi har allerede dækket de vigtigste ProxySQL-funktioner i tidligere blogindlæg:
- Sådan bruger du ClusterControl og ProxySQL til cacheforespørgsler
- Sådan bygger du en SQL-firewall med ClusterControl og ProxySQL
- Sådan implementerer du en ProxySQL-klynge
- Sådan implementerer du nemt MySQL-replikeringsmiljø med ProxySQL for høj tilgængelighed
Vi har endda en tutorial, der dækker ProxySQL, der viser, hvordan den kan bruges i MySQL- og MariaDB-opsætninger.
For ganske nylig er ProxySQL 2.0.3 blevet frigivet, som er en patch-udgivelse til 2.0-serien. Fejl bliver rettet, og 2.0-linjen ser ud til at begynde at få den trækkraft, den fortjener. I dette blogindlæg vil vi gerne diskutere større ændringer introduceret i ProxySQL 2.0.
Kausale læsninger ved hjælp af GTID
Alle, der skulle håndtere replikeringsforsinkelse og kæmpede med læs-efter-skriv-scenarier, der er påvirket af replikeringsforsinkelsen, vil helt sikkert være meget tilfredse med denne funktion. Indtil videre, i MySQL-replikeringsmiljøer, var den eneste måde at sikre kausale læsninger på at læse fra masteren (og det er lige meget, om du bruger asynkron eller semisynkron replikering). En anden mulighed var at gå efter Galera, som havde en mulighed for at håndhæve kausale læsninger siden, som altid (først plejede det at være wsrep-causal-reads og nu er det wsrep-sync-wait). For ganske nylig (i 8.0.14) fik MySQL Group-replikering en lignende funktion. Almindelig replikering kan dog ikke i sig selv håndtere dette problem. Heldigvis er ProxySQL her, og det giver os en mulighed for at definere per-forespørgselsregelbasis med, hvilken værtsgruppe læser, som matcher den forespørgselsregel, der skal være konsistent. Implementeringen leveres med ProxySQL binlog-læser, og den kan fungere med ROW binlog-format til MySQL 5.7 og nyere. Kun Oracle MySQL understøttes på grund af manglende påkrævet funktionalitet i MariaDB. Denne funktion og dens tekniske detaljer er blevet forklaret på ProxySQL officielle blog.
SSL til frontend-forbindelser
ProxySQL havde altid understøttelse af backend SSL-forbindelse, men den manglede SSL-kryptering for forbindelserne, der kom fra klienter. Dette var ikke så stor en aftale, da det anbefalede implementeringsmønster var at samle ProxySQL på applikationsknudepunkter og bruge en sikker Unix-socket til at oprette forbindelse fra appen til proxyen. Dette er stadig en anbefaling, især hvis du bruger ProxySQL til cacheforespørgsler (Unix-sockets er hurtigere end TCP-forbindelse, selv lokale, og med cache er det godt at undgå at indføre unødvendig latency). Hvad der er godt er, at der med ProxySQL 2.0 er et valg nu, da det introducerede SSL-understøttelse for indgående forbindelser. Du kan nemt aktivere det ved at sætte mysql-have_ssl til 'true'. Aktivering af SSL kommer ikke med uacceptabel indvirkning på ydeevnen. I modsætning til resultaterne fra den officielle ProxySQL-blog er ydeevnefaldet meget lavt.
Native support for Galera Cluster
Galera Cluster er blevet understøttet af ProxySQL næsten siden starten, men indtil videre er det gjort gennem det eksterne script, der (typisk) er blevet kaldt fra ProxySQL's interne planlægger. Det var op til scriptet at sikre, at ProxySQL-konfigurationen var korrekt, skribenten (eller skribenterne) er blevet korrekt fundet og konfigureret i writers værtsgruppe. Scriptet var i stand til at detektere de forskellige tilstande, Galera-noden kan have (Primær, ikke-Primær, Synkroniseret, Donor/Desync, Joining, Joined) og markere noden som enten tilgængelig eller ej. Hovedproblemet er, at det originale manuskript aldrig var tænkt som andet end proof of concept skrevet i Bash. Men da det blev distribueret sammen med ProxySQL, begyndte det at blive forbedret, modificeret af eksterne bidragydere. Andre (som Percona) undersøgte at skabe deres egne scripts, bundtet med deres software. Nogle rettelser er blevet introduceret i scriptet fra ProxySQL repository, nogle er blevet introduceret i Percona version af scriptet. Dette førte til forvirring, og selvom alle almindeligt anvendte scripts håndterede 95 % af brugssagen, dækkede ingen af de populære virkelig alle de forskellige situationer og variabler, som Galera cluster kan ende med at bruge. Heldigvis kommer ProxySQL 2.0 med indbygget understøttelse af Galera Cluster. Dette gør, at ProxySQL understøtter internt MySQL-replikering, MySQL-gruppereplikering og nu Galera Cluster. Måden, hvordan det gøres, er meget ens. Vi vil gerne dække konfigurationen af denne funktion, da den måske ikke er klar ved første øjekast.
Som med MySQL-replikering og MySQL-gruppereplikering er der oprettet en tabel i ProxySQL:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Der er adskillige indstillinger at konfigurere, og vi vil gennemgå dem én efter én. Først og fremmest er der fire værtsgrupper:
- Writer_hostgroup - den vil indeholde alle forfatterne (med read_only=0) op til indstillingen 'max_writers'. Som standard er det kun én forfatter
- Backup_writer_hostgroup - den indeholder resterende skribenter (read_only=0), der er tilbage efter at 'max_writers' er blevet tilføjet til writer_hostgroup
- Reader_hostgroup - den indeholder læsere (read_only=1), den kan også indeholde backup writers, i henhold til indstillingen 'writer_is_also_reader'
- Offline_hostgroup - den indeholder noder, som blev anset for ubrugelige (enten offline eller i en tilstand, der gør dem umulige at håndtere trafik)
Så har vi resterende indstillinger:
- Aktiv – om indgangen i mysql_galera_hostgroups er aktiv eller ej
- Max_writers - hvor mange noder der højst kan placeres i writer_hostgroup
- Writer_is_also_reader - hvis den er sat til 0, vil forfattere (read_only=0) ikke blive sat ind i reader_hostgroup. Hvis indstillet til 1, vil forfattere (read_only=0) blive sat ind i reader_hostgroup. Hvis indstillet til 2, vil noder fra backup_writer_hostgroup blive sat ind i reader_hostgroup. Denne er lidt kompleks, derfor vil vi præsentere et eksempel senere i dette blogindlæg
- Max_transactions_behind - baseret på wsrep_local_recv_queue, den maksimale kø, der er acceptabel. Hvis køen på noden overstiger max_transactions_behind, vil den given node blive markeret som SHUNNED, og den vil ikke være tilgængelig for trafikken
Den største overraskelse kan være håndteringen af læserne, hvilket er anderledes end hvordan scriptet inkluderet i ProxySQL fungerede. Først og fremmest, hvad du skal huske på, er det faktum, at ProxySQL bruger read_only=1 til at afgøre, om node er en læser eller ej. Dette er almindeligt i replikeringsopsætninger, ikke så almindeligt i Galera. Derfor vil du højst sandsynligt bruge indstillingen 'writer_is_also_reader' til at konfigurere, hvordan læsere skal tilføjes til reader_hostgroup. Lad os overveje tre Galera-noder, alle har read_only=0. Vi har også max_writers=1, da vi ønsker at rette alle skrivningerne mod én node. Vi konfigurerede mysql_galera_hostgroups som følger:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Lad os gennemgå alle mulighederne:
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Dette resultat er anderledes, end du ville se i scripts - der ville du have resterende noder markeret som læsere. Her, givet at vi ikke ønsker at forfattere skal være læsere, og givet at der ikke er nogen node med read_only=1, vil ingen læsere blive konfigureret. Én forfatter (i henhold til max_writers), resterende noder i backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Her ønsker vi, at vores forfattere skal fungere som læsere, derfor vil de alle (aktive og backup) blive sat ind i reader_hostgroup.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Dette er en indstilling for dem, der ikke ønsker, at deres aktive forfatter skal håndtere læsninger. I dette tilfælde vil kun noder fra backup_writer_hostgroup blive brugt til læsninger. Husk også, at antallet af læsere vil ændre sig, hvis du indstiller max_writers til en anden værdi. Hvis vi havde sat den til 3, ville der ikke være nogen backup-skrivere (alle noder ville ende i writer-værtsgruppen), så der ville igen ikke være nogen noder i læseværtsgruppen.
Selvfølgelig vil du konfigurere forespørgselsregler i overensstemmelse med værtsgruppens konfiguration. Vi vil ikke gennemgå denne proces her, du kan tjekke hvordan det kan gøres i ProxySQL blog. Hvis du gerne vil teste, hvordan det fungerer i et Docker-miljø, har vi en blog, som dækker, hvordan du kører Galera cluster og ProxySQL 2.0 på Docker.
Andre ændringer
Det, vi beskrev ovenfor, er de mest bemærkelsesværdige forbedringer i ProxySQL 2.0. Der er mange andre, ifølge ændringsloggen. Værd at nævne er forbedringer omkring forespørgselscache (f.eks. tilføjelse af PROXYSQL FLUSH QUERY CACHE) og ændring, der gør det muligt for ProxySQL at stole på super_read_only for at bestemme master og slaver i replikeringsopsætning.
Vi håber, at denne korte oversigt over ændringerne i ProxySQL 2.0 vil hjælpe dig med at bestemme, hvilken version af ProxySQL du skal bruge. Husk venligst, at 1.4-grenen, selvom den ikke får nogen nye funktioner, bevares den stadig.