Migreren van MySQL Enterprise naar MariaDB 10.3

Hoewel het hetzelfde erfgoed deelt met MySQL, is MariaDB een andere database. In de loop der jaren, toen nieuwe versies van MySQL en MariaDB werden uitgebracht, zijn beide projecten verschillend geworden in twee verschillende RDBMS-platforms.

MariaDB wordt de belangrijkste databasedistributie op veel Linux-platforms en wordt tegenwoordig erg populair. Tegelijkertijd wordt het voor veel bedrijven een zeer aantrekkelijk databasesysteem. Het krijgt functies die dicht bij de bedrijfsbehoeften liggen, zoals codering, hot backups of compatibiliteit met eigen databases.

Maar hoe beïnvloeden nieuwe functies de compatibiliteit van MariaDB met MySQL? Is het nog steeds druppelvervanging voor MySQL? Hoe versterken de laatste wijzigingen het migratieproces? We zullen proberen daar in dit artikel antwoord op te geven.

Wat u moet weten voordat u gaat upgraden

MariaDB en MySQL verschillen aanzienlijk van elkaar in de afgelopen twee jaar, vooral met de komst van hun meest recente versies:MySQL 8.0, MariaDB 10.3 en MariaDB 10.4 RC (we hebben vrij recent nieuwe functies van MariaDB 10.4 RC besproken, dus als u lees meer over wat er in 10.4 staat te gebeuren, bekijk twee blogs van mijn collega Krzysztof, What's New in MariaDB 10.4 en ten tweede over What's New in MariaDB Cluster 10.4).

Met de release MariaDB 10.3 verraste MariaDB velen omdat het niet langer een drop-in vervanging is voor MySQL. MariaDB voegt niet langer nieuwe MySQL-functies samen met MariaDB noir die MySQL-bugs oplost. Niettemin wordt versie 10.3 nu een echt alternatief voor Oracle MySQL Enterprise en andere bedrijfseigen databases zoals Oracle 12c (MSSQL in versie 10.4).

Voorlopige controle en beperkingen

Migratie is een complex proces, ongeacht naar welke versie u een upgrade uitvoert. Er zijn een paar dingen waarmee u rekening moet houden bij het plannen hiervan, zoals essentiële wijzigingen tussen RDBMS-versies en gedetailleerde tests die elk upgradeproces moeten leiden. Dit is vooral van cruciaal belang als u de beschikbaarheid wilt behouden voor de duur van de upgrade.

Upgraden naar een nieuwe hoofdversie brengt risico's met zich mee en het is belangrijk om het hele proces zorgvuldig te plannen. In dit document bekijken we de belangrijke nieuwe wijzigingen in versie 10.3 (en aankomende 10.4) en laten we zien hoe u het testproces plant.

Laten we eens kijken naar platformverschillen en -beperkingen om het risico te minimaliseren.

Beginnend met de configuratie zijn er enkele parameters die verschillende standaardwaarden hebben. MariaDB biedt een matrix van parameterverschillen. Het is hier te vinden.

In MySQL 8.0 is caching_sha2_password de standaard authenticatie-plug-in. Deze verbetering zou de beveiliging moeten verbeteren door gebruik te maken van het SHA-256-algoritme. MySQL heeft deze plug-in standaard ingeschakeld, terwijl MariaDB dat niet doet. Hoewel er al een functieverzoek is geopend met MariaDB MDEV-9804. MariaDB biedt in plaats daarvan de plug-in ed25519, wat een goed alternatief lijkt te zijn voor de oude authenticatiemethode.

MariaDB's ondersteuning voor encryptie op tabellen en tablespaces is toegevoegd in versie 10.1.3. Omdat uw tabellen versleuteld zijn, is het bijna onmogelijk voor iemand om uw gegevens te stelen. Met dit type codering kan uw organisatie ook voldoen aan overheidsvoorschriften zoals AVG.

MariaDB ondersteunt verbindingsthreadpools, die het meest effectief zijn in situaties waarin query's relatief kort zijn en de belasting CPU-gebonden is. Op de community-editie van MySQL is het aantal threads statisch, wat de flexibiliteit in deze situaties beperkt. Het ondernemingsplan van MySQL omvat threadpool-mogelijkheden.

MySQL 8.0 bevat het sys-schema, een set objecten die databasebeheerders en software-engineers helpt bij het interpreteren van gegevens die zijn verzameld door het prestatieschema. Sys-schema-objecten kunnen worden gebruikt voor gebruiksscenario's voor optimalisatie en diagnose. MariaDB heeft deze verbetering niet inbegrepen.

Een andere is onzichtbare kolommen. Onzichtbare kolommen bieden de flexibiliteit om kolommen aan bestaande tabellen toe te voegen zonder bang te hoeven zijn dat een toepassing kapot gaat. Deze functie is niet beschikbaar in MySQL. Hiermee kunnen kolommen worden gemaakt die niet worden vermeld in de resultaten van een SELECT *-instructie, en ze hoeven ook geen waarde te krijgen in een INSERT-instructie wanneer hun naam niet in de instructie wordt genoemd.

MariaDB besloot geen native JSON-ondersteuning te implementeren (een van de belangrijkste functies van MySQL 5.7 en 8.0) omdat ze beweren dat het geen deel uitmaakt van de SQL-standaard. In plaats daarvan hebben ze, om replicatie vanuit MySQL te ondersteunen, alleen een alias gedefinieerd voor JSON, wat eigenlijk een LONGTEXT-kolom is. Om ervoor te zorgen dat een geldig JSON-document wordt ingevoegd, kan de JSON_VALID-functie worden gebruikt als een CHECK-beperking (standaard voor MariaDB 10.4.3). MariaDB heeft geen directe toegang tot de MySQL JSON-indeling.

Oracle automatiseert veel taken met MySQL Shell. Naast SQL biedt MySQL Shell ook scriptmogelijkheden voor JavaScript en Python.

Migratieproces met mysqldump

Als we eenmaal onze beperkingen kennen, is het installatieproces vrij eenvoudig. Het is vrijwel gerelateerd aan standaardinstallatie en import met behulp van mysqldump. De back-uptool van MySQL Enterprise is niet compatibel met MariaDB, dus de aanbevolen manier is om mysqldump te gebruiken. Hier is het voorbeeldproces dat wordt gedaan op Centos 7 en MariaDB 10.3.

Dump maken op MySQL Enterprise-server

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

yum cache-index opschonen

sudo yum makecache fast

Installeer MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Start de MariaDB-service.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Beveilig MariaDB door mysql_secure_installation uit te voeren.

# 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!

Dump importeren

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

$vi import.log

Om een ​​omgeving te implementeren, kun je ook ClusterControl gebruiken, dat een optie heeft om helemaal opnieuw te implementeren.

ClusterControl kan ook worden gebruikt om replicatie in te stellen of om een ​​back-up uit MySQL Enterprise Edition te importeren.

Migratieproces met behulp van replicatie

De andere benadering voor migratie tussen MySQL Enterprise en MariaDB is het gebruik van een replicatieproces. Met MariaDB-versies kunt u ernaar repliceren vanuit MySQL-databases - wat betekent dat u MySQL-databases eenvoudig naar MariaDB kunt migreren. MySQL Enterprise-versies staan ​​geen replicatie van MariaDB-servers toe, dus dit is eenrichtingsverkeer.

Hier zijn enkele algemene regels die door de MariaDB worden aangegeven.

• Repliceren van MySQL 5.5 naar MariaDB 5.5+ zou gewoon moeten werken. U wilt dat MariaDB dezelfde of een hogere versie is dan uw MySQL-server.
• Als je een MariaDB 10.2+ als slave gebruikt, kan het nodig zijn om binlog_checksum in te stellen op NONE.
• Repliceren van MySQL 5.6 zonder GTID naar MariaDB 10+ zou moeten werken.
• Replicatie van MySQL 5.6 met GTID, binlog_rows_query_log_events en ignorable events werkt vanaf MariaDB 10.0.22 en MariaDB 10.1.8. In dit geval zal MariaDB de MySQL GTID's en andere onnodige gebeurtenissen verwijderen en in plaats daarvan haar eigen GTID's toevoegen.

Zelfs als u niet van plan bent om replicatie te gebruiken in het migratie-/cutoverproces, is het een goede vertrouwensmaker om uw productieserver te repliceren op een test-sandbox en er vervolgens op te oefenen.

We hopen dat deze inleidende blogpost u heeft geholpen het beoordelings- en implementatieproces van MySQL Enterprise Migration naar MariaDB te begrijpen.