MaxScale 2.4 släpptes den 21 december 2019 och ClusterControl 1.7.6 stöder övervakning och hantering upp till den här versionen. Men för distribution stöder ClusterControl endast upp till version 2.3. Man måste uppgradera instansen manuellt, och lyckligtvis är uppgraderingsstegen väldigt enkla. Ladda bara ner den senaste versionen från MariaDB MaxScale-nedladdningssidan och utför paketinstallationskommandot.
Följande kommandon visar hur man uppgraderar från en befintlig MaxScale 2.3 till MaxScale 2.4 på en CentOS 7-box:
$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10I det här blogginlägget kommer vi att lyfta fram några av de anmärkningsvärda förbättringarna och nya funktionerna i den här versionen och hur den ser ut i praktiken. För en fullständig lista över ändringar i MariaDB MaxScale 2.4, kolla in dess ändringslogg.
Kommandohistorik för interaktivt läge
Detta är i grunden en liten förbättring med stor inverkan på MaxScales administration och övervakningsuppgiftseffektivitet. Det interaktiva läget för MaxCtrl har nu sin kommandohistorik. Kommandohistorik låter dig enkelt upprepa det utförda kommandot genom att trycka på upp- eller nedpilarna. Men Ctrl+R-funktionaliteten (hämta det senaste kommandot som matchar tecknen du anger) finns fortfarande inte där.
I de tidigare versionerna måste man använda standardskalläget för att se till att kommandona fångas av .bash_history-filen.
GTID-övervakning för galeramon
Detta är en bra förbättring för dem som kör på Galera Cluster med geografisk redundans via asynkron replikering, även känd som kluster-till-kluster-replikering, eller MariaDB Galera Cluster-replikering över MariaDB-replikering.
I MaxScale 2.3 och äldre ser det ut så här om du har aktiverat master-slave replikering mellan MariaDB Clusters:
För MaxScale 2.4 ser det nu ut så här (var uppmärksam på Galera1:s rad):
Det är nu lättare att se replikeringstillståndet för alla noder från MaxScale, utan behovet av att kontrollera enskilda noder upprepade gånger.
SmartRouter
Detta är en av de nya huvudfunktionerna i MaxScale 2.4, där MaxScale nu är smart nog att lära sig vilken backend MariaDB backend-server som är bäst för att bearbeta frågan. SmartRouter håller reda på prestandan, eller exekveringstiden, för frågor till klustren. Mätningar lagras med det kanoniska för en fråga som nyckel. Det kanoniska för en fråga är SQL med alla användardefinierade konstanter ersatta med frågetecken, till exempel:
UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? Detta är en mycket användbar funktion om du kör MariaDB på en geografisk replikering på flera platser eller en blandning av MariaDB-lagringsmotorer i en replikeringskedja, till exempel en dedikerad slav för att hantera transaktionsarbetsbelastningar (OLTP ) med InnoDB-lagringsmotor och en annan dedikerad slav för att hantera analysarbetsbelastningar (OLAP) med Columnstore-lagringsmotorn.
Antag att vi har två platser - Sydney och Singapore som illustreras i följande diagram:
Den primära webbplatsen ligger i Singapore och har en MariaDB-mästare och en slav , medan en annan skrivskyddad slav finns i Sydney. Applikationen ansluter till MaxScale-instansen i sitt respektive land med följande portinställningar:
- Läs-skrivdelning:3306
- Round robin:3307
- Smart router:3308
Vår SmarRouter-tjänst och lyssnardefinitioner är:
[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308Starta om MaxScale och börja skicka en skrivskyddad fråga till båda MaxScale-noderna i Singapore och Sydney. Om frågan bearbetas av round-robin-routern (port 3307), skulle vi se att frågan dirigeras baserat på round-robin-algoritmen:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Av ovanstående kan vi säga att Sydneys MaxScale vidarebefordrade frågan ovan till vår Singapores slav, vilket inte är det bästa ruttalternativet i sig.
Med SmartRouter som lyssnar på port 3308, skulle vi se att frågan dirigeras till närmaste slav i Sydney:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname |
+-----------+-----------------+
| 1000000 | mariadb_sydney1 |
+-----------+-----------------+Och om samma fråga körs på vår webbplats i Singapore, kommer den att dirigeras till MariaDB-slaven som finns i Singapore:
(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Det finns dock en hake. När SmartRouter ser en läsfråga vars kanoniska inte har setts tidigare, kommer den att skicka frågan till alla kluster. Det första svaret från ett kluster kommer att utse det klustret som det bästa för det kanoniska. När det första svaret tas emot avbryts de andra frågorna. Svaret skickas till klienten när alla kluster har svarat på frågan eller avbrytningen.
Detta innebär att för att hålla reda på den kanoniska frågan (normaliserad fråga) och mäta dess prestanda, kommer du förmodligen att se att den allra första frågan misslyckas i sin första körning, till exempel:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during queryFrån den allmänna loggen i MariaDB Sydney kan vi se att den första frågan (ID 74) kördes framgångsrikt (anslut, fråga och avsluta), trots felet "Förlorad anslutning" från MaxScale:
74 Connect [email protected] as anonymous on
74 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
74 QuitMedan den identiska efterföljande frågan bearbetades korrekt och returnerades med rätt svar:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname |
+-----------+------------------------+
| 1000000 | mariadb_sydney.cluster |
+-----------+------------------------+När man tittar igen på den allmänna loggen i MariaDB Sydney (ID 75), inträffade samma bearbetningshändelser precis som den första frågan:
75 Connect [email protected] as anonymous on
75 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
75 QuitFrån denna observation kan vi dra slutsatsen att MaxScale ibland måste misslyckas med den första frågan för att kunna mäta prestanda och bli smartare för de efterföljande identiska frågorna. Din applikation måste kunna hantera det här "första felet" ordentligt innan den återvänder till klienten eller gör om transaktionen igen.
UNIX-socket för server
Det finns flera sätt att ansluta till en körande MySQL- eller MariaDB-server. Du kan använda standardnätverks-TCP/IP med värd-IP-adress och port (fjärranslutning), namngivna pipes/delat minne på Windows eller Unix-socket-filer på Unix-baserade system. UNIX-socket-filen är en speciell typ av fil som underlättar kommunikation mellan olika processer, som i det här fallet är MySQL-klienten och servern. Socket-filen är en filbaserad kommunikation och du kan inte komma åt socket från en annan maskin. Det ger en snabbare anslutning än TCP/IP (ingen nätverksoverhead) och en säkrare anslutningsmetod eftersom den bara kan användas när du ansluter till en tjänst eller process på samma dator.
Förutsatt att MaxScale-servern också är installerad på själva MariaDB-servern, kan vi använda socket UNIX-socket-filen istället. Ta bort eller kommentera "adress"-raden under Serversektionen och lägg till socketparametern med platsen för socketfilen:
[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sockInnan vi tillämpar ovanstående ändringar måste vi skapa en MaxScale axscale-användare från localhost. På huvudservern:
MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';Efter en omstart kommer MaxScale att visa UNIX-sockets sökväg istället för den faktiska adressen, och serverlistan kommer att visas så här:
Som du kan se hämtas tillstånds- och GTID-informationen korrekt via en socket-anslutning. Observera att denna DB_2 fortfarande lyssnar på port 3306 för fjärranslutningarna. Det visar bara att MaxScale använder en socket för att ansluta till den här servern för övervakning.
Att använda socket är alltid bättre på grund av det faktum att det bara tillåter lokala anslutningar och det är säkrare. Du kan också stänga av din MariaDB-server från nätverket (t.ex. --skip-networking) och låta MaxScale hantera de "externa" anslutningarna och vidarebefordra dem till MariaDB-servern via UNIX-socket-fil.
Servertömning
I MaxScale 2.4 kan backend-servrarna dräneras, vilket innebär att befintliga anslutningar kan fortsätta att användas, men inga nya anslutningar kommer att skapas till servern. Med dräneringsfunktionen kan vi utföra en graciös underhållsaktivitet utan att påverka användarupplevelsen från applikationssidan. Observera att det kan ta längre tid att tömma en server, beroende på vilka frågor som körs som måste stängas på ett elegant sätt.
För att tömma en server, använd följande kommando:
Efterverkan kan vara ett av följande tillstånd:
- Tömmar - Servern dräneras.
- Tömd – Servern har tömts. Servern höll på att tömmas och nu har antalet anslutningar till servern sjunkit till 0.
- Underhåll - Servern är under underhåll.
Efter att en server har dränerats är tillståndet för MariaDB-servern ur MaxScales synvinkel "Underhåll":
När en server är i underhållsläge skapas inga anslutningar till den och befintliga anslutningar kommer att stängas.
Slutsats
MaxScale 2.4 ger många förbättringar och förändringar jämfört med den tidigare versionen och det är den bästa databasproxyn för att hantera MariaDB-servrar och alla dess komponenter.