Migrering fra MySQL Enterprise til MariaDB 10.3

Mens det deler den samme arv med MySQL, er MariaDB en anden database. I årenes løb, da nye versioner af MySQL og MariaDB blev frigivet, har begge projekter adskilt sig i to forskellige RDBMS-platforme.

MariaDB bliver den vigtigste databasedistribution på mange Linux-platforme, og det bliver høj popularitet i disse dage. Samtidig bliver det et meget attraktivt databasesystem for mange virksomheder. Det får funktioner, der er tæt på virksomhedens behov, såsom kryptering, hot backups eller kompatibilitet med proprietære databaser.

Men hvordan påvirker nye funktioner MariaDB-kompatibiliteten med MySQL? Er det stadig drop-erstatning for MySQL? Hvordan forstærker de seneste ændringer migreringsprocessen? Det vil vi forsøge at besvare i denne artikel.

Hvad du skal vide før opgradering

MariaDB og MySQL adskiller sig væsentligt fra hinanden i de sidste to år, især med ankomsten af ​​deres seneste versioner:MySQL 8.0, MariaDB 10.3 og MariaDB 10.4 RC (vi diskuterede nye funktioner i MariaDB 10.4 RC for ganske nylig, så hvis du gerne vil læs mere om, hvad der kommer i 10.4, tjek venligst to blogs af min kollega Krzysztof, Hvad er nyt i MariaDB 10.4 og andet om Hvad er nyt i MariaDB Cluster 10.4).

Med udgivelsen MariaDB 10.3 overraskede MariaDB mange, da det ikke længere er en drop-in-erstatning for MySQL. MariaDB fusionerer ikke længere nye MySQL-funktioner med MariaDB noir, der løser MySQL-fejl. Ikke desto mindre er version 10.3 nu ved at blive et reelt alternativ til Oracle MySQL Enterprise såvel som andre proprietære virksomhedsdatabaser såsom Oracle 12c (MSSQL i version 10.4).

Foreløbig kontrol og begrænsninger

Migrering er en kompleks proces, uanset hvilken version du opgraderer til. Der er et par ting, du skal huske på, når du planlægger dette, såsom væsentlige ændringer mellem RDBMS-versioner samt detaljerede test, der skal lede enhver opgraderingsproces. Dette er især vigtigt, hvis du gerne vil bevare tilgængeligheden under opgraderingens varighed.

Opgradering til en ny større version indebærer risiko, og det er vigtigt at planlægge hele processen med omtanke. I dette dokument vil vi se på de vigtige nye ændringer i 10.3 (og den kommende 10.4) version og vise dig, hvordan du planlægger testprocessen.

For at minimere risikoen, lad os tage et kig på platformforskelle og begrænsninger.

Fra konfigurationen er der nogle parametre, der har forskellige standardværdier. MariaDB giver en matrix af parameterforskelle. Den kan findes her.

I MySQL 8.0 er caching_sha2_password standardgodkendelsesplugin'et. Denne forbedring skulle forbedre sikkerheden ved at bruge SHA-256-algoritmen. MySQL har dette plugin aktiveret som standard, mens MariaDB ikke gør det. Selvom der allerede er åbnet en funktionsanmodning med MariaDB MDEV-9804. MariaDB tilbyder i stedet ed25519 plugin, som ser ud til at være et godt alternativ til den gamle godkendelsesmetode.

MariaDBs understøttelse af kryptering på tabeller og tablespaces blev tilføjet i version 10.1.3. Når dine tabeller er krypteret, er dine data næsten umulige for nogen at stjæle. Denne type kryptering gør det også muligt for din organisation at overholde regeringsbestemmelser såsom GDPR.

MariaDB understøtter forbindelsestrådspuljer, som er mest effektive i situationer, hvor forespørgsler er relativt korte, og belastningen er CPU-bundet. På MySQL’s community-udgave er antallet af tråde statisk, hvilket begrænser fleksibiliteten i disse situationer. Virksomhedsplanen for MySQL inkluderer threadpool-funktioner.

MySQL 8.0 inkluderer sys-skemaet, et sæt objekter, der hjælper databaseadministratorer og softwareingeniører med at fortolke data indsamlet af Performance Schema. Sys-skemaobjekter kan bruges til optimering og diagnosticering. MariaDB har ikke denne forbedring inkluderet.

En anden er usynlige søjler. Usynlige kolonner giver fleksibiliteten til at tilføje kolonner til eksisterende tabeller uden frygt for at bryde en applikation. Denne funktion er ikke tilgængelig i MySQL. Det tillader oprettelse af kolonner, som ikke er angivet i resultaterne af en SELECT *-sætning, og de behøver heller ikke at blive tildelt en værdi i en INSERT-sætning, når deres navn ikke er nævnt i sætningen.

MariaDB besluttede ikke at implementere indbygget JSON-understøttelse (en af ​​hovedfunktionerne i MySQL 5.7 og 8.0), da de hævder, at det ikke er en del af SQL-standarden. I stedet, for at understøtte replikering fra MySQL, definerede de kun et alias for JSON, som faktisk er en LONGTEXT-kolonne. For at sikre, at et gyldigt JSON-dokument er indsat, kan JSON_VALID-funktionen bruges som en CHECK-begrænsning (standard for MariaDB 10.4.3). MariaDB kan ikke direkte få adgang til MySQL JSON-format.

Oracle automatiserer en masse opgaver med MySQL Shell. Ud over SQL tilbyder MySQL Shell også script-funktioner til JavaScript og Python.

Migreringsproces ved hjælp af mysqldump

Når vi kender vores begrænsninger, er installationsprocessen ret enkel. Det er stort set relateret til standardinstallation og import ved hjælp af mysqldump. MySQL Enterprise backup-værktøj er ikke kompatibelt med MariaDB, så den anbefalede måde er at bruge mysqldump. Her er eksempelprocessen udført på Centos 7 og MariaDB 10.3.

Opret dump på MySQL Enterprise-server

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

Rens yum cache indeks

sudo yum makecache fast

Installer MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Start MariaDB-tjenesten.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Sikre MariaDB ved at køre 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

For at implementere et miljø kan du også bruge ClusterControl, som har en mulighed for at implementere fra bunden.

ClusterControl kan også bruges til at opsætte replikering eller til at importere en sikkerhedskopi fra MySQL Enterprise Edition.

Migreringsproces ved hjælp af replikering

Den anden tilgang til migrering mellem MySQL Enterprise og MariaDB er at bruge replikeringsprocessen. MariaDB-versioner tillader replikering til dem fra MySQL-databaser - hvilket betyder, at du nemt kan migrere MySQL-databaser til MariaDB. MySQL Enterprise-versioner tillader ikke replikering fra MariaDB-servere, så dette er envejsrute.

Her er nogle generelle regler, som MariaDB peger på.

• Replikation fra MySQL 5.5 til MariaDB 5.5+ burde bare fungere. Du vil have MariaDB til at være den samme eller højere version end din MySQL-server.
• Når du bruger en MariaDB 10.2+ som slave, kan det være nødvendigt at indstille binlog_checksum til NONE.
• Replikation fra MySQL 5.6 uden GTID til MariaDB 10+ burde fungere.
• Replikering fra MySQL 5.6 med GTID, binlog_rows_query_log_events og ignorerbare hændelser fungerer fra MariaDB 10.0.22 og MariaDB 10.1.8. I dette tilfælde vil MariaDB fjerne MySQL GTID'erne og andre unødvendige hændelser og tilføjer i stedet sine egne GTID'er.

Selvom du ikke planlægger at bruge replikering i migrerings-/cutover-processen, er det en god tillidsskaber at replikere din produktionsserver på en testsandbox og derefter øve dig på den.

Vi håber, at dette indledende blogindlæg hjalp dig med at forstå vurderingen og implementeringsprocessen af ​​MySQL Enterprise Migration til MariaDB.