MaxScale 2.4 is uitgebracht op 21 december 2019 en ClusterControl 1.7.6 ondersteunt de bewaking en het beheer tot aan deze versie. Voor implementatie ondersteunt ClusterControl echter alleen versie 2.3. Je moet de instantie handmatig upgraden en gelukkig zijn de upgradestappen heel eenvoudig. Download gewoon de nieuwste versie van de MariaDB MaxScale-downloadpagina en voer de opdracht voor pakketinstallatie uit.
De volgende opdrachten laten zien hoe u kunt upgraden van een bestaande MaxScale 2.3 naar MaxScale 2.4 op een 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.10In deze blogpost gaan we enkele van de opmerkelijke verbeteringen en nieuwe functies van deze versie belichten en hoe deze eruitziet in actie. Bekijk de changelog voor een volledige lijst met wijzigingen in MariaDB MaxScale 2.4.
Opdrachtgeschiedenis interactieve modus
Dit is in feite een kleine verbetering met een grote impact op het MaxScale-beheer en de efficiëntie van monitoringtaken. De interactieve modus voor MaxCtrl heeft nu zijn opdrachtgeschiedenis. Met de opdrachtgeschiedenis kunt u de uitgevoerde opdracht eenvoudig herhalen door op de pijl-omhoog of pijl-omlaag te drukken. De Ctrl+R-functionaliteit (denk aan de laatste opdracht die overeenkomt met de tekens die u opgeeft) is er echter nog steeds niet.
In de vorige versies moest men de standaard shell-modus gebruiken om ervoor te zorgen dat de commando's worden vastgelegd door het .bash_history-bestand.
GTID-bewaking voor galeramon
Dit is een goede verbetering voor degenen die op Galera Cluster werken met geografische redundantie via asynchrone replicatie, ook bekend als cluster-naar-cluster-replicatie, of MariaDB Galera-clusterreplicatie via MariaDB-replicatie.
In MaxScale 2.3 en ouder ziet het er zo uit als u master-slave-replicatie tussen MariaDB-clusters hebt ingeschakeld:
Voor MaxScale 2.4 ziet het er nu zo uit (let op Galera1's rij):
Het is nu gemakkelijker om de replicatiestatus voor alle knooppunten van MaxScale te zien, zonder de noodzaak om afzonderlijke knooppunten herhaaldelijk te controleren.
SmartRouter
Dit is een van de nieuwe belangrijke functies in MaxScale 2.4, waar MaxScale nu slim genoeg is om te leren welke backend MariaDB-backendserver het beste is om de query te verwerken. SmartRouter houdt de prestaties, of de uitvoeringstijd, van query's naar de clusters bij. Metingen worden opgeslagen met de canoniek van een zoekopdracht als sleutel. Het canonieke van een query is de SQL waarbij alle door de gebruiker gedefinieerde constanten zijn vervangen door vraagtekens, bijvoorbeeld:
UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? Dit is een zeer handige functie als u MariaDB uitvoert op een geografische replicatie met meerdere locaties of een mix van MariaDB-opslagengines in één replicatieketen, bijvoorbeeld een speciale slave om transactieworkloads af te handelen (OLTP ) met InnoDB-opslagengine en een andere toegewijde slave om analyseworkloads (OLAP) af te handelen met Columnstore-opslagengine.
Stel dat we twee locaties hebben - Sydney en Singapore, zoals geïllustreerd in het volgende diagram:
De primaire site bevindt zich in Singapore en heeft een MariaDB-master en een slave , terwijl een andere alleen-lezen slaaf zich in Sydney bevindt. De applicatie maakt verbinding met de MaxScale-instantie in het betreffende land met de volgende poortinstellingen:
- Lezen-schrijven split:3306
- Round robin:3307
- Slimme router:3308
Onze SmarRouter-service en luisteraardefinities zijn:
[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 = 3308Start MaxScale opnieuw en stuur een alleen-lezen-query naar beide MaxScale-knooppunten in Singapore en Sydney. Als de query wordt verwerkt door de round-robin-router (poort 3307), zien we dat de query wordt gerouteerd op basis van het round-robin-algoritme:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Uit het bovenstaande kunnen we opmaken dat Sydney's MaxScale de bovenstaande vraag heeft doorgestuurd naar de slaaf van Singapore, wat op zich niet de beste routeringsoptie is.
Als SmartRouter luistert op poort 3308, zien we dat de vraag wordt doorgestuurd naar de dichtstbijzijnde slave in Sydney:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname |
+-----------+-----------------+
| 1000000 | mariadb_sydney1 |
+-----------+-----------------+En als dezelfde zoekopdracht wordt uitgevoerd op onze site in Singapore, wordt deze doorgestuurd naar de MariaDB-slave in Singapore:
(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Er is echter een addertje onder het gras. Wanneer SmartRouter een leesquery ziet waarvan de canonieke code nog niet eerder is gezien, wordt de query naar alle clusters verzonden. Het eerste antwoord van een cluster zal dat cluster aanwijzen als de beste voor die canonieke. Wanneer het eerste antwoord wordt ontvangen, worden ook de andere vragen geannuleerd. Het antwoord wordt naar de klant gestuurd zodra alle clusters op de vraag of de annulatie hebben gereageerd.
Dit betekent dat u, om de canonieke query (genormaliseerde query) bij te houden en de prestaties ervan te meten, waarschijnlijk zult zien dat de allereerste query mislukt bij de eerste uitvoering, bijvoorbeeld:
(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 queryUit het algemene logboek in MariaDB Sydney kunnen we afleiden dat de eerste query (ID 74) met succes is uitgevoerd (verbinden, opvragen en afsluiten), ondanks de foutmelding "Verbinding verbroken" van MaxScale:
P> 74 Connect [email protected] as anonymous on
74 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
74 QuitTerwijl de identieke daaropvolgende zoekopdracht correct werd verwerkt en met het juiste antwoord werd geretourneerd:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname |
+-----------+------------------------+
| 1000000 | mariadb_sydney.cluster |
+-----------+------------------------+Nog eens kijkend naar het algemene logboek in MariaDB Sydney (ID 75), vonden dezelfde verwerkingsgebeurtenissen plaats, net als de eerste vraag:
75 Connect [email protected] as anonymous on
75 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
75 QuitUit deze observatie kunnen we concluderen dat MaxScale af en toe de eerste query moet mislukken om de prestaties te meten en slimmer te worden voor de daaropvolgende identieke query's. Uw applicatie moet deze "eerste fout" goed kunnen afhandelen voordat u terugkeert naar de klant of de transactie opnieuw probeert.
UNIX-socket voor server
Er zijn meerdere manieren om verbinding te maken met een draaiende MySQL- of MariaDB-server. U kunt het standaard netwerk-TCP/IP gebruiken met host-IP-adres en poort (externe verbinding), named pipes/gedeeld geheugen op Windows of Unix-socketbestanden op Unix-gebaseerde systemen. Het UNIX-socketbestand is een speciaal soort bestand dat de communicatie tussen verschillende processen vergemakkelijkt, in dit geval de MySQL-client en de server. Het socketbestand is een op bestanden gebaseerde communicatie en u hebt geen toegang tot de socket vanaf een andere machine. Het biedt een snellere verbinding dan TCP/IP (geen netwerkoverhead) en een veiligere verbindingsbenadering omdat het alleen kan worden gebruikt wanneer verbinding wordt gemaakt met een service of proces op dezelfde computer.
Stel dat de MaxScale-server ook op de MariaDB-server zelf is geïnstalleerd, dan kunnen we in plaats daarvan het socket-UNIX-socketbestand gebruiken. Verwijder onder het gedeelte Server de regel "adres" of becommentarieer deze en voeg de socketparameter toe met de locatie van het socketbestand:
[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sockVoordat we de bovenstaande wijzigingen toepassen, moeten we een MaxScale axscale-gebruiker maken van localhost. Op de hoofdserver:
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';Na een herstart zal MaxScale het UNIX-socketpad tonen in plaats van het werkelijke adres, en de serverlijst wordt als volgt weergegeven:
Zoals u kunt zien, worden de status- en GTID-informatie correct opgehaald via een socketverbinding. Merk op dat deze DB_2 nog steeds luistert naar poort 3306 voor de externe verbindingen. Het laat alleen zien dat MaxScale een socket gebruikt om verbinding te maken met deze server voor monitoring.
Het gebruik van een socket is altijd beter omdat het alleen lokale verbindingen toestaat en het is veiliger. U kunt ook uw MariaDB-server van het netwerk afsluiten (bijv. --skip-networking) en MaxScale de "externe" verbindingen laten afhandelen en deze via UNIX-socketbestand doorsturen naar de MariaDB-server.
Server loopt leeg
In MaxScale 2.4 kunnen de backend-servers worden leeggemaakt, wat betekent dat bestaande verbindingen kunnen blijven worden gebruikt, maar dat er geen nieuwe verbindingen met de server worden gemaakt. Met de drain-functie kunnen we een gracieuze onderhoudsactiviteit uitvoeren zonder de gebruikerservaring van de applicatiekant te beïnvloeden. Houd er rekening mee dat het leegmaken van een server langer kan duren, afhankelijk van de lopende query's die netjes moeten worden afgesloten.
Gebruik het volgende commando om een server leeg te maken:
Het na-effect kan een van de volgende toestanden zijn:
- Drainage - De server wordt leeggemaakt.
- Drained - De server is leeggemaakt. De server werd leeggemaakt en nu is het aantal verbindingen met de server gedaald tot 0.
- Onderhoud - De server is in onderhoud.
Nadat een server is leeggemaakt, is de status van de MariaDB-server vanuit het oogpunt van MaxScale "Onderhoud":
Wanneer een server zich in de onderhoudsmodus bevindt, worden er geen verbindingen mee gemaakt en worden bestaande verbindingen gesloten.
Conclusie
MaxScale 2.4 brengt veel verbeteringen en veranderingen ten opzichte van de vorige versie en het is de beste databaseproxy om MariaDB-servers en al zijn componenten te verwerken.