Migrera från MySQL Enterprise till MariaDB 10.3

Medan den delar samma arv med MySQL, är MariaDB en annan databas. Under åren som nya versioner av MySQL och MariaDB släpptes, har båda projekten skiljt sig åt i två olika RDBMS-plattformar.

MariaDB blir den huvudsakliga databasdistributionen på många Linux-plattformar och det blir hög popularitet nu för tiden. Samtidigt blir det ett mycket attraktivt databassystem för många företag. Den får funktioner som ligger nära företagets behov som kryptering, heta säkerhetskopieringar eller kompatibilitet med egna databaser.

Men hur påverkar nya funktioner MariaDB-kompatibiliteten med MySQL? Är det fortfarande en droppersättning för MySQL? Hur förstärker de senaste ändringarna migreringsprocessen? Det ska vi försöka svara på i den här artikeln.

Vad du behöver veta innan du uppgraderar

MariaDB och MySQL skiljer sig avsevärt från varandra under de senaste två åren, särskilt med ankomsten av deras senaste versioner:MySQL 8.0, MariaDB 10.3 och MariaDB 10.4 RC (vi diskuterade nya funktioner i MariaDB 10.4 RC ganska nyligen så om du vill läs mer om vad som är på gång i 10.4, vänligen kolla två bloggar av min kollega Krzysztof, Vad är nytt i MariaDB 10.4 och det andra om Vad är nytt i MariaDB Cluster 10.4).

Med releasen MariaDB 10.3 överraskade MariaDB många eftersom det inte längre är en drop-in-ersättning för MySQL. MariaDB slår inte längre ihop nya MySQL-funktioner med MariaDB noir som löser MySQL-buggar. Ändå håller version 10.3 nu på att bli ett verkligt alternativ till Oracle MySQL Enterprise såväl som andra företags egna databaser som Oracle 12c (MSSQL i version 10.4).

Preliminär kontroll och begränsningar

Migrering är en komplex process oavsett vilken version du uppgraderar till. Det finns några saker du måste tänka på när du planerar detta, till exempel väsentliga förändringar mellan RDBMS-versioner samt detaljerade tester som måste leda en uppgraderingsprocess. Detta är särskilt viktigt om du vill behålla tillgängligheten under uppgraderingen.

Att uppgradera till en ny större version innebär risker och det är viktigt att planera hela processen eftertänksamt. I det här dokumentet kommer vi att titta på de viktiga nya ändringarna i version 10.3 (och kommande 10.4) och visa dig hur du planerar testprocessen.

För att minimera risken, låt oss ta en titt på plattformsskillnader och begränsningar.

Från och med konfigurationen finns det några parametrar som har olika standardvärden. MariaDB tillhandahåller en matris av parameterskillnader. Den finns här.

I MySQL 8.0 är caching_sha2_password standardinsticksprogrammet för autentisering. Denna förbättring bör förbättra säkerheten genom att använda SHA-256-algoritmen. MySQL har detta plugin aktiverat som standard, medan MariaDB inte gör det. Även om det redan finns en funktionsbegäran som har öppnats med MariaDB MDEV-9804. MariaDB erbjuder istället ed25519 plugin som verkar vara ett bra alternativ till den gamla autentiseringsmetoden.

MariaDB:s stöd för kryptering på tabeller och tabellutrymmen lades till i version 10.1.3. Med dina tabeller krypterade är dina data nästan omöjliga för någon att stjäla. Den här typen av kryptering gör att din organisation också kan följa myndighetsföreskrifter som GDPR.

MariaDB stöder anslutningstrådpooler, som är mest effektiva i situationer där frågorna är relativt korta och belastningen är CPU-bunden. På MySQL:s community-utgåva är antalet trådar statiskt, vilket begränsar flexibiliteten i dessa situationer. Företagsplanen för MySQL inkluderar threadpool-funktioner.

MySQL 8.0 inkluderar sys-schemat, en uppsättning objekt som hjälper databasadministratörer och programvaruingenjörer att tolka data som samlas in av Performance Schema. Sys-schemaobjekt kan användas för användningsfall för optimering och diagnos. MariaDB har inte denna förbättring inkluderad.

En annan är osynliga kolumner. Osynliga kolumner ger flexibiliteten att lägga till kolumner i befintliga tabeller utan rädsla för att bryta en applikation. Den här funktionen är inte tillgänglig i MySQL. Det gör det möjligt att skapa kolumner som inte är listade i resultaten av en SELECT *-sats, och de behöver inte heller tilldelas ett värde i en INSERT-sats när deras namn inte nämns i satsen.

MariaDB beslutade att inte implementera inbyggt JSON-stöd (en av huvudfunktionerna i MySQL 5.7 och 8.0) eftersom de hävdar att det inte är en del av SQL-standarden. Istället, för att stödja replikering från MySQL, definierade de bara ett alias för JSON, som egentligen är en LONGTEXT-kolumn. För att säkerställa att ett giltigt JSON-dokument infogas, kan JSON_VALID-funktionen användas som en CHECK-begränsning (standard för MariaDB 10.4.3). MariaDB kan inte direkt komma åt MySQL JSON-format.

Oracle automatiserar många uppgifter med MySQL Shell. Förutom SQL erbjuder MySQL Shell även skriptfunktioner för JavaScript och Python.

Migreringsprocess med mysqldump

När vi väl känner till våra begränsningar är installationsprocessen ganska enkel. Det är ganska mycket relaterat till standardinstallation och import med mysqldump. MySQL Enterprise backup-verktyg är inte kompatibelt med MariaDB så det rekommenderade sättet är att använda mysqldump. Här är exempelprocessen som görs på Centos 7 och MariaDB 10.3.

Skapa dump på MySQL Enterprise-server

$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sql

Rengör yum cache index

sudo yum makecache fast

Installera MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Starta MariaDB-tjänsten.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Säkra MariaDB genom att köra mysql_secure_installation.

# mysql_secure_installation 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Importdump

Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.

$vi import.log

För att distribuera en miljö kan du också använda ClusterControl som har en möjlighet att distribuera från början.

ClusterControl kan också användas för att ställa in replikering eller för att importera en säkerhetskopia från MySQL Enterprise Edition.

Migreringsprocess med replikering

Den andra metoden för migrering mellan MySQL Enterprise och MariaDB är att använda replikeringsprocessen. MariaDB-versioner tillåter replikering till dem, från MySQL-databaser - vilket innebär att du enkelt kan migrera MySQL-databaser till MariaDB. MySQL Enterprise-versioner tillåter inte replikering från MariaDB-servrar så detta är enkelriktad väg.

Här är några allmänna regler som MariaDB pekar på.

• Att replikera från MySQL 5.5 till MariaDB 5.5+ borde bara fungera. Du vill att MariaDB ska vara samma eller högre version än din MySQL-server.
• När du använder en MariaDB 10.2+ som slav kan det vara nödvändigt att ställa in binlog_checksum till NONE.
• Att replikera från MySQL 5.6 utan GTID till MariaDB 10+ borde fungera.
• Replikering från MySQL 5.6 med GTID, binlog_rows_query_log_events och ignorerbara händelser fungerar från MariaDB 10.0.22 och MariaDB 10.1.8. I det här fallet kommer MariaDB att ta bort MySQL GTID och andra onödiga händelser och istället lägga till sina egna GTID.

Även om du inte planerar att använda replikering i migrerings-/cutover-processen är det en bra förtroendebyggare att replikera din produktionsserver på en testsandlåda och sedan öva på den.

Vi hoppas att det här inledande blogginlägget hjälpte dig att förstå utvärderings- och implementeringsprocessen av MySQL Enterprise Migration till MariaDB.