MariaDB
 sql >> Database >  >> RDS >> MariaDB

Migrazione del database di Azure per MySQL/MariaDB a un server locale

Le migrazioni del database possono imporre enormi sfide se si considera come iniziare, quali strumenti utilizzare e come ottenere una migrazione completa del database con successo. In precedenza, abbiamo elencato i migliori open source che puoi utilizzare durante la migrazione per MySQL o MariaDB. In questo blog ti mostreremo come migrare i dati dal database di Microsoft Azure per MySQL o MariaDB.

Microsoft Azure è ora noto per essere un contendente contro gli altri due giganti della tecnologia cloud:AWS e Google Cloud. È specializzato in più dei suoi prodotti Microsoft, in particolare nel loro database proprietario MSSQL coltivato in casa. Ma non solo, ha anche open source come uno dei loro database di servizi completamente gestiti da offrire pubblicamente. Tra i suoi database supportati ci sono MySQL e MariaDB.

L'uscita dal database di Azure per MySQL/MariaDB può essere noioso, ma dipende dal tipo di architettura e dal tipo di set di dati che hai ospitato in Azure come provider di servizi cloud corrente. Con gli strumenti giusti, può essere realizzabile e può essere eseguita una migrazione completa.

Ci concentreremo sugli strumenti che possiamo utilizzare per la migrazione dei dati su MySQL o MariaDB. Per questo blog, sto usando RHEL/CentOS per installare i pacchetti richiesti. Andiamo oltre e definiamo i passaggi e le procedure su come farlo.

Migrazione dal database di Azure per MySQL o MariaDB

Un approccio tipico alla migrazione dei dati dal database di Azure a un server locale consiste nell'eseguire un backup usando una copia logica. Questa operazione può essere eseguita utilizzando soluzioni di utilità di backup compatibili con il database di Azure per MySQL o MariaDB, che è un servizio completamente gestito. I servizi di database completamente gestiti non offrono accessi SSH, quindi la copia fisica dei backup non è un'opzione.

Prima di eseguire la migrazione o il dump del database esistente da Azure, è necessario prendere nota delle seguenti considerazioni.

Casi d'uso comuni per il dump e il ripristino in locale

I casi d'uso più comuni sono:

  • L'uso del backup logico (come mysqldump, mysqlpump o mydumper/myloader) e il ripristino è l'unica opzione. Database di Azure per MySQL o MariaDB non supporta l'accesso fisico all'archiviazione fisica poiché si tratta di un servizio di database completamente gestito.
  • Supporta solo i motori di archiviazione InnoDB e Memory. Migrazione da motori di archiviazione alternativi a InnoDB. Database di Azure per MySQL o MariaDB supporta solo il motore di archiviazione InnoDB e pertanto non supporta motori di archiviazione alternativi. Se le tabelle sono configurate con altri motori di archiviazione, convertile nel formato del motore InnoDB prima della migrazione al database di Azure per MySQL.
  • Ad esempio, se hai un WordPress o un'app Web che usa le tabelle MyISAM, converti prima tali tabelle eseguendo la migrazione nel formato InnoDB prima di ripristinarle nel database di Azure per MySQL. Utilizzare la clausola ENGINE=InnoDB per impostare il motore utilizzato durante la creazione di una nuova tabella, quindi trasferire i dati nella tabella compatibile prima del ripristino.
  • Se il database di Azure di origine si trova in una versione specifica, anche il server locale di destinazione è la stessa versione del database di Azure di origine.

Quindi, con queste limitazioni, ti aspetti solo che i tuoi dati da Azure debbano essere il motore di archiviazione InnoDB o la memoria, se presente nel tuo set di dati.

Considerazioni sulle prestazioni per l'esecuzione del backup logico dal database di Azure

L'unico modo per eseguire un backup logico con Azure è usare mysqldump o mysqlpump. Per ottimizzare le prestazioni quando si esegue un dump utilizzando questi strumenti, prendere nota di queste considerazioni durante il dump di database di grandi dimensioni:

  • Utilizzare l'opzione exclude-triggers in mysqldump durante il dump dei database. Escludi i trigger dai file di dump per evitare che i comandi di trigger vengano attivati ​​durante il ripristino dei dati.
  • Utilizzare l'opzione di transazione singola per impostare la modalità di isolamento della transazione su REPEATABLE READ e inviare un'istruzione SQL START TRANSACTION al server prima di eseguire il dump dei dati. Il dump di molte tabelle all'interno di una singola transazione provoca il consumo di spazio di archiviazione aggiuntivo durante il ripristino. L'opzione transazione singola e l'opzione lock-tables si escludono a vicenda perché LOCK TABLES determina il commit implicito di tutte le transazioni in sospeso. Per scaricare tabelle di grandi dimensioni, combina l'opzione transazione singola con l'opzione rapida.
  • Utilizza la sintassi a più righe con inserimento esteso che include diversi VALUE elenchi. Ciò si traduce in un file di dump più piccolo e velocizza gli inserimenti quando il file viene ricaricato.
  • Utilizzare l'opzione order-by-primary in mysqldump durante il dump dei database, in modo che i dati vengano inseriti nell'ordine della chiave primaria.
  • Utilizzare l'opzione disable-keys in mysqldump durante il dump dei dati, per disabilitare i vincoli di chiave esterna prima del caricamento. La disabilitazione dei controlli della chiave esterna fornisce miglioramenti delle prestazioni. Abilita i vincoli e verifica i dati dopo il caricamento per garantire l'integrità referenziale.
  • Usa tabelle partizionate quando appropriato.
  • Carica i dati in parallelo. Evita un parallelismo eccessivo che ti farebbe raggiungere un limite di risorse e monitora le risorse usando le metriche disponibili nel portale di Azure.
  • Utilizzare l'opzione defer-table-indexes in mysqlpump durante il dump dei database, in modo che la creazione dell'indice avvenga dopo il caricamento dei dati della tabella.
  • Utilizzare l'opzione skip-definer in mysqlpump per omettere il definer e le clausole SQL SECURITY dalle istruzioni create per le viste e le procedure memorizzate. Quando si ricarica il file di dump, vengono creati oggetti che utilizzano i valori DEFINER e SQL SECURITY predefiniti.
  • Copia i file di backup in un BLOB/archivio di Azure ed esegui il ripristino da lì, che dovrebbe essere molto più veloce rispetto all'esecuzione del ripristino su Internet.

Non supportato

I seguenti non sono supportati:

  • Ruolo DBA:limitato. In alternativa, puoi utilizzare l'utente amministratore (creato durante la creazione di un nuovo server), che ti consente di eseguire la maggior parte delle istruzioni DDL e DML.
  • privilegio SUPER:allo stesso modo, il privilegio SUPER è limitato.
  • DEFINER:richiede super privilegi per la creazione ed è limitato. Se si importano dati utilizzando un backup, rimuovere i comandi CREATE DEFINER manualmente o utilizzando il comando --skip-definer durante l'esecuzione di mysqldump.
  • Database di sistema:il database di sistema mysql è di sola lettura e viene utilizzato per supportare varie funzionalità PaaS. Non puoi apportare modifiche al database di sistema mysql.
  • SELECT ... INTO OUTFILE:non supportato nel servizio.

Utilizzo di mysqldump

L'uso di mysqldump deve essere installato nel nodo del database di destinazione situato in locale. Deve essere preparato come una replica del nodo del database di Azure in modo che tutte le transazioni successive vengano replicate nel nodo. Per fare ciò, segui i passaggi seguenti.

Installa mysqldump

  1. Prepara il repository.

# Per MySQL

$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

# Per MariaDB

$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

  1. Installa il pacchetto mysql-client

# Per MySQL

$ yum install -y mysql-community-client.x86_64

# Per MariaDB

$ yum install -y MariaDB-client

  1. Crea un dump dei dati utilizzando mysqldump eseguendolo all'interno del nodo di destinazione.

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

  1. Installa il server MySQL/MariaDB nel nodo del database di destinazione

# Per MySQL

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# Per MariaDB

$ yum install MariaDB-server.x86_64

  1. Configura l'istanza del server MySQL/MariaDB (my.cnf, autorizzazioni file, directory) e avvia il server 

# Configurazione di my.cnf (usando la distribuzione my.cnf utilizzata da ClusterControl)

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF

innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path=ibdata1:100M:autoextend

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=256M

innodb_log_buffer_size=32M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

innodb_flush_method=O_DIRECT

innodb_rollback_on_timeout=ON

innodb_autoinc_lock_mode=2

innodb_stats_on_metadata=0

default_storage_engine=innodb

server_id=1126

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=OFF

report_host=192.168.10.226

key_buffer_size=24M

tmp_table_size=64M

max_heap_table_size=64M

max_allowed_packet=512M

skip_name_resolve=true

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type=0

query_cache_size=0

table_open_cache=1024

lower_case_table_names=0

performance_schema=OFF

performance-schema-max-mutex-classes=0

performance-schema-max-mutex-instances=0



[MYSQL]

socket=/var/lib/mysql/mysql.sock



[client]

socket=/var/lib/mysql/mysql.sock



[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet=512M

## Reimposta la directory dei dati e reinstalla i file di sistema del database

$ rm -rf /var/lib/mysql/*

## Crea le directory di registro

$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## Per MySQL

$ mysqld --initialize

## Per MariaDB

$ mysql_install_db

  1. Avvia il server MySQL/MariaDB

## Per MySQL

$ systemctl start mysqld

## Per MariaDB

$ systemctl start mariadb

  1. Carica il dump dei dati prelevato dal database di Azure nel nodo del database di destinazione in locale

$ mysql --show-warnings < backups/dump.sql

  1. Crea l'utente di replica dal nodo di origine del database di Azure

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Assicurati di modificare l'indirizzo IP dell'indirizzo IP del tuo nodo di destinazione come client da cui connetterti.

  1. Configura il server MySQL/MariaDB come replica/slave del nodo di origine del database di Azure

## Innanzitutto, cerchiamo o individuiamo il comando CHANGE MASTER

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

## Eseguire l'istruzione CHANGE MASTER ma aggiungere l'utente/password di replica e il nome host come segue,

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## In alcuni casi, potresti dover ignorare lo schema mysql. Esegui la seguente istruzione:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Quindi avvia i thread slave

START SLAVE;

## Controlla lo stato dello slave come va

SHOW SLAVE STATUS \G

Ora che finalmente siamo stati in grado di replicare dal database di Azure per MySQL/MariaDB come origine della replica in locale.

Utilizzo di mydumper

Il database di Azure per MySQL o MariaDB suggerisce infatti che l'uso di mydumper specialmente per backup di grandi dimensioni come 1 TB può essere l'opzione alternativa. Offre parallelismo e velocità quando si esegue un dump o una copia di backup del set di dati da un nodo di database di Azure di origine.

 Segui i passaggi seguenti dall'installazione di mydumper al caricamento sul server locale di destinazione.

  1. Installa il file binario. I binari possono essere trovati qui https://github.com/maxbube/mydumper/releases.

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm

  1. Esegui il backup dal nodo di origine del database di Azure. Ad esempio,

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Come puoi vedere, esiste una limitazione nell'esecuzione del backup da un database gestito come Azure. Potresti notare,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Questo perché SUPER PRIVILEGE non è supportato o limitato. Idealmente, l'opzione migliore per eseguire questa operazione è eseguire il backup da una replica del database di Azure. Ne parleremo più avanti.

Ora, a questo punto, mydumper eseguirà un backup dei file sotto forma di file *.gz

  1. Caricalo sul server locale di destinazione

$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3

** Message: 8 threads created

** Message: Creating database `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

  1. Imposta il nodo di destinazione come slave/replica. MyDumper includerà un file chiamato metadati che consiste in coordinate di registro binario tra cui posizioni GTID, ad esempio:

$ cat metadata

Started dump at: 2020-10-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## Quindi esegui un change master dalla replica o dal nodo del database MySQL/MariaDB di destinazione di destinazione

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Avvia lo slave

START SLAVE;

A questo punto è stata eseguita la replica da un'istanza di database di Azure che esegue MySQL/MariaDB. Una volta che l'applicazione è pronta per l'allontanamento dall'istanza del database di Azure, configura l'endpoint per il server locale e tutte le transazioni rimanenti dall'istanza di Azure verranno replicate nella tua istanza in locale senza che i dati vengano persi per il server on-premise server prem.

Limitazioni di gestione con database gestiti per MySQL o MariaDB in Azure

La gestione delle limitazioni, specialmente quando si esegue un dump di backup del set di dati, deve essere accurata al 100% dal momento in cui è stato eseguito il dump di backup. Naturalmente, questa è una migrazione ideale per il tuo locale. Per far fronte a questo problema, la migliore configurazione dell'architettura consiste nel disporre di una topologia di replica presente nel database di Azure.

Una volta che lo hai e pronto per la migrazione, mysqldump/mysqlpump o mydumper deve usare la replica del database di Azure come origine. All'interno della replica del database di Azure, assicurarsi che SQL_THREAD sia interrotto in modo da poter eseguire lo snapshot o registrare il MASTER_LOG_FILE e EXEC_MASTER_LOG_POS corretti dal risultato di SHOW SLAVE STATUS.

Ovviamente, una volta eseguito il backup, non dimenticare di avviare la replica del database di Azure per riavviare i thread di replica.

Verifica discrepanze nei dati

Una volta caricati o scaricati i dati sul server locale che funge da replica dall'istanza del database di Azure, è necessario ricontrollarlo eseguendo calcoli di checksum per determinare la distanza dei dati rispetto al database di Azure di origine. Ti consigliamo di utilizzare lo strumento pt-table-checksum di Percona Toolkit, ma puoi crearne uno tuo utilizzando strumenti di checksum come md5 o sha256, ma questo richiede tempo. Inoltre, l'utilizzo di pt-upgrade da Percona Toolkit può aiutare anche dopo che la migrazione dei dati utilizzando questo approccio di replica è stata completata.

Conclusione

Le limitazioni dei privilegi e dei tipi non supportati dal database di Azure possono essere impegnative, ma con il flusso e l'architettura appropriati non è impossibile migrare da un database completamente gestito in locale. Tutto quello che devi fare è preparare i passaggi richiesti, configurare la topologia richiesta dall'origine del database di Azure, quindi avviare la migrazione dall'esecuzione dei backup, alla replica e alla migrazione totale al tuo locale.