ProxySQL är en av de bästa proxyservrarna för MySQL. Det introducerade en hel del alternativ för databasadministratörer. Det gjorde det möjligt att forma databastrafiken genom att fördröja, cachelagra eller skriva om frågor i farten. Det kan också användas för att skapa en miljö där failovers inte påverkar applikationer och kommer att vara transparenta för dem. Vi har redan täckt de viktigaste ProxySQL-funktionerna i tidigare blogginlägg:
- Så här använder du ClusterControl och ProxySQL för cachning av frågor
- Hur man bygger en SQL-brandvägg med ClusterControl och ProxySQL
- Hur man distribuerar ett ProxySQL-kluster
- Hur man enkelt distribuerar MySQL-replikeringsmiljö med ProxySQL för hög tillgänglighet
Vi har till och med en handledning som täcker ProxySQL som visar hur den kan användas i MySQL- och MariaDB-inställningar.
Ganska nyligen har ProxySQL 2.0.3 släppts, vilket är en patch-release för 2.0-serien. Buggar håller på att fixas och 2.0-linjen verkar börja få den dragkraft den förtjänar. I det här blogginlägget vill vi diskutera stora förändringar som införts i ProxySQL 2.0.
Kausala avläsningar med GTID
Alla som var tvungna att hantera replikeringsfördröjning och kämpade med läs-efter-skriv-scenarier som påverkas av replikeringsfördröjningen kommer definitivt att vara mycket nöjda med den här funktionen. Hittills, i MySQL-replikeringsmiljöer, var det enda sättet att säkerställa kausala läsningar att läsa från mastern (och det spelar ingen roll om du använder asynkron eller semisynkron replikering). Ett annat alternativ var att välja Galera, som hade ett alternativ för att upprätthålla kausala läsningar sedan, typ, alltid (först brukade det vara wsrep-causal-reads och nu är det wsrep-sync-wait). Ganska nyligen (i 8.0.14) fick MySQL Group-replikering liknande funktion. Regelbunden replikering kan dock inte på egen hand hantera detta problem. Lyckligtvis är ProxySQL här och det ger oss ett alternativ att definiera på regelbasis per fråga med vilken värdgrupp som läser som matchar den frågeregeln som ska vara konsekvent. Implementeringen kommer med ProxySQL binlog-läsare och den kan fungera med ROW binlog-format för MySQL 5.7 och nyare. Endast Oracle MySQL stöds på grund av brist på nödvändig funktionalitet i MariaDB. Denna funktion och dess tekniska detaljer har förklarats på ProxySQL officiella blogg.
SSL för gränssnittsanslutningar
ProxySQL hade alltid stöd för backend SSL-anslutning men den saknade SSL-kryptering för anslutningarna som kom från klienter. Detta var inte så stor sak med tanke på att det rekommenderade distributionsmönstret var att samlokalisera ProxySQL på applikationsnoder och använda en säker Unix-socket för att ansluta från appen till proxyn. Det här är fortfarande en rekommendation, speciellt om du använder ProxySQL för cachning av frågor (Unix-sockets är snabbare än TCP-anslutning, även lokala och med cache är det bra att undvika att introducera onödig latens). Vad som är bra är att med ProxySQL 2.0 finns det ett val nu eftersom det introducerade SSL-stöd för inkommande anslutningar. Du kan enkelt aktivera det genom att ställa in mysql-have_ssl till "true". Att aktivera SSL kommer inte med oacceptabel prestandapåverkan. Tvärtom, enligt resultat från den officiella ProxySQL-bloggen är prestandafallet mycket lågt.
Inbyggt stöd för Galera Cluster
Galera Cluster har stötts av ProxySQL nästan sedan starten men hittills har det gjorts genom det externa skriptet som (vanligtvis) har anropats från ProxySQL:s interna schemaläggare. Det var upp till skriptet att säkerställa att ProxySQL-konfigurationen var korrekt, skribenten (eller skribenterna) har upptäckts korrekt och konfigurerats i writers hostgroup. Skriptet kunde detektera de olika tillstånden som Galera-noden kan ha (Primär, icke-Primär, Synkroniserad, Donator/Desync, Joining, Joined) och markera noden som antingen tillgänglig eller inte. Huvudfrågan är att originalmanuset aldrig var tänkt som något annat än proof of concept skrivet i Bash. Men när den distribuerades tillsammans med ProxySQL började den förbättras, modifierad av externa bidragsgivare. Andra (som Percona) tittade på att skapa sina egna skript, tillsammans med sin programvara. Vissa korrigeringar har introducerats i skriptet från ProxySQL-repository, några har introducerats i Percona-versionen av skriptet. Detta ledde till förvirring och även om alla vanligt använda skript hanterade 95 % av användningsfallen, täckte ingen av de populära verkligen alla de olika situationer och variabler som Galera kluster kan komma att använda. Som tur är kommer ProxySQL 2.0 med inbyggt stöd för Galera Cluster. Detta gör att ProxySQL stöder internt MySQL-replikering, MySQL-gruppreplikering och nu Galera Cluster. Sättet på hur det görs är väldigt likt. Vi skulle vilja täcka konfigurationen av den här funktionen eftersom den kanske inte är tydlig vid första anblicken.
Precis som med MySQL-replikering och MySQL-gruppreplikering har en tabell skapats 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)Det finns många inställningar att konfigurera och vi kommer att gå igenom dem en efter en. Först och främst finns det fyra värdgrupper:
- Writer_hostgroup - den kommer att innehålla alla skribenter (med read_only=0) upp till inställningen "max_writers". Som standard är det bara en författare
- Backup_writer_hostgroup - den innehåller återstående skribenter (read_only=0) som finns kvar efter att "max_writers" har lagts till i writer_hostgroup
- Reader_hostgroup - den innehåller läsare (read_only=1), den kan också innehålla backup-skrivare, enligt inställningen "writer_is_also_reader"
- Offline_hostgroup – den innehåller noder som inte ansågs användbara (antingen offline eller i ett tillstånd som gör att de inte kan hantera trafik)
Sedan har vi återstående inställningar:
- Aktiv – om posten i mysql_galera_hostgroups är aktiv eller inte
- Max_writers - hur många noder som högst kan placeras i writer_hostgroup
- Writer_is_also_reader - om satt till 0, kommer writers (read_only=0) inte att läggas in i reader_hostgroup. Om satt till 1 kommer skribenter (read_only=0) att läggas in i reader_hostgroup. Om satt till 2 kommer noder från backup_writer_hostgroup att läggas in i reader_hostgroup. Den här är lite komplex, därför kommer vi att presentera ett exempel senare i det här blogginlägget
- Max_transactions_behind - baserat på wsrep_local_recv_queue, maxkön som är acceptabel. Om kön på noden överstiger max_transactions_behind kommer given nod att markeras som SHUNNED och den kommer inte att vara tillgänglig för trafiken
Den största överraskningen kan vara hanteringen av läsarna, vilket är annorlunda än hur skriptet som ingår i ProxySQL fungerade. Först och främst, vad du måste tänka på är det faktum att ProxySQL använder read_only=1 för att avgöra om noden är en läsare eller inte. Detta är vanligt i replikeringsinställningar, inte så vanligt i Galera. Därför kommer du troligen att vilja använda inställningen "writer_is_also_reader" för att konfigurera hur läsare ska läggas till i reader_hostgroup. Låt oss betrakta tre Galera-noder, alla har read_only=0. Vi har också max_writers=1 eftersom vi vill rikta alla skrivningar mot en nod. Vi konfigurerade mysql_galera_hostgroups enligt följande:
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)Låt oss gå igenom alla alternativ:
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)Detta resultat är annorlunda än du skulle se i skripten - där skulle du ha återstående noder markerade som läsare. Här, med tanke på att vi inte vill att författare ska vara läsare och med tanke på att det inte finns någon nod med read_only=1, kommer inga läsare att konfigureras. En författare (enligt max_writers), återstående 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)Här vill vi att våra skribenter ska fungera som läsare, därför kommer alla (aktiva och backup) att läggas in 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)Det här är en inställning för dem som inte vill att deras aktiva författare ska hantera läsningar. I det här fallet kommer endast noder från backup_writer_hostgroup att användas för läsningar. Tänk också på att antalet läsare kommer att ändras om du ställer in max_writers till något annat värde. Om vi skulle ställa in den på 3, skulle det inte finnas några backup-skrivare (alla noder skulle hamna i skribentvärdgruppen), så det skulle återigen inte finnas några noder i läsarvärdgruppen.
Naturligtvis kommer du att vilja konfigurera frågeregler i enlighet med värdgruppens konfiguration. Vi kommer inte att gå igenom denna process här, du kan kolla hur det kan göras i ProxySQL-bloggen. Om du vill testa hur det fungerar i en Docker-miljö har vi en blogg som tar upp hur du kör Galera cluster och ProxySQL 2.0 på Docker.
Övriga ändringar
Det vi beskrev ovan är de mest anmärkningsvärda förbättringarna i ProxySQL 2.0. Det finns många andra, enligt ändringsloggen. Värt att nämna är förbättringar kring frågecache (till exempel tillägg av PROXYSQL FLUSH QUERY CACHE) och förändring som gör att ProxySQL kan förlita sig på super_read_only för att fastställa master och slavar i replikeringsinställningarna.
Vi hoppas att denna korta översikt över ändringarna i ProxySQL 2.0 kommer att hjälpa dig att avgöra vilken version av ProxySQL du ska använda. Kom ihåg att 1.4-grenen, även om den inte kommer att få några nya funktioner, bibehålls den fortfarande.