Panoramica
Database Migration Service supporta migrazioni una tantum e continue dai database di origine ai database Cloud SQL di destinazione.
I database di origine supportati per MySQL includono:
- Amazon RDS 5.6, 5.7, 8.0
- MySQL autogestito (on-premise o su qualsiasi VM cloud sotto il tuo controllo totale) 5.5, 5.6, 5.7, 8.0
- Cloud SQL per MySQL 5.6, 5.7, 8.0, 8.4
- Amazon Aurora 5.6, 5.7, 8.0
- Database di Microsoft Azure per MySQL 5.7, 8.0
Per le origini MySQL 8.0, Database Migration Service supporta anche le seguenti versioni secondarie: 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40.
Per configurare un database di origine:
- Per le origini Cloud SQL: se esegui la migrazione da un'istanza Cloud SQL che utilizza una connessione IP privato a un'istanza Cloud SQL che utilizza un indirizzo non RFC 1918, aggiungi l'intervallo non RFC 1918 alla configurazione di rete dell'istanza Cloud SQL di origine. Consulta Configurare le reti autorizzate nella documentazione di Cloud SQL.
- Prima di eseguire la migrazione dei dati dal database di origine a quello di destinazione, assicurati di interrompere tutte le operazioni di scrittura in Data Definition Language (DDL) durante la fase di dump completo. Puoi utilizzare uno script per verificare che le operazioni DDL siano state interrotte. Una volta che la migrazione è nella fase CDC, puoi riprendere le operazioni DDL.
- Assicurati che il database di origine non contenga metadati definiti dagli utenti con la clausola DEFINER. Consulta Crea ed esegui un job di migrazione MySQL contenente metadati con una clausola DEFINER.
- Se il database di origine contiene oggetti che fanno riferimento alle tabelle degli schemi di sistema
mysql
,performance_schema
,information_schema
,ndbinfo
osys
, assicurati che i database di replica contengano anche queste tabelle dello schema di sistema.Se i database delle repliche non hanno queste tabelle, il job di migrazione potrebbe non riuscire con l' errore
Unknown table in system schema
. - Devi impostare l'opzione server-id su un valore pari o superiore a 1. Per ulteriori informazioni, consulta Opzioni e variabili per la replica e il logging binario.
- Configura la registrazione dell'ID transazione globale (GTID) impostando
GTID_MODE
suON
oOFF
. Il valoreGTID_MODE
diON_PERMISSIVE
non è supportato.Il valore da utilizzare dipende dai requisiti di migrazione:
- Se
esegui la migrazione a un'istanza di destinazione esistente in cui sono attivate le
repliche di lettura, imposta
GTID_MODE
suON
. - Se utilizzi un dump manuale per eseguire la migrazione dei dati, imposta
GTID_MODE
suON
.
GTID_MODE
, consulta Variabile di sistema ID transazione globale. - Se
esegui la migrazione a un'istanza di destinazione esistente in cui sono attivate le
repliche di lettura, imposta
-
Devi configurare l'account utente utilizzato per connetterti al database di origine in modo che accetti connessioni da qualsiasi posizione (host =
%
). L'accesso può essere limitato a questo utente in un passaggio successivo.Per limitare la possibilità che vengano compromessi altri aspetti del database, ti consigliamo di creare un account separato per questo scopo.
Esistono quattro tipi di combinazioni di migrazioni e dump:
- Tipo 1: migrazione continua e dump gestito
- Tipo 2: migrazione continua e dump manuale
- Tipo 3: migrazione una tantum e dump gestito
- Tipo 4: migrazione una tantum e dump manuale
I privilegi per ogni tipo di combinazione di migrazione e dump sono elencati nelle schede di seguito.
L'account utente che configuri deve avere i seguenti privilegi:
REPLICATION SLAVE
EXECUTE
SELECT
SHOW VIEW
REPLICATION CLIENT
RELOAD
TRIGGER
- (Solo per la migrazione da Amazon RDS e Amazon Aurora)
LOCK TABLES
MySQL versione 8.0 o successive: per un rendimento ottimale, assicurati di non concedere il privilegio
BACKUP_ADMIN
a questo account.L'account utente che configuri deve avere i seguenti privilegi:
REPLICATION SLAVE
EXECUTE
L'account utente che configuri deve avere i seguenti privilegi:
SELECT
SHOW VIEW
TRIGGER
- (Solo per la migrazione da Amazon RDS e Amazon Aurora)
LOCK TABLES
- (Solo per la migrazione da origini con l'impostazione
GTID_MODE = ON
)RELOAD
MySQL versione 8.0 o successive: per un rendimento ottimale, assicurati di non concedere il privilegio
BACKUP_ADMIN
a questo account.Non sono richiesti privilegi.
- Prima di configurare i log binari, assicurati di:
- Attiva i log binari nel database di origine.
- Utilizza il logging binario basato su riga.
- Conserva i log binari per un periodo di tempo sufficientemente lungo da supportare la migrazione del database. In genere, una settimana è sufficiente.
Per configurare i log binari, espandi la sezione relativa all'origine:
MySQL self-hosted
A seconda della versione di MySQL, specifica un periodo di tempo sufficiente per la replica:
- MySQL 5.5 - 5.7:
expire_logs_days
- MySQL 8.0:
expire_logs_days
,binlog_expire_logs_seconds
Database di Microsoft Azure per MySQL
Il logging binario è abilitato per impostazione predefinita in Microsoft Azure Database per MySQL. Non è necessario attivarla. Per ulteriori informazioni, consulta la documentazione di Microsoft.
Configura i seguenti parametri obbligatori:
Imposta
binlog_expire_logs_seconds
su un periodo sufficientemente lungo per supportare la migrazione del database.Per saperne di più, consulta Configurare i parametri del server in Azure Database for PostgreSQL e il parametro
binlog_expire_logs_seconds
nella documentazione di Microsoft.- Riavvia il server in modo che le modifiche apportate vengano applicate.
Amazon RDS
Per Amazon RDS, imposti la configurazione basata su riga nel gruppo di parametri configurando il parametro
binlog retention hours
. Questo parametro viene utilizzato per specificare quante ore Amazon RDS deve conservare i file di log binari.Per impostare il periodo di conservazione per i log binari in Amazon RDS, utilizza la stored procedure
mysql.rds_set_configuration
e specifica un periodo di tempo sufficiente per la replica. Ad esempio:call mysql.rds_set_configuration('binlog retention hours',168);
Amazon Aurora
Per Amazon Aurora:
- Abilita il logging binario per il tuo database MySQL.
- Imposta il periodo di conservazione dei log binari:
mysql> call mysql.rds_set_configuration('binlog retention hours', 168);
- Riavvia il server in modo che le modifiche apportate vengano applicate.
- Tutte le tabelle (tranne quelle nei database di sistema) utilizzano il motore di archiviazione InnoDB.
- La password dell'account utente utilizzato per la connessione al database di origine non deve superare i 32 caratteri. Si tratta di un problema specifico della replica MySQL.
Solo per le origini Microsoft Azure Database for MySQL: controlla il valore dell'impostazione
require_secure_transport
.Per impostazione predefinita, i database Microsoft Azure richiedono la crittografia SSL/TLS per tutte le connessioni in entrata. A seconda del valore
require_secure_transport
, utilizza una delle seguenti impostazioni di crittografia quando crei il profilo di connessione origine:- Se
require_secure_transport
è impostato suon
, seleziona Di base, TLS o mTLS. - Se
require_secure_transport
è impostato suoff
, seleziona Nessuna.
- Se