Vad är MariaDB TX? Hur man hanterar den nya MariaDB MySQL-gaffeln!

Du kanske har hört talas om MariaDB TX och du kanske har undrat vad det är?

Finns det någon skillnad mellan det och MariaDB Server 10.3?

I det här blogginlägget vill vi ge dig en översikt över MariaDB TX och vad det handlar om.

Kort sagt:MariaDB TX är ett abonnemang där MariaDB kombinerar flera erbjudanden och bygger en fullfjädrad transaktionsdatabas.

Databasen som används i MariaDB TX är MariaDB Server 10.3, som även inkluderar Galera Cluster för synkron multi-master replikering. För proxylagret använder MariaDB TX MaxScale.

Låt oss fokusera lite på dessa två huvuderbjudanden och gå igenom deras funktioner.

MariaDB Server 10.3

Det utvecklades till en funktionskomplett gaffel, som implementerar nya funktioner utöver vad Oracle implementerar i uppströms. MariaDB 10.3 kommer med en lista över företagsfokuserade funktioner. MariaDB Server 10.3 är inte längre en drop-in ersättning för MySQL.

Oracle-kompatibilitet

MariaDB 10.3 kommer med SQL_MODE=ORACLE, vilket förbättrar kompatibiliteten för SQL-syntax som används i MariaDB 10.3 med Oracle PL/SQL. Följande kompatibilitetsfunktioner ingår i MariaDB TX:

• Lagrade procedurparametrar
• Icke-ANSI lagrad procedurkonstruktion
• Markörsyntax
• Slingasyntax
• Variabeldeklaration
• Arv av datatyp (%TYPE, %ROWTYPE)
• Undantag i PL/SQL-stil
• Synonymer för grundläggande SQL-typer (VARCHAR2, NUMBER, …)

Detta möjliggör enklare migrering av dina applikationer från Oracle-databaser till MariaDB TX.

Upp till 80 % av Oracle PL/SQL-koden kan nu exekveras på MariaDB utan att behöva införa ändringar; detta påverkar allvarligt den övergripande inlärningskurvan och minskar tiden som behövs för att skriva om den äldre koden för att köras på MariaDB TX.

Vad som också är viktigt att ha i åtanke, MariaDB TX kommer med ett supportpaket och du kommer att få tillgång till konsulter som kommer att kunna dela migrationens bästa praxis med dig eller till och med direkt hjälpa dig i planeringen för att göra övergången ännu mindre besvärlig.

Förbättringar i SQL

MariaDB TX ger oss också förbättringar i SQL-syntax, inklusive nya funktioner som borde vara mycket användbara för utvecklare som fönsterfunktioner eller vanliga tabelluttryck. En temporal underklausul kan också vara mycket användbar eftersom de tillåter åtkomst till flera versioner av en given rad baserat på en specifik tidpunkt.

Alla funktioner listas nedan:

• Temporala undersatser (t.ex. FRÅN)
• Användardefinierade aggregerade funktioner
• Aggregerade funktioner i ordningsuppsättning
• SKÄRSA/UTOM
• Konstruktörer för tabellvärden
• DDL/SELECT-lås timeout
• Vanliga tabelluttryck
• Fönsterfunktioner
• JSON-funktioner

Externa lagringsmotorer

Standardmotorn för MariaDB är InnoDB, transaktionell, allsidig lagringsmotor.

Det är lämpligt för de flesta arbetsbelastningar och det fungerar utmärkt för OLTP (Online Transaction Processing) arbetsbelastning. Det är dock inte den enda lagringsmotorn som är tillgänglig i MariaDB TX. Du får tillgång till Spider-motorn, som kan användas för att partitionera dina data över flera MariaDB-instanser samtidigt som stödet för XA-transaktioner bibehålls.

En annan lagringsmotor du kan använda är MyRocks, en motor optimerad för reduktion av lagring och skrivförstärkning. Battle-testad i Facebook, LSN-baserad, lämpar sig perfekt för att lagra stora mängder data på SSD-lagring, minska kostnaderna genom att implementera stark komprimering och genom att minska antalet skrivningar som krävs för en given arbetsbelastning (och därmed minimera SSD-nötningen ).

Galera-kluster

MariaDB TX ger dig enkel åtkomst till Galera Cluster, en praktiskt taget synkron multi-master replikering. Galera Cluster kan användas för att designa högt tillgängliga, WAN-övergripande kluster.

Galera Cluster är byggt ovanpå det kvorummedvetna protokollet, vilket säkerställer att nätverkspartitioneringen inte kommer att vara ett problem och att den delade hjärnan inte längre ska vara ett problem. Galera Cluster ger möjlighet att automatiskt tillhandahålla nya eller misslyckade noder, vilket minskar hanteringens fotavtryck.

Driftsfunktioner

MariaDB TX tillhandahåller också några funktioner relaterade till de operativa uppgifterna. Omedelbar ADD COLUMN hjälper till att minska effekten av en av de vanligaste schemaändringarna. Osynliga kolumner hjälper till att upprätthålla kompatibiliteten mellan gammal och ny kod. Index på virtuella kolumner kommer att öka prestandan.

Mariabackup

MariaDB TX implementerar data-at-rest-kryptering som inkluderar kryptering av binära loggar. För att säkerställa att MariaDB TX-användare kan dra nytta av låsfria säkerhetskopior, hade Mariabackup skapats. Det är en förbättrad gaffel av Xtrabackup, som inte fungerade korrekt med MariaDB TX-krypteringsfunktioner. Nu kan du njuta av dina heta, fysiska säkerhetskopior med Mariabackup samtidigt som du har dina data säkert krypterade.

MariaDB MaxScale

Förutom MariaDB 10.3 kommer MariaDB TX med MaxScale 2.3, en SQL-medveten proxy som kan användas för att bygga högt tillgängliga miljöer. Den kommer med många funktioner och vi skulle vilja gå igenom de viktigaste av dem här.

Automatisk failover

MaxScale kan användas för att spåra tillståndet för master MariaDB-noden och, om den misslyckas, utföra en snabb, automatisk failover. Automatiserad failover är avgörande för att bygga upp en mycket tillgänglig lösning som kan återhämta sig snabbt från felet.

Läs-skrivdelning

Läs- och skrivdelning är en viktig funktion för att tillåta lässkalning. Det räcker för applikationen att ansluta till MaxScale och den kommer att upptäcka topologin, avgöra vilken MariaDB som fungerar som master och vilken som fungerar som slavar. Den kommer då att dirigera trafiken i enlighet med detta. SELECT-frågor kommer att skickas till slavarna, skrivningar kommer att skickas till mastern. Allt sker automatiskt, topologi övervakas hela tiden och skulle en failover inträffa kommer trafiken att omdirigeras baserat på ändringen.

Transparent frågedirigering

MaxScale, som är ingångspunkten för trafiken till MariaDB TX, kan användas för att göra en läs-skrivdelning. Ibland är detta fortfarande inte tillräckligt och det skulle vara bra att ha ett sätt att kontrollera vart en given fråga ska skickas. Detta är möjligt i MaxScale - du kan matcha frågorna med reguljära uttryck och sedan bestämma om de ska skickas till mastern eller till slavar. Detta kan hjälpa i vissa särskilda fall där SELECT-frågan måste köras på mastern på grund av läs-efter-skriv-problem eller bara för att den måste ha den mest uppdaterade vyn av datasetet.

Cachning av frågeresultat

För att förbättra prestandan är query caching ett måste. Frågecache som är tillgängligt i MariaDB kommer helt enkelt inte att fungera i mycket samtidig miljö eftersom det tvingar fram serialisering av frågorna, vilket allvarligt minskar prestandan även för skrivskyddade arbetsbelastningar. Att använda extern lösning för cache är inte alltid genomförbart:trots allt kommer du att få ännu en databas att underhålla, säkra och hålla frisk. Det kan vara bättre att använda MaxScale som en cache förutsatt att du redan använder den för annan funktionalitet.

Frågeblockering

Ibland lider databaser av en ineffektiv fråga, vilket skapar hög belastning på systemet. Det kan vara att omskrivningen av den frågan skulle ta alldeles för lång tid (någon skulle behöva skriva om den, testa förändringen på iscensättning och sedan till slut distribuera till produktion), en tid som du inte har. MaxScale kan hjälpa dig här med funktioner som frågeblockering, som i princip låter dig stoppa en given fråga från att träffa databasen. Den här funktionen kan också användas för att bygga en SQL-brandvägg - släpp alla frågor som matchar mönster som pekar mot SQL-injektion eller andra, potentiellt farliga och skadliga aktiviteter.

Som du kan se kommer MariaDB TX med en lista med funktioner och programvara som är designad för att fungera tillsammans och bygga högt tillgänglig, skalbar databas för transaktionsdatabehandling.

Enterprise Monitoring &Management för MariaDB TX

ClusterControl stöder MariaDB TX fullt ut. Du kan enkelt distribuera både MariaDB Server 10.3 och MaxScale 2.3. ClusterControl stöder MariaDB-replikeringsinställningar såväl som MariaDB Galera Cluster.

Så länge du har SSH-anslutning från din ClusterControl-instans till de noder du vill distribuera MariaDB TX på, kan du göra det med bara ett par klick.

Först måste du definiera hur ClusterControl ska nå MariaDB TX-noderna.

Välj sedan MariaDB som leverantör och välj en av de versioner som stöds. Skicka MariaDB root-lösenordet.

Slutligen, bestäm dig för topologin. Du kan distribuera MariaDB TX i en master - master, aktiv - standby-inställning med ytterligare slavar. Replikering kommer att använda MariaDB GTID.

För MariaDB Galera Cluster är första steget exakt detsamma, sedan behöver du bara välja MariaDB som leverantör, bestämma versionen och definiera noder i MariaDB Galera Cluster:

Till exempel är det bara några klick bort att lägga till MaxScale-lastbalanserare:

När du har distribuerat den kan du hantera din MaxScale med ClusterControl:

Du kan även skala ditt Galera-kluster genom att lägga till nya Galera-noder eller asynkrona replikeringsslavar. Du kan lägga till slavar eller fördröjda slavar till dina replikeringsinställningar, eller utföra topologiändringar genom att befordra en slav till master och återslava resten av installationen. ClusterControl kommer att övervaka klustret och försöka återställa misslyckade noder eller kluster om en incident skulle inträffa. För säkerhetskopiering kan ClusterControl hjälpa dig att definiera ett säkerhetskopieringsschema med både mysqldump och Mariabackup så att du enkelt kan dra nytta av krypteringsfunktionerna i MariaDB TX.

För övervaknings- och trenddelen kan ClusterControl användas antingen i ett agentlöst läge:

Eller så kan den användas tillsammans med Prometheus och agenter för att ge ännu bättre insikt i vad som händer i MariaDB TX-klustret.

Vi hoppas att det här inledande blogginlägget hjälpte dig att förstå vad MariaDB TX är och hur ClusterControl kan hjälpa dig att hantera det.