MariaDB 10.4 är en aktuell utvecklingsgren av MariaDB. Nyligen, den 21 maj, släpptes den tredje Release Candidate (10.4.5), vilket för oss närmare den officiella releasen. Det är därför vi tänkte att det kan vara en bra idé att ta en titt på de nya 10.4-funktionerna. Vi kommer också att dela med oss av några tankar om ett färskt blogginlägg publicerat av MariaDB Corporation. För information om själva releasen kan du hitta alla detaljer i ändringsloggen för MariaDB 10.4.0.
Prestandaändringar
Unicode-teckenuppsättningar är vanligtvis långsammare än teckenuppsättningar som latin1, mestadels på grund av deras storlek. MySQL 8.0 medförde betydande förbättringar på detta område, och MariaDB 10.4 borde också vara märkbart snabbare än 10.3 i detta avseende. Det är en ganska viktig förbättring - folk älskar verkligen att använda emojis, som kräver UTF8 för att vara aktiverat. En del arbete har gjorts i optimeraren - MariaDB 10.4 borde fungera bättre för IN()-underfrågor eftersom det nu är möjligt att skjuta in villkor i materialiserade underfrågor.
Att starta och stoppa InnoDB kan ta ett tag, beroende på mängden data i redo-loggar. MariaDB 10.4 kommer att förbättra start, avstängning och rensning. Sådana förbättringar är särskilt viktiga med tanke på populariteten av heta säkerhetskopieringsverktyg som mariabackup och xtrabackup. Dessa verktyg går i slutändan igenom InnoDB-startprocessen från en oren avstängning när de tillämpar redo-loggar, därför bör varje förbättring inom det området minska tiden som behövs för att återställa säkerhetskopior.
InnoDB-ändringar
MariaDB 10.4 har fått en omedelbar DROP COLUMN-operation. Det är nu också möjligt att ändra ordning på kolumnerna i tabellen utan att behöva bygga om den. Vi kan inte betona hur viktigt detta är. Du kanske undrar vilka är de vanligaste operationerna som du gör i produktionsmiljön? Vi skulle säga att det är att lägga till eller ta bort ett index. En annan vanligaste operation skulle vara operationer på kolumnerna - lägg till en ny kolumn och ta bort befintlig kolumn. Hittills var det vanligaste tillvägagångssättet att använda externa verktyg för att göra jobbet:pt-online-schema-change eller, på senare tid, gh-ost. Båda har sina begränsningar (gh-ost fungerar till exempel inte för Galera Cluster) vilket kan göra det omöjligt att använda dem på ditt system. Särskilt knepiga är främmande nycklar. Med instant DROP COLUMN (direkt ADD COLUMN är redan tillgänglig) kan en stor del av schemaändringarna utföras ad hoc, utan detaljerad schemaläggning och planering, som det måste göras nu. Det är viktigt att komma ihåg att omedelbara förändringar är vad vi vill ha. Det finns icke-blockerande schemaändringar, som att skapa ett index, men sådana operationer utgör en allvarlig utmaning när replikeringen används eftersom de inducerar replikeringsfördröjning. Så även om operationen kunde ha körts på ett livesystem, föredrar vi att använda lösningar som pt-online-schema-change för att ha bättre kontroll över processen.
Detta är inte den enda förbättringen av hur schemaändringar exekveras. MariaDB 10.4 kommer att dra nytta av snabbare förlängning av VARCHAR-kolumner, dessutom kommer teckenuppsättningar och sorteringsändringar på icke-indexerade kolumner att ske omedelbart.
Allmänna ändringar
En av de största förändringarna är förändringar i användarhanteringen. Mysql.host-tabellen kommer inte att skapas, mysql.user-tabellen är utfasad. Användarkonton och globala privilegier kommer att behållas i tabellen mysql.global_priv. Detta är potentiellt en allvarlig förändring för alla verktyg (inklusive ClusterControl), som har en möjlighet att hantera MySQL- och MariaDB-användare - nya fall måste skrivas för att täcka användarhantering i MariaDB 10.4 och framåt. Även om vi erkänner att förändringar behövs, hjälper detta definitivt inte att underhålla verktyg för både MariaDB och MySQL, vilket gör verktygslandskapet ännu mer uppdelat än det redan är. På tal om användare, MariaDB 10.4 kommer med ett alternativ för utgående användarlösenord. Detta är definitivt ett steg i en bra riktning - det hjälper till att upprätthålla god praxis för lösenordshantering.
Även om vi kommer att ta upp det i en separat blogg mer i detalj, måste vi nämna här stöd för Galera 26.4 - MariaDB 10.4 kommer att dra nytta av en ny Galera-version med funktioner som strömmande replikering eller förbättrad SST tack vare säkerhetskopieringslås.
Slutligen, i MariaDB 10.4 kan du ställa in sql_mode=MSSQL. Detta är en initial implementering men sql_mode=ORACLE var också en initial implementering någon gång. Detta visar MariaDB:s fokus på företagskunder - om Oracle-kunder bestämmer sig för att migrera är det ganska troligt att MariaDB-användningen bland Microsoft SQL Server också kommer att växa eftersom fler funktioner kommer att läggas till och migreringen blir mindre problem.
MariaDB är en gaffel
Ganska nyligen såg vi ett blogginlägg som förklarar MariaDBs hållning om InnoDB-ändringar och kompatibilitet. Kontentan är att MariaDB inte längre kommer att slå samman InnoDB-funktioner från MySQL, fokus kommer att ligga på stabiliteten och prestandaförbättringen som görs av MariaDB. Detta betyder i princip att MariaDB kommer att bli inkompatibel med MySQL. Även om du kunde göra den binära uppgraderingen tidigare, kommer detta inte att vara möjligt i framtiden. Även just nu kan det vara knepigt att genomföra. Detta ökar vikten av verktyg som mydumper/myloader eftersom logisk säkerhetskopiering kommer att vara det enda sättet för migrering. Vad som är bra, MariaDB kommer att kunna äga stabiliteten i deras gaffel av InnoDB - de kommer inte att behöva ta itu med problem som introduceras av uppströmsutvecklare, därför kan vi förvänta oss att färre buggar introduceras.
Prestandamässigt måste vi vänta på benchmarks men med tanke på historiska data kan vi anta att MariaDB kommer att vara långsammare än MySQL. I tidigare riktmärken är det vi vanligtvis ser att prestandaökningen för MariaDB slår in när nyare InnoDB-version har integrerats. Detta kommer inte längre att vara fallet vilket får oss att undra hur MariaDB kommer att klara sig i prestandajämförelsen från och med nu och om de förbättringar som introducerats av MariaDB kommer att räcka för att hålla jämna steg med MySQL 8.0 och ytterligare versioner.
För oss användare betyder allt detta att MariaDB 10.4 borde vara stabilare än de tidigare utgåvorna. Det betyder också att vi så småningom kommer att behöva lära oss interna delar av två olika lagringsmotorer - speciellt om vi bryr oss om prestandan. Det här är långt ifrån idealiskt men det är så det är. Verktyg måste utformas för att fungera med den ena eller andra versionen av InnoDB (eller ytterligare arbete måste läggas till för att stödja både MySQL och MariaDB). Vi kommer att hålla ett öga på hur detta kommer att utvecklas. När du tänker på det är det inte ett så överraskande drag - MariaDB var alltid tvungen att ta sin tid att integrera med nyare InnoDB-version. Med fler och fler inkompatibla funktioner som läggs till i MariaDB och stora förändringar introducerade i MySQL 8.0, är det vettigt att fokusera på att utveckla ny funktionalitet snarare än på att porta inkompatibel InnoDB från uppströms MySQL.
Vi hoppas att detta korta blogginlägg gav dig insikt i förändringar som kommer att drabba produktionssystemen när du går till MariaDB 10.4.