Migrace z MySQL Enterprise na MariaDB 10.3

I když sdílí stejné dědictví s MySQL, MariaDB je jiná databáze. Během let, kdy byly vydány nové verze MySQL a MariaDB, se oba projekty lišily ve dvou různých platformách RDBMS.

MariaDB se stává hlavní databázovou distribucí na mnoha linuxových platformách a v dnešní době získává vysokou popularitu. Zároveň se stává velmi atraktivním databázovým systémem pro mnoho korporací. Získává funkce, které jsou blízké podnikovým potřebám, jako je šifrování, horké zálohy nebo kompatibilita s proprietárními databázemi.

Jak ale nové funkce ovlivňují kompatibilitu MariaDB s MySQL? Je to stále náhrada za MySQL? Jak nejnovější změny umocňují proces migrace? Na to se pokusíme odpovědět v tomto článku.

Co potřebujete vědět před upgradem

MariaDB a MySQL se od sebe v posledních dvou letech výrazně liší, zejména s příchodem jejich nejnovějších verzí:MySQL 8.0, MariaDB 10.3 a MariaDB 10.4 RC (nové funkce MariaDB 10.4 RC jsme probírali poměrně nedávno, takže pokud byste chtěli přečtěte si více o tom, co se chystá v 10.4, podívejte se na dva blogy mého kolegy Krzysztofa, Co je nového v MariaDB 10.4 a druhý o Co je nového v MariaDB Cluster 10.4).

S vydáním MariaDB 10.3 překvapila MariaDB mnohé, protože již není náhradní náhradou za MySQL. MariaDB již neslučuje nové funkce MySQL s MariaDB noir řešící chyby MySQL. Verze 10.3 se však nyní stává skutečnou alternativou k Oracle MySQL Enterprise a dalším podnikovým proprietárním databázím, jako je Oracle 12c (MSSQL ve verzi 10.4).

Předběžná kontrola a omezení

Migrace je složitý proces bez ohledu na to, na kterou verzi upgradujete. Existuje několik věcí, které musíte mít při plánování na paměti, jako jsou zásadní změny mezi verzemi RDBMS a také podrobné testování, které musí vést jakýkoli proces upgradu. To je zvláště důležité, pokud chcete zachovat dostupnost po dobu upgradu.

Upgrade na novou hlavní verzi zahrnuje riziko a je důležité celý proces promyšleně naplánovat. V tomto dokumentu se podíváme na důležité nové změny ve verzi 10.3 (a nadcházející verzi 10.4) a ukážeme vám, jak naplánovat proces testování.

Abychom toto riziko minimalizovali, podívejme se na rozdíly a omezení platforem.

Počínaje konfigurací existují některé parametry, které mají různé výchozí hodnoty. MariaDB poskytuje matici rozdílů parametrů. Najdete ho zde.

V MySQL 8.0 je caching_sha2_password výchozím ověřovacím pluginem. Toto vylepšení by mělo zlepšit zabezpečení pomocí algoritmu SHA-256. MySQL má tento plugin ve výchozím nastavení povolený, zatímco MariaDB ne. Ačkoli již existuje požadavek na funkci otevřený s MariaDB MDEV-9804. MariaDB místo toho nabízí plugin ed25519, který se zdá být dobrou alternativou ke staré metodě ověřování.

Podpora MariaDB pro šifrování v tabulkách a tabulkových prostorech byla přidána ve verzi 10.1.3. Vzhledem k tomu, že vaše tabulky jsou šifrované, je téměř nemožné, aby někdo ukradl vaše data. Tento typ šifrování také umožňuje vaší organizaci, aby byla v souladu s vládními nařízeními, jako je GDPR.

MariaDB podporuje fondy vláken připojení, které jsou nejúčinnější v situacích, kdy jsou dotazy relativně krátké a zatížení je vázáno na CPU. V komunitní edici MySQL je počet vláken statický, což omezuje flexibilitu v těchto situacích. Podnikový plán MySQL zahrnuje možnosti fondu vláken.

MySQL 8.0 obsahuje schéma sys, sadu objektů, které pomáhají správcům databází a softwarovým inženýrům interpretovat data shromážděná pomocí schématu výkonu. Objekty sys schématu lze použít pro případy použití optimalizace a diagnostiky. MariaDB toto vylepšení neobsahuje.

Dalším jsou neviditelné sloupy. Neviditelné sloupce poskytují flexibilitu přidávání sloupců do existujících tabulek bez obav z rozbití aplikace. Tato funkce není v MySQL dostupná. Umožňuje vytvářet sloupce, které nejsou uvedeny ve výsledcích příkazu SELECT *, ani jim není třeba přiřazovat hodnotu v příkazu INSERT, když jejich název není v příkazu uveden.

MariaDB se rozhodla neimplementovat nativní podporu JSON (jedna z hlavních funkcí MySQL 5.7 a 8.0), protože tvrdí, že není součástí standardu SQL. Místo toho, aby podporovali replikaci z MySQL, definovali pouze alias pro JSON, což je ve skutečnosti sloupec LONGTEXT. Aby bylo zajištěno, že bude vložen platný dokument JSON, lze jako omezení CHECK použít funkci JSON_VALID (výchozí pro MariaDB 10.4.3). MariaDB nemůže přímo přistupovat k formátu MySQL JSON.

Oracle automatizuje mnoho úloh pomocí MySQL Shell. Kromě SQL nabízí MySQL Shell také možnosti skriptování pro JavaScript a Python.

Proces migrace pomocí mysqldump

Jakmile známe naše omezení, proces instalace je poměrně jednoduchý. Do značné míry to souvisí se standardní instalací a importem pomocí mysqldump. Zálohovací nástroj MySQL Enterprise není kompatibilní s MariaDB, takže doporučeným způsobem je použít mysqldump. Zde je ukázkový proces prováděný na Centos 7 a MariaDB 10.3.

Vytvořte výpis na serveru MySQL Enterprise

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

Vyčistit index mezipaměti yum

sudo yum makecache fast

Nainstalujte MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Spusťte službu MariaDB.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Zabezpečte MariaDB spuštěním 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!

Import výpisu

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

$vi import.log

K nasazení prostředí můžete také použít ClusterControl, který má možnost nasazení od začátku.

ClusterControl lze také použít k nastavení replikace nebo importu zálohy z MySQL Enterprise Edition.

Proces migrace pomocí replikace

Dalším přístupem k migraci mezi MySQL Enterprise a MariaDB je použití procesu replikace. Verze MariaDB umožňují replikaci z databází MySQL - což znamená, že můžete snadno migrovat databáze MySQL do MariaDB. Verze MySQL Enterprise neumožňují replikaci ze serverů MariaDB, takže toto je jednosměrná cesta.

Zde jsou některá obecná pravidla, na která upozorňuje MariaDB.

• Replikace z MySQL 5.5 na MariaDB 5.5+ by měla fungovat. Budete chtít, aby MariaDB byla stejná nebo vyšší verze než váš server MySQL.
• Při použití MariaDB 10.2+ jako slave může být nutné nastavit binlog_checksum na NONE.
• Replikace z MySQL 5.6 bez GTID do MariaDB 10+ by měla fungovat.
• Replikace z MySQL 5.6 s GTID, binlog_rows_query_log_events a ignorovatelnými událostmi funguje od MariaDB 10.0.22 a MariaDB 10.1.8. V tomto případě MariaDB odstraní MySQL GTID a další nepotřebné události a místo toho přidá vlastní GTID.

I když neplánujete používat replikaci v procesu migrace/přechodu, protože je dobrým nástrojem na budování důvěry, je replikovat svůj produkční server na testovací karanténě a poté na něm cvičit.

Doufáme, že vám tento úvodní příspěvek na blogu pomohl porozumět procesu hodnocení a implementace migrace MySQL Enterprise Migration na MariaDB.