MariaDB 10.4 is een huidige ontwikkelingstak van MariaDB. Onlangs, op 21 mei, is de derde Release Candidate (10.4.5) uitgebracht, wat ons dichter bij de officiële release brengt. Daarom dachten we dat het misschien een goed idee is om de nieuwe 10.4-functies eens te bekijken. We zullen ook enkele gedachten delen over een recent blogbericht dat is gepubliceerd door MariaDB Corporation. Voor informatie over de release zelf kun je alle details vinden in de changelog van MariaDB 10.4.0.
Prestatiewijzigingen
Unicode-tekensets zijn doorgaans langzamer dan tekensets zoals latin1, vooral vanwege hun grootte. MySQL 8.0 bracht aanzienlijke verbeteringen op dit gebied en MariaDB 10.4 zou in dit opzicht ook merkbaar sneller moeten zijn dan 10.3. Het is een behoorlijk belangrijke verbetering - mensen houden er echt van om emoji's te gebruiken, waarvoor UTF8 moet zijn ingeschakeld. Er is wat werk verzet in de optimizer - MariaDB 10.4 zou beter moeten werken voor IN()-subquery's, aangezien het nu mogelijk is om voorwaarden in gematerialiseerde subquery's te pushen.
Het starten en stoppen van InnoDB kan even duren, afhankelijk van de hoeveelheid gegevens in de redo-logs. MariaDB 10.4 verbetert het opstarten, afsluiten en opschonen. Dergelijke verbeteringen zijn vooral belangrijk gezien de populariteit van hot back-uptools zoals mariabackup en xtrabackup. Die tools doorlopen uiteindelijk het InnoDB-opstartproces vanaf een onreine afsluiting wanneer ze opnieuw logs toepassen, daarom zou elke verbetering op dat gebied de tijd die nodig is om back-ups te herstellen, moeten verkorten.
InnoDB-wijzigingen
MariaDB 10.4 heeft een directe DROP COLUMN-bewerking ontvangen. Het is nu ook mogelijk om de kolommen in de tabel opnieuw te ordenen zonder deze opnieuw te hoeven maken. We kunnen niet genoeg benadrukken hoe belangrijk dit is. U vraagt zich misschien af wat de meest voorkomende handelingen zijn die u in de productieomgeving uitvoert? We zouden zeggen dat het een index toevoegt of verwijdert. Een andere meest voorkomende bewerking zijn bewerkingen op de kolommen - voeg een nieuwe kolom toe en verwijder de bestaande kolom. Tot nu toe was de meest gebruikelijke benadering het gebruik van externe tools om het werk te doen:pt-online-schema-change of, meer recentelijk, gh-ost. Beide hebben hun beperkingen (gh-ost werkt bijvoorbeeld niet voor Galera Cluster) waardoor het onmogelijk is om ze op uw systeem te gebruiken. Vooral lastig zijn buitenlandse sleutels. Met instant DROP COLUMN (instant ADD COLUMN is al beschikbaar) kan een groot deel van de schemawijzigingen ad hoc worden uitgevoerd, zonder gedetailleerde planning en planning, zoals nu moet. Het is belangrijk om in gedachten te houden dat onmiddellijke veranderingen zijn wat we willen hebben. Er zijn niet-blokkerende schemawijzigingen, zoals het maken van een index, maar dergelijke bewerkingen vormen een serieuze uitdaging wanneer de replicatie wordt gebruikt, omdat ze replicatievertraging veroorzaken. Dus hoewel de bewerking op een live systeem had kunnen worden uitgevoerd, geven we er de voorkeur aan om tijdelijke oplossingen zoals pt-online-schema-change te gebruiken om betere controle over het proces te houden.
Dit is niet de enige verbetering in de manier waarop schemawijzigingen worden uitgevoerd. MariaDB 10.4 zal profiteren van een snellere uitbreiding van VARCHAR-kolommen, bovendien zullen wijzigingen in de tekenset en sortering op niet-geïndexeerde kolommen onmiddellijk zijn.
Algemene wijzigingen
Een van de grootste veranderingen zijn wijzigingen in het gebruikersbeheer. Mysql.host-tabel wordt niet gemaakt, mysql.user-tabel is verouderd. Gebruikersaccounts en algemene privileges worden bewaard in de tabel mysql.global_priv. Dit is potentieel een serieuze verandering voor alle tools (inclusief ClusterControl), die een optie hebben om MySQL- en MariaDB-gebruikers te beheren - er zullen nieuwe cases moeten worden geschreven om gebruikersbeheer in MariaDB 10.4 en hoger te dekken. Hoewel we erkennen dat er veranderingen nodig zijn, helpt dit zeker niet om tools voor zowel MariaDB als MySQL te behouden, waardoor het toolinglandschap nog meer verdeeld is dan het al is. Over gebruikers gesproken, MariaDB 10.4 wordt geleverd met een optie om het gebruikerswachtwoord te laten verlopen. Dit is absoluut een stap in de goede richting - het helpt om goede praktijken met betrekking tot wachtwoordbeheer af te dwingen.
Ook al zullen we er in een aparte blog uitgebreider op ingaan, toch moeten we hier de ondersteuning voor Galera 26.4 vermelden - MariaDB 10.4 zal profiteren van een nieuwe Galera-versie met functies zoals streaming-replicatie of verbeterde SST dankzij back-upvergrendelingen.
Ten slotte kunt u in MariaDB 10.4 sql_mode=MSSQL instellen. Dit is een initiële implementatie, maar sql_mode=ORACLE was ooit ook een initiële implementatie. Dit toont de focus van MariaDB op zakelijke klanten - als Oracle-klanten besluiten te migreren, is het zeer waarschijnlijk dat de acceptatie van MariaDB door Microsoft SQL Server ook zal toenemen naarmate er meer functies worden toegevoegd en migratie minder een probleem zal worden.
MariaDB een vork zijn
Vrij recent zagen we een blogpost waarin het standpunt van MariaDB over InnoDB-wijzigingen en compatibiliteit werd uitgelegd. De essentie is dat MariaDB niet langer InnoDB-functies van MySQL zal samenvoegen, de focus zal liggen op de stabiliteit en prestatieverbetering die door MariaDB wordt gedaan. Dit betekent in feite dat MariaDB incompatibel wordt met MySQL. Zelfs als u de binaire upgrade in het verleden zou kunnen doen, zal dit in de toekomst niet mogelijk zijn. Zelfs nu kan het lastig zijn om uit te voeren. Dit vergroot het belang van tools zoals mydumper/myloader, aangezien logische back-up de enige manier voor migratie is. Wat goed is, MariaDB zal de stabiliteit van hun vork van InnoDB kunnen bezitten - ze zullen niet te maken krijgen met problemen die zijn geïntroduceerd door upstream-ontwikkelaars, daarom kunnen we verwachten dat er minder bugs worden geïntroduceerd.
Qua prestaties moeten we wachten op benchmarks, maar gezien de historische gegevens kunnen we aannemen dat MariaDB langzamer zal zijn dan MySQL. In eerdere benchmarks zien we meestal dat de prestatieverbetering voor MariaDB begint wanneer een recentere InnoDB-versie is geïntegreerd. Dit zal niet langer het geval zijn, waardoor we ons afvragen hoe MariaDB het voortaan zal doen in de prestatievergelijking en of de verbeteringen die door MariaDB zijn geïntroduceerd voldoende zullen zijn om MySQL 8.0 en andere versies bij te houden.
Voor ons gebruikers betekent dit alles dat MariaDB 10.4 stabieler zou moeten zijn dan de vorige releases. Het betekent ook dat we uiteindelijk de internals van twee verschillende storage-engines zullen moeten leren - vooral als we om de prestaties geven. Dit is verre van ideaal, maar het is nu eenmaal zo. Tools moeten worden ontworpen om met de ene of de andere versie van InnoDB te werken (of er moet extra werk worden toegevoegd om zowel MySQL als MariaDB te ondersteunen). We houden in de gaten hoe dit verder gaat. Als je erover nadenkt, is het niet zo'n verrassende zet - MariaDB moest altijd de tijd nemen om te integreren met de recentere InnoDB-versie. Met steeds meer incompatibele functies die worden toegevoegd aan MariaDB en enorme veranderingen die zijn geïntroduceerd in MySQL 8.0, is het logisch om te focussen op het ontwikkelen van nieuwe functionaliteit in plaats van op het overzetten van incompatibele InnoDB van upstream MySQL.
We hopen dat deze korte blogpost je inzicht heeft gegeven in de veranderingen die de productiesystemen zullen treffen wanneer je naar MariaDB 10.4 gaat.