MaxScale 2.4 blev udgivet den 21. december 2019, og ClusterControl 1.7.6 understøtter overvågning og styring op til denne version. Til implementering understøtter ClusterControl dog kun op til version 2.3. Man skal manuelt opgradere instansen manuelt, og heldigvis er opgraderingstrinene meget ligetil. Du skal bare downloade den seneste version fra MariaDB MaxScale-downloadsiden og udføre pakkeinstallationskommandoen.
Følgende kommandoer viser, hvordan du opgraderer fra en eksisterende MaxScale 2.3 til MaxScale 2.4 på en CentOS 7-boks:
$ 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 dette blogindlæg vil vi fremhæve nogle af de bemærkelsesværdige forbedringer og nye funktioner i denne version, og hvordan den ser ud i aktion. For en komplet liste over ændringer i MariaDB MaxScale 2.4, tjek dens changelog.
Kommandohistorik for interaktiv tilstand
Dette er dybest set en lille forbedring med stor indflydelse på MaxScale-administration og overvågningsopgaveeffektivitet. Den interaktive tilstand for MaxCtrl har nu sin kommandohistorik. Kommandohistorik giver dig nemt mulighed for at gentage den udførte kommando ved at trykke på pil op eller pil ned. Men Ctrl+R-funktionaliteten (hent den sidste kommando, der matcher de tegn, du angiver) er der stadig ikke.
I de tidligere versioner skal man bruge standard shell-tilstand for at sikre, at kommandoerne er fanget af .bash_history-filen.
GTID-overvågning for galeramon
Dette er en god forbedring for dem, der kører på Galera Cluster med geografisk redundans via asynkron replikering, også kendt som klynge-til-klynge-replikering, eller MariaDB Galera Cluster-replikering over MariaDB-replikering.
I MaxScale 2.3 og ældre ser det sådan ud, hvis du har aktiveret master-slave-replikering mellem MariaDB-klynger:
For MaxScale 2.4 ser det nu sådan ud (vær opmærksom på Galera1's række):
Det er nu nemmere at se replikeringstilstanden for alle noder fra MaxScale uden behovet for at kontrollere individuelle noder gentagne gange.
SmartRouter
Dette er en af de nye store funktioner i MaxScale 2.4, hvor MaxScale nu er smart nok til at lære, hvilken backend MariaDB-backend-server der er den bedste til at behandle forespørgslen. SmartRouter holder styr på ydeevnen eller udførelsestiden for forespørgsler til klyngerne. Målinger gemmes med det kanoniske af en forespørgsel som nøglen. Det kanoniske af en forespørgsel er SQL'en med alle brugerdefinerede konstanter erstattet med spørgsmålstegn, for eksempel:
UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? Dette er en meget nyttig funktion, hvis du kører MariaDB på en multi-site geografisk replikering eller en blanding af MariaDB storage engines i én replikeringskæde, for eksempel en dedikeret slave til at håndtere transaktionsarbejdsbelastninger (OLTP ) med InnoDB-lagringsmotor og en anden dedikeret slave til at håndtere analytiske arbejdsbelastninger (OLAP) med Columnstore-lagringsmotor.
Det antages, at vi har to steder - Sydney og Singapore som illustreret i følgende diagram:
Det primære websted er placeret i Singapore og har en MariaDB-master og en slave , mens en anden skrivebeskyttet slave befinder sig i Sydney. Applikationen opretter forbindelse til MaxScale-instansen i dets respektive land med følgende portindstillinger:
- Læse-skriveopdeling:3306
- Round robin:3307
- Smart router:3308
Vores SmarRouter-tjeneste og lytterdefinitioner er:
[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 = 3308Genstart MaxScale, og begynd at sende en skrivebeskyttet forespørgsel til begge MaxScale-knuder i Singapore og Sydney. Hvis forespørgslen behandles af round-robin-routeren (port 3307), vil vi se, at forespørgslen bliver rutet baseret 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 |
+-----------+--------------------+Fra ovenstående kan vi se, at Sydneys MaxScale videresendte ovenstående forespørgsel til vores Singapores slave, hvilket ikke er den bedste rutemulighed i sig selv.
Når SmartRouter lytter på port 3308, vil vi se, at forespørgslen bliver dirigeret til den nærmeste slave i Sydney:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname |
+-----------+-----------------+
| 1000000 | mariadb_sydney1 |
+-----------+-----------------+Og hvis den samme forespørgsel udføres på vores Singapore-websted, vil den blive dirigeret til MariaDB-slaven i Singapore:
(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Der er dog en hage. Når SmartRouter ser en læseforespørgsel, hvis kanoniske ikke er set før, sender den forespørgslen til alle klynger. Det første svar fra en klynge vil udpege den klynge som den bedste for den kanoniske. Når det første svar modtages, annulleres de andre forespørgsler. Svaret sendes til klienten, når alle klynger har svaret på forespørgslen eller annulleringen.
Det betyder, at for at holde styr på den kanoniske forespørgsel (normaliseret forespørgsel) og måle dens ydeevne, vil du sandsynligvis se, at den allerførste forespørgsel mislykkes i dens første udførelse, for eksempel:
(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 queryFra den generelle log i MariaDB Sydney kan vi se, at den første forespørgsel (ID 74) blev udført med succes (tilslut, forespørg og afslut), på trods af fejlen "Mistet forbindelse" fra MaxScale:
74 Connect [email protected] as anonymous on
74 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
74 QuitMens den identiske efterfølgende forespørgsel blev korrekt behandlet og returneret med det korrekte 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 vi igen ser på den generelle log i MariaDB Sydney (ID 75), skete de samme behandlingshændelser ligesom den første forespørgsel:
75 Connect [email protected] as anonymous on
75 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
75 QuitFra denne observation kan vi konkludere, at MaxScale af og til skal fejle den første forespørgsel for at måle ydeevne og blive klogere til de efterfølgende identiske forespørgsler. Din applikation skal være i stand til at håndtere denne "første fejl" korrekt, før den vender tilbage til klienten eller prøv transaktionen igen.
UNIX-socket til server
Der er flere måder at oprette forbindelse til en kørende MySQL- eller MariaDB-server. Du kan bruge standard netværks-TCP/IP med værts-IP-adresse og port (fjernforbindelse), navngivne rør/delt hukommelse på Windows eller Unix-socket-filer på Unix-baserede systemer. UNIX-socket-filen er en speciel type fil, der letter kommunikationen mellem forskellige processer, som i dette tilfælde er MySQL-klienten og serveren. Socket-filen er en fil-baseret kommunikation, og du kan ikke få adgang til socket fra en anden maskine. Det giver en hurtigere forbindelse end TCP/IP (ingen netværksoverhead) og en mere sikker forbindelsestilgang, fordi den kun kan bruges, når der oprettes forbindelse til en tjeneste eller proces på den samme computer.
Hvis MaxScale-serveren også er installeret på selve MariaDB-serveren, kan vi bruge socket UNIX-socket-filen i stedet. Under Server-sektionen skal du fjerne eller kommentere "adresse"-linjen og tilføje socket-parameteren med placeringen af socket-filen:
[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sockFør vi anvender ovenstående ændringer, skal vi oprette en MaxScale axscale-bruger fra localhost. På masterserveren:
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 genstart vil MaxScale vise UNIX-socketstien i stedet for den faktiske adresse, og serverlisten vil blive vist sådan:
Som du kan se, hentes tilstands- og GTID-oplysningerne korrekt gennem en socket-forbindelse. Bemærk, at denne DB_2 stadig lytter til port 3306 for fjernforbindelserne. Det viser bare, at MaxScale bruger en socket til at oprette forbindelse til denne server til overvågning.
Brug af socket er altid bedre på grund af det faktum, at det kun tillader lokale forbindelser, og det er mere sikkert. Du kan også lukke din MariaDB-server fra netværket (f.eks. --skip-networking) og lade MaxScale håndtere de "eksterne" forbindelser og videresende dem til MariaDB-serveren via UNIX-socket-fil.
Dræning af server
I MaxScale 2.4 kan backend-serverne drænes, hvilket betyder, at eksisterende forbindelser kan fortsætte med at blive brugt, men der vil ikke blive oprettet nye forbindelser til serveren. Med afløbsfunktionen kan vi udføre en yndefuld vedligeholdelsesaktivitet uden at påvirke brugeroplevelsen fra applikationssiden. Bemærk, at det kan tage længere tid at tømme en server, afhængigt af de kørende forespørgsler, der skal lukkes elegant.
For at dræne en server skal du bruge følgende kommando:
Eftervirkningen kan være en af følgende tilstande:
- Dræner - Serveren tømmes.
- Drænet - Serveren er blevet drænet. Serveren blev drænet, og nu er antallet af forbindelser til serveren faldet til 0.
- Vedligeholdelse - Serveren er under vedligeholdelse.
Efter at en server er blevet drænet, er MariaDB-serverens tilstand fra MaxScale-synspunkt "Vedligeholdelse":
Når en server er i vedligeholdelsestilstand, vil der ikke blive oprettet forbindelser til den, og eksisterende forbindelser vil blive lukket.
Konklusion
MaxScale 2.4 bringer en masse forbedringer og ændringer i forhold til den tidligere version, og det er den bedste databaseproxy til at håndtere MariaDB-servere og alle dens komponenter.