Esistono diversi metodi per eseguire una migrazione a MySQL su Cloud SQL. La strategia di migrazione per una determinata origine dipende da diversi fattori, tra cui le dimensioni del database, le aspettative relative al tempo di inattività e l'esperienza dei tecnici che eseguono la migrazione. Passiamo in rassegna alcune delle strategie di migrazione più comuni.

Se stai eseguendo la migrazione di un piccolo database di pochi gigabyte o che contiene dati statici, l'approccio più semplice è eseguire un dump del database utilizzando l'utilità mysqldump. Carica il file di dump in Cloud Storage e importalo in un'istanza di Cloud SQL seguendo le istruzioni riportate nell'articolo su esportazione e importazione mediante file di dump SQL.

Poiché i file di dump contengono istruzioni SQL logiche, uno dei vantaggi di questo approccio è che è possibile modificare i file di dump prima di caricarli in Cloud Storage. Tuttavia, considerate determinate limitazioni di Cloud SQL, evita di includere nel file di dump elementi che potrebbero provocare errori in un'importazione, come indicato nelle best practice per l'importazione e l'esportazione di dati.

Quando esegui la migrazione di molte istanze di MySQL o per migrazioni di dimensioni maggiori, è preferibile utilizzare Database Migration Service (DMS). Si tratta di un servizio che fornisce diversi percorsi di migrazione, tra cui i percorsi per le migrazioni a MySQL sia omogenee che eterogenee, nonché il supporto di SQL Server e PostgreSQL come destinazioni della migrazione.

Per la maggior parte delle migrazioni di database di medie e grandi dimensioni l'utilizzo di DMS dovrebbe essere sufficiente. Le situazioni in cui DMS potrebbe non essere appropriato includono database molto grandi (ad esempio di diversi TB) o se i tuoi tecnici MySQL hanno competenze relative alle repliche e preferiscono un controllo più granulare del processo di migrazione utilizzando la replica MySQL nativa.

Se ridurre al minimo il tempo di inattività è una priorità durante la migrazione e se nel tuo team ci sono tecnici MySQL esperti, la scelta di replicare da un'origine esterna utilizzando una replica basata su log binari nativi è un'opzione. Questo metodo utilizza l'importazione di uno snapshot di base del tuo database usando un metodo come un'importazione in Cloud Storage.

Quindi, configurerai la replica di MySQL dall'istanza di origine all'istanza di Cloud SQL di destinazione, utilizzando un insieme di stored procedure create in precedenza già disponibili nell'istanza di Cloud SQL. Le istruzioni complete sono disponibili nell'articolo Utilizzo di un'importazione personalizzata per configurare la replica da database esterni di grandi dimensioni.

Un dettaglio chiave quando si utilizza la replica basata su log binario per la migrazione è che i log binari presenti sull'istanza di origine rimangono disponibili finché non sono più necessari all'istanza Cloud SQL di destinazione. Quando esegui MySQL on-premise o gestito autonomamente, parametri come expire_logs_days possono essere configurati per controllare l'eliminazione definitiva dei log binari. Tuttavia, altri servizi cloud gestiti dal fornitore hanno le proprie restrizioni sulla conservazione dei log binari.

Ad esempio, Amazon Relational Database Service (RDS) consente di configurare la conservazione dei log binari utilizzando il nome di una stored procedure mysql.rds_set_configuration. Questa consente di conservare i dati per un massimo di sette giorni. Nella maggior parte dei casi, sette giorni sono sufficienti per la maggior parte delle migrazioni di piccole e medie dimensioni da RDS a Cloud SQL. In questi casi, gli utenti possono sfruttare un processo ben documentato che prevede la creazione di una replica RDS gestita. Successivamente possono eseguire un'operazione che "interrompe" la replica, ad esempio rendere la replica scrivibile ed eliminare una riga o inserire una sorta di transazione "avvelenata" sul database primario che raggiunge il log binario e interrompe la replica. L'automazione di RDS non eliminerà definitivamente i log binari finché la replica ne ha bisogno (anche se sembra che ci sia un limite complessivo di 30 giorni prima che RDS "termini" un flusso di replica non funzionante).

Un'altra soluzione consiste nell'utilizzare il client mysqlbinlog per scaricare i log binari su un'altra istanza di MySQL intermedia per evitare l'eliminazione prematura dei log binari. Ad esempio, in RDS è presente una stored procedure denominata mysql.rds_set_configuration che consente di impostare un periodo di conservazione in ore per assicurare che i log binari rimangano sull'host per un periodo sufficiente per il download. In questo caso, non è necessario configurare un'istanza di MySQL come intermediaria perché qualsiasi server, ad esempio "Binlog Server", simile a un'istanza MySQL, è a disposizione per archiviare e inoltrare log binari.

MySQL è unico tra i sistemi di database relazionali più diffusi in quanto supporta più motori di archiviazione modulari. Originariamente MySQL supportava un singolo motore di archiviazione noto come MyISAM e, fino a MySQL 8.0, la maggior parte delle tabelle di sistema utilizzava questo motore di archiviazione. Tuttavia, MyISAM non supportava le transazioni e non era sicuro in caso di un arresto improvviso del sistema o di un arresto anomalo del database.

Da allora, InnoDB è diventato il motore di archiviazione effettivo per la maggior parte delle tabelle utente di MySQL, grazie all'architettura sicura in caso di arresti anomali e al supporto per le transazioni. Tuttavia, ci sono altri motori di archiviazione comunemente utilizzati dalla community MySQL, sia on-premise che in altri provider cloud, tra cui:

• ARCHIVE: memorizza i dati in un formato altamente compresso a scopo di archiviazione
• CSV: archivia i dati in un formato separato da virgole (CSV) utilizzato per il logging delle tabelle, per il log generale e per quello delle query lente.
• MEMORY: archivia le tabelle in memoria

Nel caso di Cloud SQL è necessario un motore di archiviazione che sia transazionale e sicuro in caso di arresti anomali per supportare funzionalità a valore aggiunto come la replica e il recupero point-in-time. Pertanto, tutte le tabelle utente di cui viene eseguita la migrazione a Cloud SQL devono utilizzare il motore di archiviazione InnoDB o essere convertite in InnoDB durante il processo di migrazione.

Ciò è particolarmente importante se esegui la replica nativa di MySQL da una sorgente esterna a Cloud SQL. Sebbene Cloud SQL non consenta agli utenti di creare una tabella MyISAM direttamente su un'istanza Cloud SQL utilizzando comandi DDL (Data Definition Language) come CREATE TABLE, al momento è possibile replicare le tabelle MyISAM da un'origine esterna a Cloud SQL.

Tuttavia, queste tabelle MyISAM importate su Cloud SQL possono causare problemi di stabilità e affidabilità in un secondo momento durante operazioni come replica, recupero point-in-time e failover. Per questo motivo è consigliabile convertire tutte le tabelle utente MyISAM in InnoDB prima di eseguire una migrazione. 

La seguente query elenca tutte le tabelle MyISAM non di sistema.

In quanto servizio gestito, MySQL per Cloud SQL non consente il privilegio SUPER per gli account utente. In questo differisce dalla maggior parte delle installazioni on-premise di MySQL che consentono utenti root con questo privilegio. Analogamente, la maggior parte degli altri provider cloud non fornisce questo privilegio SUPER in un ambiente MySQL gestito.

In ogni caso, gli utenti di Cloud SQL ricevono un utente MySQL predefinito denominato "root’@’%" a cui sono concessi la maggior parte dei privilegi forniti da MySQL ad eccezione di quelli che potrebbero influire sulla possibilità da parte di Google di gestire il servizio, come il suddetto SUPER, insieme a FILE e SHUTDOWN. Per ulteriori dettagli sui privilegi d'uso forniti in Cloud SQL, consulta la documentazione sugli utenti MySQL.

Durante la preparazione alla migrazione, esamina tutti gli account utente nell'istanza di origine. Ad esempio, esegui il comando SHOW GRANTS per ciascun utente per esaminare l'insieme di privilegi correnti e verificare se alcuni sono soggetti a limitazioni in Cloud SQL. Analogamente, lo strumento pt-show-grants di Percona può elencare i privilegi concessi.

Le restrizioni sui privilegi utente in Cloud SQL possono influire sulle migrazioni durante la migrazione di oggetti di database con un attributo DEFINER. Spesso questo è il caso delle stored procedure, dei trigger, delle funzioni definite dall'utente e delle viste. Se l'attributo definer per un oggetto di database nell'istanza di origine è un utente con un privilegio non supportato in Cloud SQL, questo può causare problemi durante o dopo la migrazione.

Ad esempio, una stored procedure potrebbe avere un attributo definer con privilegi elevati per eseguire comandi SQL come la modifica di una variabile globale non consentita in Cloud SQL. In casi come questo, potrebbe essere necessario riscrivere il codice della stored procedure o eseguire la migrazione degli oggetti diversi dalle tabelle, come le stored procedure, come passaggio separato.

La nostra documentazione include una sezione intitolata Job di importazione e migrazione MySQL con metadati con clausola DEFINER che tratta in modo più approfondito altri problemi relativi alla clausola definer per gli oggetti del database.

A causa delle limitazioni dei privilegi utente menzionate in precedenza, gli utenti non possono chiamare in modo nativo il comando SET GLOBAL per modificare i parametri del database. Cloud SQL offre invece un insieme predefinito di "flag" che possono essere modificati utilizzando la console della UI, GCloud CLI e API REST per modificare i parametri.

L'elenco completo dei flag Cloud SQL supportati per MySQL è disponibile nella nostra documentazione pubblica nella sezione Flag supportati. Prima di eseguire la migrazione a Cloud SQL, confronta l'elenco dei flag supportati con i flag attualmente utilizzati nel tuo ambiente di origine. Ad esempio, una buona abitudine è creare un'istanza Cloud SQL di test con impostazioni della CPU e della memoria simili a quelle dell'istanza di origine ed eseguire SHOW GLOBAL VARIABLES sia sull'istanza di origine sia su Cloud SQL per confrontare le differenze.

I flag comuni che possono avere impostazioni diverse on-premise o in un provider cloud rispetto a Cloud SQL per MySQL includono:

• Impostazioni del set di caratteri e delle regole di confronto, ad esempio character_set_server e collation_server. I valori predefiniti possono variare tra le installazioni e portare a differenze nell'archiviazione e nelle prestazioni. Ad esempio, latin1 rispetto a utf8.
• Impostazioni dei log binari, ad esempio binlog_format. Cloud SQL attualmente supporta solo il logging basato su righe nel log binario.
• Impostazioni di replica avanzate. Ad esempio, Cloud SQL non supporta i parametri filtro di replica come replicate-do-table e replicate-do-db.
• Impostazioni avanzate di InnoDB Cloud SQL consente di modificare la maggior parte dei parametri correlati a InnoDB, ad esempio il ridimensionamento del pool di buffer InnoDB, tramite la modifica di innodb_buffer_pool_size. Tuttavia, potrebbero esserci alcune impostazioni InnoDB più dettagliate non modificabili in Cloud SQL o con valori predefiniti diversi rispetto a quelli on-premise o ad altri provider cloud.