Eseguire la migrazione di MySQL in locale a Database di Azure per MySQL: Migrazione dei dati
SI APPLICA A:
Database di Azure per MySQL - Server singolo Database di Azure per MySQL - Server flessibile
Prerequisiti
Eseguire il backup del database
Come passaggio prudente prima dell'aggiornamento o della migrazione dei dati, esportare il database prima dell'aggiornamento usando MySQL Workbench o manualmente tramite il mysqldump comando .
Offline e online
Prima di selezionare uno strumento di migrazione, deve essere determinato se la migrazione deve essere online o offline.
Le migrazioni offline causano l'arresto del sistema durante l'esecuzione della migrazione. Questa opzione garantisce che non si verifichino transazioni e che lo stato dei dati sia esattamente quello previsto quando viene ripristinato in Azure.
Le migrazioni online esegue la migrazione dei dati quasi in tempo reale. Questa opzione è appropriata quando si verificano tempi di inattività ridotti per gli utenti o le applicazioni che usano il carico di lavoro dei dati. Il processo prevede la replica dei dati usando un metodo di replica,
binlogad esempio o simile.
Per la seconda guerra mondiale, l'ambiente ha alcuni requisiti di rete e sicurezza complessi che non consentono l'applicazione delle modifiche appropriate per la connettività in ingresso e in uscita nell'intervallo di tempo di migrazione di destinazione. Queste complessità e requisiti eliminano essenzialmente l'approccio online dalla considerazione.
Nota
Per altre informazioni sulla migrazione offline e online, vedere le sezioni Pianificazione e valutazione.
Deriva dei dati
Le strategie di migrazione offline hanno il potenziale per la deriva dei dati. La deriva dei dati si verifica quando i dati di origine appena modificati non vengono sincronizzati con i dati migrati. In questo caso, è necessaria un'esportazione completa o un'esportazione differenziale. È possibile attenuare questo problema arrestando tutto il traffico verso il database e quindi eseguendo l'esportazione. Se non è possibile arrestare tutto il traffico di modifica dei dati, è necessario tenere conto della deriva.
Determinare le modifiche può diventare complicato se le tabelle di database non hanno colonne come chiavi primarie basate su numeriche o un tipo di modifica e di creazione della data in ogni tabella di cui è necessario eseguire la migrazione.
Ad esempio, se è presente una chiave primaria basata su numeriche e la migrazione viene importata nell'ordinamento, è relativamente semplice determinare dove l'importazione è stata arrestata e riavviarla da tale posizione. Se non è presente alcuna chiave numerica, potrebbe essere possibile utilizzare la modifica e la creazione della data e di nuovo importare in modo ordinato in modo da poter riavviare la migrazione dall'ultima data visualizzata nella destinazione.
Consigli sulle prestazioni
Esportazione
Usare uno strumento di esportazione che può essere eseguito in modalità multithread, ad esempio mydumper
Quando si usa MySQL 8.0, usare le tabelle partizionate quando appropriato per aumentare la velocità delle esportazioni.
Import
Creare indici cluster e chiavi primarie dopo il caricamento dei dati. Caricare i dati in ordine di chiave primaria o altro se la chiave primaria è una colonna data (ad esempio, modificare la data o crearne una) in ordine ordinato.
Ritardare la creazione di indici secondari fino al caricamento dei dati. Creare tutti gli indici secondari dopo il caricamento.
Disabilitare i vincoli di chiave esterna prima del caricamento. La disabilitazione dei controlli della chiave esterna offre miglioramenti significativi delle prestazioni. Abilitare i vincoli e verificare i dati dopo il caricamento per garantire l'integrità referenziale.
Caricare i dati in parallelo. Evitare un eccessivo parallelismo che potrebbe causare conflitti di risorse e monitorare le risorse usando le metriche disponibili nel portale di Azure.
Eseguire la migrazione
Eseguire il backup del database
Creare e verificare la zona di destinazione di Azure
Configurare i parametri del server di origine
Configurare i parametri del server di destinazione
Esportare gli oggetti di database (schema, utenti e così via)
Esportare i dati
Importare gli oggetti di database
Importare i dati
Convalida
Reimpostare i parametri del server di destinazione
Eseguire la migrazione delle applicazioni
Passaggi comuni
Nonostante il percorso eseguito, è necessario eseguire i passaggi comuni:
Eseguire l'aggiornamento a una versione di Azure MySQL supportata
Oggetti di database di inventario
Esportare utenti e autorizzazioni
Eseguire la migrazione alla versione più recente di MySQL
Poiché il database wwi conference è in esecuzione 5.5, è necessario eseguire un aggiornamento. Il CIO ha chiesto di eseguire l'aggiornamento alla versione più recente di MySQL (attualmente 8.0).
Esistono due modi per eseguire l'aggiornamento alla versione 8.0:
Sul posto
Esportazione/Importazione
Quando si decide di eseguire un aggiornamento, è importante eseguire lo strumento di controllo dell'aggiornamento per determinare se sono presenti conflitti. Ad esempio, quando si esegue l'aggiornamento a MySQL Server 8.0, lo strumento verifica i conflitti seguenti:
Nomi di oggetti di database in conflitto con parole riservate in MySQL 8.0
Utilizzo del set di caratteri utf8mb3
Utilizzo degli attributi del tipo di lunghezza ZEROFILL/display
Nomi di tabella in conflitto con le tabelle nella versione 8.0
Utilizzo del tipo temporale
Nomi di vincoli di chiave esterna più lunghi di 64 caratteri
Se il controllo dell'aggiornamento non segnala problemi, è possibile eseguire un aggiornamento sul posto sostituendo i file binari MySQL. I database con problemi devono essere esportati e i problemi risolti.
Scenario WWI
Dopo aver eseguito correttamente la migrazione dell'istanza di MySQL alla versione 8.0, il team di migrazione wwi ha realizzato il percorso di migrazione Servizio Migrazione del database (DMS) originale non può più essere usato come strumento servizio Migrazione del database attualmente supporta solo 5.6 e 5.7. Servizio Migrazione del database richiede l'accesso alla rete. Il team di migrazione wwi non era pronto a gestire i problemi di rete complessi. Questi problemi ambientali hanno limitato la scelta dello strumento di migrazione a MySQL Workbench.
Oggetti di database
Come descritto nella sezione Piani di test, è necessario eseguire un inventario degli oggetti di database prima e dopo la migrazione per assicurarsi di aver eseguito la migrazione di tutti gli elementi.
Se si vuole eseguire una stored procedure per generare queste informazioni, è possibile usare un codice simile al seguente:
DELIMITER //
CREATE PROCEDURE `Migration_PerformInventory`(IN schemaName CHAR(64))
BEGIN
DECLARE finished INTEGER DEFAULT 0;
DECLARE tableName varchar(100) DEFAULT "";
#get all tables
DECLARE curTableNames
CURSOR FOR
SELECT TABLE_NAME FROM information_schema.tables where TABL
E_SCHEMA = schemaName;
-- declare NOT FOUND handler
DECLARE CONTINUE HANDLER
FOR NOT FOUND SET finished = 1;
DROP TABLE IF EXISTS MIG_INVENTORY;
CREATE TABLE MIG_INVENTORY
(
REPORT_TYPE VARCHAR(1000),
OBJECT_NAME VARCHAR(1000),
PARENT_OBJECT_NAME VARCHAR (1000),
OBJECT_TYPE VARCHAR(1000),
COUNT INT
)
ROW_FORMAT=DYNAMIC,
ENGINE='InnoDB';
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'TABLES', 'TABLES', COUNT(*)
FROM
information_schema.tables
where
TABLE_SCHEMA = schemaName;
#### Constraints
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'STATISTICS', 'STATISTICS', COUNT(*)
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'VIEWS', 'VIEWS', COUNT(*)
FROM
information_schema.VIEWS
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'PROCEDURES', 'PROCEDURES', COUNT(*)
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'EVENTS', 'EVENTS', COUNT(*)
FROM
information_schema.EVENTS
WHERE
EVENT_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USER DEFINED FUNCTIONS', 'USER DEFINED FUNCTIONS'
, COUNT(*)
FROM
mysql.func;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USERS', 'USERS', COUNT(*)
FROM
mysql.user
WHERE
user <> '' order by user;
OPEN curTableNames;
getTableName: LOOP
FETCH curTableNames INTO tableName;
IF finished = 1 THEN
LEAVE getTableName;
END IF;
SET @s = CONCAT('SELECT COUNT(*) into @TableCount FROM ', schemaName,
'.', tableName);
#SELECT @s;
PREPARE stmt FROM @s;
EXECUTE stmt;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'TABLECOUNT', tableName, 'TABLECOUNT', @TableCount;
DEALLOCATE PREPARE stmt;
END LOOP getTableName;
CLOSE curTableNames;
SELECT * FROM MIG_INVENTORY;
END //
DELIMITER ;
CALL Migration_PerformInventory('reg_app');
- La chiamata a questa procedura nel database di origine rivela quanto segue (output troncato):
- Il risultato della routine del database di destinazione dovrebbe essere simile all'immagine seguente dopo aver completato la migrazione. Si noti che nel database non sono presenti funzioni. Le funzioni sono state eliminate prima della migrazione.
Utenti e autorizzazioni
Una migrazione corretta richiede la migrazione di utenti e autorizzazioni associati all'ambiente di destinazione.
Esportare tutti gli utenti e le relative concessioni usando lo script di PowerShell seguente:
$username = "yourusername";
$password = "yourpassword";
mysql -u$username -p$password --skip-column-names -A -e"SELECT CONCAT('SHOW G
RANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" > Show
Grants.sql;
$lines = get-content "ShowGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password --skip-column-names -A -e"$line" >> AllGrants.sql
}
Creare un nuovo script di PowerShell usando PowerShell ISE (vedere il documento di installazione)
Impostare il nome utente su root e la password sulla password dell'utente radice
È quindi possibile eseguire lo AllGrants.sql script destinato al nuovo Database di Azure per MySQL:
$username = "yourusername";
$password = "yourpassword";
$server = "serverDNSname";
$lines = get-content "AllGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password -h$server --ssl-ca=c:\temp\BaltimoreCyberTrus
tRoot.crt.cer --skip-column-names -A -e"$line"
}
È anche possibile creare utenti in Database di Azure per MySQL usando PowerShell: /en-us/azure/mysql/howto-create-users
Eseguire la migrazione
Con i componenti di migrazione di base, è ora possibile procedere con la migrazione dei dati. In precedenza erano stati introdotti diversi strumenti e metodi. Per WWI, utilizzeranno il percorso di MySQL Workbench per esportare i dati e quindi importarli in Database di Azure per MySQL.
Elenco di controllo per la migrazione dei dati
Comprendere la complessità dell'ambiente e se un approccio online è fattibile.
Tenere conto della deriva dei dati. L'arresto del servizio di database può eliminare potenziali deviazioni dei dati.
Configurare i parametri di origine per l'esportazione rapida.
Configurare i parametri di destinazione per l'importazione rapida.
Testare tutte le migrazioni con una versione di origine diversa rispetto alla destinazione.
Eseguire la migrazione di oggetti non basati su dati, ad esempio nomi utente e privilegi.
Assicurarsi che tutte le attività siano documentate e controllate durante l'esecuzione della migrazione.