Migrazione da MySQL Enterprise a MariaDB 10.3

Sebbene condivida la stessa eredità con MySQL, MariaDB è un database diverso. Nel corso degli anni, con il rilascio delle nuove versioni di MySQL e MariaDB, entrambi i progetti si sono differenziati in due diverse piattaforme RDBMS.

MariaDB diventa la principale distribuzione di database su molte piattaforme Linux e sta ottenendo grande popolarità in questi giorni. Allo stesso tempo, diventa un sistema di database molto interessante per molte aziende. Sta ottenendo funzionalità vicine alle esigenze aziendali come crittografia, backup a caldo o compatibilità con database proprietari.

Ma in che modo le nuove funzionalità influiscono sulla compatibilità di MariaDB con MySQL? È ancora una sostituzione a goccia per MySQL? In che modo le ultime modifiche amplificano il processo di migrazione? Cercheremo di rispondere in questo articolo.

Cosa devi sapere prima dell'aggiornamento

MariaDB e MySQL differiscono in modo significativo l'uno dall'altro negli ultimi due anni, specialmente con l'arrivo delle loro versioni più recenti:MySQL 8.0, MariaDB 10.3 e MariaDB 10.4 RC (abbiamo discusso delle nuove funzionalità di MariaDB 10.4 RC abbastanza di recente, quindi se vuoi per saperne di più su ciò che è in arrivo in 10.4, controlla due blog del mio collega Krzysztof, Novità in MariaDB 10.4 e secondo su Novità in MariaDB Cluster 10.4).

Con il rilascio MariaDB 10.3, MariaDB ha sorpreso molti poiché non è più un sostituto drop-in di MySQL. MariaDB non unisce più le nuove funzionalità di MySQL con MariaDB noir per risolvere i bug di MySQL. Tuttavia la versione 10.3 sta diventando una vera alternativa a Oracle MySQL Enterprise e ad altri database proprietari aziendali come Oracle 12c (MSSQL nella versione 10.4).

Verifica preliminare e limitazioni

La migrazione è un processo complesso, indipendentemente dalla versione a cui si esegue l'aggiornamento. Ci sono alcune cose che devi tenere a mente quando lo pianifichi, come le modifiche essenziali tra le versioni di RDBMS e i test dettagliati che devono guidare qualsiasi processo di aggiornamento. Ciò è particolarmente critico se desideri mantenere la disponibilità per tutta la durata dell'aggiornamento.

L'aggiornamento a una nuova versione principale comporta dei rischi ed è importante pianificare attentamente l'intero processo. In questo documento, esamineremo le nuove importanti modifiche nella versione 10.3 (e in arrivo 10.4) e ti mostreremo come pianificare il processo di test.

Per ridurre al minimo il rischio, diamo un'occhiata alle differenze e alle limitazioni della piattaforma.

A partire dalla configurazione ci sono alcuni parametri che hanno valori di default differenti. MariaDB fornisce una matrice di differenze di parametri. Può essere trovato qui.

In MySQL 8.0, caching_sha2_password è il plug-in di autenticazione predefinito. Questo miglioramento dovrebbe migliorare la sicurezza utilizzando l'algoritmo SHA-256. MySQL ha questo plugin abilitato per impostazione predefinita, mentre MariaDB no. Sebbene sia già stata aperta una richiesta di funzionalità con MariaDB MDEV-9804. MariaDB offre invece il plugin ed25519 che sembra essere una buona alternativa al vecchio metodo di autenticazione.

Il supporto di MariaDB per la crittografia su tabelle e tablespace è stato aggiunto nella versione 10.1.3. Con le tue tabelle crittografate, i tuoi dati sono quasi impossibili da rubare per qualcuno. Questo tipo di crittografia consente inoltre alla tua organizzazione di essere conforme alle normative governative come il GDPR.

MariaDB supporta i pool di thread di connessione, che sono più efficaci in situazioni in cui le query sono relativamente brevi e il carico è vincolato alla CPU. Nell'edizione della community di MySQL, il numero di thread è statico, il che limita la flessibilità in queste situazioni. Il piano aziendale di MySQL include funzionalità di pool di thread.

MySQL 8.0 include lo schema sys, un insieme di oggetti che aiuta gli amministratori di database e gli ingegneri del software a interpretare i dati raccolti dallo schema delle prestazioni. Gli oggetti Sys schema possono essere utilizzati per casi d'uso di ottimizzazione e diagnosi. MariaDB non include questo miglioramento.

Un altro sono le colonne invisibili. Le colonne invisibili offrono la flessibilità di aggiungere colonne alle tabelle esistenti senza il timore di interrompere un'applicazione. Questa funzione non è disponibile in MySQL. Consente di creare colonne che non sono elencate nei risultati di un'istruzione SELECT *, né è necessario assegnare loro un valore in un'istruzione INSERT quando il loro nome non è menzionato nell'istruzione.

MariaDB ha deciso di non implementare il supporto JSON nativo (una delle principali funzionalità di MySQL 5.7 e 8.0) poiché affermano che non fa parte dello standard SQL. Invece, per supportare la replica da MySQL, hanno definito solo un alias per JSON, che in realtà è una colonna LONGTEXT. Per garantire l'inserimento di un documento JSON valido, la funzione JSON_VALID può essere utilizzata come vincolo CHECK (impostazione predefinita per MariaDB 10.4.3). MariaDB non può accedere direttamente al formato JSON MySQL.

Oracle automatizza molte attività con MySQL Shell. Oltre a SQL, MySQL Shell offre anche funzionalità di scripting per JavaScript e Python.

Processo di migrazione tramite mysqldump

Una volta che conosciamo i nostri limiti, il processo di installazione è abbastanza semplice. È praticamente correlato all'installazione standard e all'importazione tramite mysqldump. Lo strumento di backup MySQL Enterprise non è compatibile con MariaDB, quindi il modo consigliato è utilizzare mysqldump. Ecco il processo di esempio eseguito su Centos 7 e MariaDB 10.3.

Crea dump sul server MySQL Enterprise

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

Pulisci l'indice della cache yum

sudo yum makecache fast

Installa MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Avvia il servizio MariaDB.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Proteggi MariaDB eseguendo 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!

Importa dump

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

$vi import.log

Per distribuire un ambiente puoi anche utilizzare ClusterControl che ha un'opzione per la distribuzione da zero.

ClusterControl può essere utilizzato anche per impostare la replica o per importare un backup da MySQL Enterprise Edition.

Processo di migrazione mediante replica

L'altro approccio per la migrazione tra MySQL Enterprise e MariaDB consiste nell'usare il processo di replica. Le versioni di MariaDB consentono la replica su di esse, dai database MySQL, il che significa che puoi migrare facilmente i database MySQL a MariaDB. Le versioni di MySQL Enterprise non consentono la replica dai server MariaDB, quindi questo è un percorso a senso unico.

Ecco alcune regole generali indicate da MariaDB.

• La replica da MySQL 5.5 a MariaDB 5.5+ dovrebbe funzionare. Vorrai che MariaDB sia la stessa versione o superiore del tuo server MySQL.
• Quando si utilizza un MariaDB 10.2+ come slave, potrebbe essere necessario impostare binlog_checksum su NONE.
• La replica da MySQL 5.6 senza GTID a MariaDB 10+ dovrebbe funzionare.
• La replica da MySQL 5.6 con GTID, binlog_rows_query_log_events ed eventi ignorabili funziona a partire da MariaDB 10.0.22 e MariaDB 10.1.8. In questo caso, MariaDB rimuoverà i GTID MySQL e altri eventi non necessari e aggiungerà invece i propri GTID.

Anche se non prevedi di utilizzare la replica nel processo di migrazione/cutover, averne uno è un buon generatore di fiducia è replicare il tuo server di produzione su una sandbox di test e poi esercitarti su di esso.

Ci auguriamo che questo post introduttivo del blog ti abbia aiutato a comprendere il processo di valutazione e implementazione di MySQL Enterprise Migration a MariaDB.