Hvad er MariaDB TX? Sådan administreres den nye MariaDB MySQL Fork!

Du har måske hørt om MariaDB TX, og du har måske undret dig over, hvad det er?

Er der forskel på det og MariaDB Server 10.3?

I dette blogindlæg vil vi gerne give dig et overblik over MariaDB TX, og hvad det handler om.

Kort sagt:MariaDB TX er et abonnement, hvor MariaDB kombinerer flere tilbud og bygger en fuldt udstyret transaktionsdatabase.

Databasen brugt i MariaDB TX er MariaDB Server 10.3, som også inkluderer Galera Cluster til synkron multi-master replikering. Til proxy-laget bruger MariaDB TX MaxScale.

Lad os fokusere lidt på disse to hovedtilbud og gennemgå deres funktioner.

MariaDB Server 10.3

Det udviklede sig til en funktionsfuld gaffel, som implementerer nye funktionaliteter oven i, hvad Oracle implementerer i upstream. MariaDB 10.3 kommer med en liste over virksomhedsfokuserede funktioner. MariaDB Server 10.3 er ikke længere en drop-in-erstatning for MySQL.

Oracle-kompatibilitet

MariaDB 10.3 kommer med SQL_MODE=ORACLE, som forbedrer kompatibiliteten for SQL-syntaks brugt i MariaDB 10.3 med Oracle PL/SQL. Følgende kompatibilitetsfunktioner er inkluderet i MariaDB TX:

• Lagrede procedureparametre
• Ikke-ANSI Stored Procedure Construct
• Markørsyntaks
• Sløjfesyntaks
• Variabelerklæring
• Datatypearv (%TYPE, %ROWTYPE)
• PL/SQL-undtagelser
• Synonymer for grundlæggende SQL-typer (VARCHAR2, NUMBER, …)

Dette giver mulighed for lettere migrering af dine applikationer fra Oracle-databaser til MariaDB TX.

Op til 80 % af Oracle PL/SQL-koden kan nu udføres på MariaDB uden behov for at indføre ændringer; dette påvirker den overordnede indlæringskurve alvorligt og reducerer den tid, der er nødvendig for at omskrive den gamle kode, så den kører på MariaDB TX.

Hvad der også er vigtigt at huske på, MariaDB TX kommer med en supportpakke, og du vil få adgang til konsulenter, der vil være i stand til at dele migration best practices med dig eller endda direkte hjælpe dig i planlægningsprocessen for at gøre overgangen endnu mindre besværlig.

Forbedringer i SQL

MariaDB TX bringer os også forbedringer i SQL-syntaks, herunder nye funktioner, der burde være meget nyttige for udviklere som vinduesfunktioner eller almindelige tabeludtryk. En tidsmæssig undersætning kan også være meget nyttig, da de giver mulighed for at få adgang til flere versioner af en given række baseret på et specifikt tidspunkt.

Alle funktionerne er anført nedenfor:

• Tidligere undersætninger (f.eks. AS OF)
• Brugerdefinerede aggregerede funktioner
• Bestilte aggregerede funktioner
• SKÆR/UNDTAGET
• Tabelværdikonstruktører
• DDL/SELECT-lås timeout
• Almindelige tabeludtryk
• Vinduefunktioner
• JSON-funktioner

Eksterne lagermotorer

Standardmotoren for MariaDB er InnoDB, transaktionsbaseret, all-round storage-motor.

Det er velegnet til de fleste arbejdsbelastninger, og det fungerer godt til OLTP (Online Transaction Processing) arbejdsbelastning. Det er dog ikke den eneste lagermotor, der er tilgængelig i MariaDB TX. Du får adgang til Spider-motoren, som kan bruges til at partitionere dine data på tværs af flere MariaDB-forekomster, mens du bevarer understøttelse af XA-transaktioner.

En anden lagringsmotor, du kan bruge, er MyRocks, en motor optimeret til reduktion af lagring og skriveforstærkning. Kamptestet i Facebook, LSN-baseret, den egner sig perfekt til at gemme store mængder data på SSD-lager, reducere omkostningerne ved at implementere stærk komprimering og ved at reducere antallet af skrivninger, der kræves for en given arbejdsbyrde (og dermed minimere SSD-slidningen) ).

Galera-klynge

MariaDB TX giver dig nem adgang til Galera Cluster, en praktisk talt synkron multi-master replikering. Galera Cluster kan bruges til at designe højst tilgængelige, WAN-spændende klynger.

Galera Cluster er bygget oven på den quorum-aware protokol, som sikrer, at netværksopdelingen ikke vil være et problem, og at den splittede hjerne ikke længere bør være et problem. Galera Cluster giver mulighed for automatisk klargøring af nye eller mislykkede noder, hvilket reducerer administrationens fodaftryk.

Driftsfunktioner

MariaDB TX giver også nogle funktioner relateret til de operationelle opgaver. Øjeblikkelig ADD COLUMN hjælper med at reducere virkningen af ​​en af ​​de mest almindelige skemaændringer. Usynlige kolonner hjælper med at opretholde kompatibilitet mellem gammel og ny kode. Indekser på virtuelle kolonner vil øge ydeevnen.

Mariabackup

MariaDB TX implementerer data-at-rest-kryptering, som inkluderer kryptering af binære logfiler. For at sikre, at MariaDB TX-brugere kan drage fordel af låsefri sikkerhedskopier, var Mariabackup blevet oprettet. Det er en forbedret gaffel af Xtrabackup, som ikke fungerede korrekt med MariaDB TX-krypteringsfunktioner. Nu kan du nyde dine varme, fysiske sikkerhedskopier med Mariabackup, mens du har dine data sikkert krypteret.

MariaDB MaxScale

Ud over MariaDB 10.3 kommer MariaDB TX med MaxScale 2.3, en SQL-bevidst proxy, som kan bruges til at bygge højt tilgængelige miljøer. Den kommer med adskillige funktioner, og vi vil gerne gennemgå de vigtigste af dem her.

Automatisk failover

MaxScale kan bruges til at spore sundheden for master MariaDB-knuden og, hvis den fejler, udføre en hurtig, automatisk failover. Automatiseret failover er afgørende for at opbygge en meget tilgængelig løsning, der kan komme sig hurtigt fra fejlen.

Læse-skriveopdeling

Læse-skrive-opdeling er kritisk funktion for at tillade læseskalering. Det er nok for applikationen at oprette forbindelse til MaxScale, og den vil detektere topologien, bestemme hvilken MariaDB der fungerer som master, og hvilke der fungerer som slaver. Det vil så dirigere trafikken i overensstemmelse hermed. SELECT forespørgsler vil blive sendt til slaverne, skriver vil blive sendt til masteren. Alt sker automatisk, topologi overvåges hele tiden, og skulle der ske en failover, vil trafikken blive omdirigeret baseret på ændringen.

Transparent forespørgselsrouting

MaxScale, som er indgangspunktet for trafikken i MariaDB TX, kan bruges til at lave en læse-skrive-split. Nogle gange er dette stadig ikke nok, og det ville være fantastisk at have en måde at kontrollere, hvor en given forespørgsel skal sendes. Dette er muligt i MaxScale - du kan matche forespørgslerne ved hjælp af regulære udtryk og derefter beslutte, om de skal sendes til masteren eller til slaver. Dette kan hjælpe i nogle særlige tilfælde, hvor SELECT-forespørgsel skal udføres på masteren på grund af læs-efter-skrive-problemer, eller bare fordi den skal have den mest opdaterede visning af datasættet.

Caching af forespørgselsresultat

For at forbedre ydeevnen er forespørgselscache et must. Forespørgselscache, der er tilgængelig i MariaDB, vil bare ikke fungere i et meget samtidig miljø, da det gennemtvinger serialisering af forespørgslerne, hvilket alvorligt reducerer ydeevnen selv for skrivebeskyttede arbejdsbelastninger. Det er ikke altid muligt at bruge ekstern løsning til cache:du vil trods alt ende med endnu en database til at vedligeholde, sikre og holde sund. Det kan være bedre at bruge MaxScale som en cache, forudsat at du allerede bruger den til anden funktionalitet.

Forespørgselsblokering

Nogle gange lider databaser af en ineffektiv forespørgsel, som skaber høj belastning på systemet. Det kunne være, at omskrivning af den forespørgsel ville tage alt for lang tid (nogen ville skulle omskrive den, teste ændringen på iscenesættelse og så endelig implementere til produktion), en tid du ikke har. MaxScale kan her hjælpe dig med funktioner som forespørgselsblokering, som grundlæggende giver dig mulighed for at stoppe en given forespørgsel i at ramme databasen. Denne funktion kan også bruges til at bygge en SQL-firewall - slip alle de forespørgsler, der matcher mønstre, der peger mod SQL-injektioner eller andre potentielt farlige og ondsindede aktiviteter.

Som du kan se, kommer MariaDB TX med en liste over funktioner og software, der er designet til at arbejde sammen og bygge yderst tilgængelig, skalerbar database til transaktionsdatabehandling.

Enterprise Monitoring &Management for MariaDB TX

ClusterControl understøtter MariaDB TX fuldt ud. Du kan nemt implementere både MariaDB Server 10.3 og MaxScale 2.3. ClusterControl understøtter MariaDB-replikeringsopsætninger såvel som MariaDB Galera Cluster.

Så længe du har SSH-forbindelse fra din ClusterControl-instans til de noder, du vil implementere MariaDB TX på, kan du gøre det med blot et par klik.

Først skal du definere, hvordan ClusterControl vil nå MariaDB TX noderne.

Vælg derefter MariaDB som leverandør og gå efter en af ​​de understøttede versioner. Send MariaDB root-adgangskoden.

Til sidst beslutter du dig for topologien. Du kan implementere MariaDB TX i en master - master, aktiv - standby-opsætning med ekstra slaver. Replikering vil bruge MariaDB GTID.

For MariaDB Galera Cluster er første trin nøjagtig det samme, så skal du bare vælge MariaDB som leverandør, beslutte dig for versionen og definere noder i MariaDB Galera Cluster:

For eksempel er tilføjelse af MaxScale load balancers kun et par klik væk:

Når den er installeret, kan du administrere din MaxScale ved hjælp af ClusterControl:

Du kan også skalere din Galera-klynge ved at tilføje nye Galera-noder eller asynkrone replikeringsslaver. Du kan tilføje slaver eller forsinkede slaver til dine replikeringsopsætninger eller udføre topologiændringer ved at promovere en slave til master og genslave resten af ​​opsætningen. ClusterControl vil overvåge klyngen og forsøge at gendanne mislykkede noder eller klynger, hvis der skulle ske en hændelse. Til sikkerhedskopier kan ClusterControl hjælpe dig med at definere en sikkerhedskopieringsplan ved hjælp af både mysqldump og Mariabackup, så du nemt kan drage fordel af krypteringsfunktionerne i MariaDB TX.

Til overvågnings- og trenddelen kan ClusterControl bruges enten i en agentfri tilstand:

Eller det kan bruges sammen med Prometheus og agenter for at give endnu bedre indsigt i, hvad der sker i MariaDB TX-klyngen.

Vi håber, at dette indledende blogindlæg hjalp dig med at forstå, hvad MariaDB TX er, og hvordan ClusterControl kan hjælpe dig med at administrere det.