Configura l'origine

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

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, 8.4
• MySQL autogestito (on-premise o su qualsiasi VM cloud di cui hai il controllo totale) 5.5, 5.6, 5.7, 8.0, 8.4
• Cloud SQL per MySQL 5.6, 5.7, 8.0, 8.4
• Amazon Aurora 5.6, 5.7, 8.0, 8.4
• Database di Microsoft Azure per MySQL 5.7, 8.0, 8.4

Per le origini MySQL 8.0, Database Migration Service supporta anche le versioni secondarie seguenti: 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, 8.0.41, 8.0.42, 8.0.43.

Per configurare un database di origine, completa i seguenti passaggi:

1. 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 intervallo di indirizzi IP 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.
2. Prima di eseguire la migrazione dei dati dal database di origine al database di destinazione, assicurati di interrompere tutte le operazioni di scrittura DDL (Data Definition Language) 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.
3. Assicurati che il database di origine non contenga metadati definiti da utenti con la clausola DEFINER. Consulta Creare ed eseguire un job di migrazione MySQL contenente metadati con una clausola DEFINER.
4. Se il database di origine contiene oggetti che fanno riferimento tabelle negli schemi di sistema mysql, performance_schema, information_schema, ndbinfo, o sys assicurati che anche i database di replica contengano queste tabelne dello schema di sistema.

   Se i database di replica non hanno queste tabelle, il job di migrazione potrebbe non riuscire con l'errore Unknown table in system schema .

5. Devi impostare l'opzione server-id su un valore pari o superiore a 1. Per saperne di più, consulta Opzioni e variabili per la replica e il logging binario.
6. Configura il logging dell'ID transazione globale (GTID) impostando il GTID_MODE su ON o OFF. Il valore GTID_MODE di ON_PERMISSIVE non è supportato.

   Il valore da utilizzare dipende dai requisiti di migrazione:

   • Se esegui la migrazione a un'istanza di destinazione esistente con le repliche di lettura abilitate, imposta GTID_MODE su ON.
   • Se utilizzi un dump manuale per eseguire la migrazione dei dati, imposta GTID_MODE su ON.
   Per saperne di più su GTID_MODE, consulta Variabile di sistema ID transazione globale.

7. Devi configurare l'account utente utilizzato per connetterti al database di origine in modo che accetti connessioni di qualsiasi provenienza (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.

   Tipo 1

   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: assicurati che l'account di migrazione non abbia il privilegio BACKUP_ADMIN.

   Per saperne di più sui privilegi, consulta Privilegi forniti da MySQL. Per saperne di più sugli account utente, consulta Formato dell'account utente MySQL.

   Tipo 2

   L'account utente che configuri deve avere i seguenti privilegi:

   • REPLICATION SLAVE
   • EXECUTE

   Per saperne di più sui privilegi, consulta Privilegi forniti da MySQL. Per saperne di più sugli account utente, consulta Formato dell'account utente MySQL.

   Tipo 3

   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: assicurati che l'account di migrazione non abbia il privilegio BACKUP_ADMIN.

   Per saperne di più sui privilegi, consulta Privilegi forniti da MySQL. Per saperne di più sugli account utente, consulta Formato dell'account utente MySQL.

   Tipo 4

   Non sono richiesti privilegi.

   Per saperne di più sui privilegi, consulta Privilegi forniti da MySQL. Per saperne di più sugli account utente, consulta Formato dell'account utente MySQL.

8. Prima di configurare i log binari, assicurati di:
   • Abilitare i log binari nel database di origine.
   • Utilizzare il logging binario basato su righe.
   • Conservare i log binari per un periodo di tempo sufficiente a supportare la migrazione del database. In genere, una settimana è sufficiente.

   Per configurare i log binari, espandi la sezione relativa all'origine:

   Cloud SQL per MySQL

   In Cloud SQL per MySQL, il logging binario viene abilitato automaticamente quando utilizzi il recupero point-in-time (PITR). Puoi configurare il formato dei log e il periodo di conservazione con i flag di sistema disponibili in Cloud SQL:

   1. Abilita il PITR sull'istanza per abilitare il logging binario. Consulta Recupero point-in-time (PITR) nella documentazione di Cloud SQL.
   2. Utilizza i flag di Cloud SQL per modificare la configurazione del logging. Per maggiori dettagli, consulta Configurare i flag di database nella documentazione di Cloud SQL.
      1. Per il formato dei log, non è necessario modificare alcuna impostazione. Cloud SQL per MySQL imposta automaticamente il flag binlog_format su ROW.
      2. Per la data di scadenza dei log, utilizza uno dei seguenti flag:
         • MySQL 5.6 - 5.7: expire_logs_days
         • MySQL 8.0 e versioni successive: expire_logs_days, binlog_expire_logs_seconds

   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 nel database di Microsoft Azure per MySQL. Non è necessario abilitarlo. Per maggiori informazioni, consulta la documentazione di Microsoft.

   Configura i seguenti parametri obbligatori:

   1. Imposta binlog_expire_logs_seconds su un periodo di tempo sufficientemente lungo da supportare la migrazione del database.

      Per saperne di più, consulta Configurare i parametri del server nel database di Azure per PostgreSQL e il binlog_expire_logs_seconds parametro nella documentazione di Microsoft.

   2. Riavvia il server in modo che le modifiche effettuate vengano applicate.

   Amazon RDS

   Per Amazon RDS, imposta la configurazione basata su righe nel gruppo di parametri configurando il binlog retention hours parametro. Questo parametro viene utilizzato per specificare per quante ore Amazon RDS deve conservare i file di log binari.

   Per impostare il periodo di conservazione dei 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);

   Il valore massimo che puoi impostare per questo parametro è 168 ore (o 7 giorni).

   Amazon Aurora

   Per Amazon Aurora:

   1. Abilita il logging binario per il database MySQL.
   2. Imposta il periodo di conservazione dei log binari:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      Stai inserendo questo comando perché vuoi garantire una replica corretta configurando il sistema in modo da conservare i log binari per almeno 7 giorni (o 168 ore).
   3. Riavvia il server in modo che le modifiche effettuate vengano applicate.
9. Tutte le tabelle (tranne quelle nei database di sistema) utilizzano il motore di archiviazione InnoDB.

   Per saperne di più su InnoDB, consulta Il motore di archiviazione InnoDB. Per saperne di più sulla conversione a InnoDB, consulta Convertire le tabelle da MyISAM a InnoDB.

10. La password dell'account utente utilizzato per connetterti al database di origine non deve superare i 32 caratteri. Si tratta di un problema specifico della replica MySQL.

    Per saperne di più sulla limitazione della lunghezza della password utente MySQL, consulta Bug MySQL n. 43439.

11. Solo per le origini del database di Microsoft Azure per MySQL: controlla il valore dell'impostazione require_secure_transport.

    Per impostazione predefinita, i database di Microsoft Azure richiedono la crittografia SSL/TLS per tutte le connessioni in entrata. A seconda del valore di require_secure_transport, utilizza una delle seguenti impostazioni di crittografia quando crei il profilo di connessione di origine:

    • Se require_secure_transport è impostato su on, seleziona Basic, TLS o mTLS.
    • Se require_secure_transport è impostato su off, seleziona Nessuno.