Considerazioni importanti prima della migrazione di Aurora a Cloud SQL per MySQL

Aurora utilizza il server di set di caratteri predefinito latin1 (fino alla versione MySQL 5.7). Differisce dalla configurazione predefinita di Cloud SQL per MySQL per database, tabelle, stored procedure e funzioni, che vengono create con utf8 come set di caratteri predefinito durante la migrazione. Ciò può comportare situazioni che causano problemi di prestazioni.

Ad esempio, un utente può trovarsi in una situazione in cui le tabelle vengono create con il set di caratteri latin1 e le stored procedure o le funzioni vengono create con il set di caratteri utf8 predefinito di Cloud SQL. In questi casi, se la stored procedure o la funzione prevedono variabili come parametri utf8 e la raffrontano con il valore della colonna, che è in set di caratteri latin1, si verificherà un problema di prestazioni a causa del confronto tra due diversi set di caratteri e regole di confronto. 

Puoi controllare il set di caratteri delle routine utilizzando il seguente comando:

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

Se stavi utilizzando il set di caratteri predefinito in Aurora (fino alla versione 5.7), ovvero latin1, il set di caratteri predefinito deve essere modificato da utf8 a latin1 in Cloud SQL prima di importare i dati.

Un'altra soluzione potrebbe essere modificare tutto in utf8; tuttavia, in questo caso gli utenti dovrebbero testare l'applicazione e il set di dati completi poiché le modifiche al set di caratteri possono comportare rappresentazioni di dati impreviste.

Gli utenti possono modificare questa impostazione nell'istanza Cloud SQL sotto la sezione dei flag, come illustrato di seguito.

Aurora MySQL 5.7 ha molte regole di confronto (ad esempio utf8mb4_0900_ai_ci per il set di caratteri utf8mb4) attualmente disponibili solo in Cloud SQL per MySQL 8.0. Se utilizzi queste regole di confronto e importi i dati in Cloud SQL per MySQL 5.7, verrà visualizzato un messaggio di errore simile a "Errore: il 'set di caratteri 255' non è un set di caratteri compilato''.

La soluzione è cambiare queste regole di confronto in quelle disponibili in MySQL versione 5.7.

A differenza di Aurora, Cloud SQL per MySQL non supporta il motore MyISAM. Ti consigliamo di convertire tutte le tabelle in InnoDB prima di avviare la migrazione da Aurora a Cloud SQL. 

Se esiste una tabella in un motore diverso da InnoDB, gli utenti possono modificare il motore della tabella utilizzando il comando "ALTER":

mysql> alter table table_1 engine='Innodb' ;

Query OK, 0 rows affected (2.89 sec)

Records: 0 Duplicates: 0 Warnings: 0

Nota: il tempo necessario per l'esecuzione della query dipende dalle dimensioni della tabella e potrebbe bloccare altre operazioni nella stessa tabella. Puoi anche utilizzare strumenti per la modifica online dello schema come pt-online-schema-change o gh-ost per alterare la tabella senza bloccare altre operazioni.

In Aurora gli utenti possono configurare più lettori dietro un singolo endpoint, anche se gli utenti di Cloud SQL per MySQL non hanno questa funzionalità predefinita. Ogni replica di lettura in Cloud SQL per MySQL ha il proprio IP e gli utenti devono utilizzare un proxy come ProxySQL per suddividere il traffico tra più istanze di replica di lettura.

Ecco una guida che mostra come utilizzare ProxySQL per instradare il traffico a più repliche di lettura.

Il buffer delle modifiche è una struttura di dati speciale che memorizza nella cache le modifiche alle pagine di indici secondari quando queste ultime non si trovano nel pool di buffer e vengono unite successivamente quando vengono caricate nel pool di buffer da altre operazioni di lettura. Per maggiori dettagli leggi la sezione relativa al buffer delle modifiche.

Per il caso d'uso in cui il carico di lavoro contiene molte scritture nelle tabelle con indici secondari, Aurora potrebbe avere prestazioni più lente di Cloud SQL per MySQL, che utilizza la funzionalità predefinita del buffer delle modifiche InnoDB per rimandare questi aggiornamenti a una fase successiva. Gli utenti devono confrontare le prestazioni in base al carico di lavoro dell'applicazione.

La cache delle query memorizza il comando select insieme al risultato in un livello di archiviazione intermedio. Se in un secondo momento si riceve un'istruzione identica, il server controlla e recupera i risultati dalla cache delle query, anziché eseguire di nuovo quel comando. La cache delle query è condivisa tra tutte le sessioni, che possono quindi sfruttare i risultati memorizzati nella cache da istruzioni già eseguite da altre sessioni. Scopri di più sulla cache delle query.

Aurora abilita la cache delle query per impostazione predefinita, tuttavia la community MySQL ha disabilitato la cache delle query nella versione 5.7 e l'ha rimossa completamente nella versione 8.0. Anche Cloud SQL per MySQL ha fatto lo stesso. Se le query si basano sulla funzionalità di memorizzazione nella cache delle query di Aurora, le prestazioni possono variare in Cloud SQL per MySQL. Consigliamo di testare le prestazioni delle query in Cloud SQL per MySQL confrontando il tempo di esecuzione con Aurora.

Per le repliche di lettura all'interno di una regione, Aurora utilizza il concetto di volume del cluster che contiene copie dei dati in tre zone di disponibilità al suo interno. Il ritardo della replica in Aurora è in genere molto inferiore a 100 millisecondi perché l'istanza principale e le repliche all'interno dello stesso cluster di database visualizzano tutti i dati nel volume del cluster come un singolo volume logico. Inoltre, per la replica di lettura tra regioni, Aurora utilizza la sincronizzazione dei dati basata su disco in più regioni anziché la replica basata su log binario.

In breve, in Aurora la replica viene gestita dal livello di archiviazione, mentre in Cloud SQL per MySQL viene utilizzato il meccanismo di replica standard che trasferisce il log binario nell'istanza di replica e quindi replica i log nelle istanze MySQL di replica. Possiamo migliorare le prestazioni della replica configurando la replica parallela in Cloud SQL. Leggi i dettagli sulla configurazione della replica parallela.

Anche se il tempo di replica dipende dalla quantità di dati modificati dall'applicazione e dalla rete tra le istanze principale e di replica, la maggior parte delle applicazioni funziona senza ritardi sia in Aurora che in Cloud SQL per MySQL. Tuttavia, se l'applicazione esegue una scrittura intensiva e l'applicazione sta leggendo le repliche, suggeriamo di confrontare il tempo di replica in AWS Aurora e in Cloud SQL MySQL prima della migrazione.

A differenza di AWS Aurora, che utilizza la sincronizzazione dei dati basata su disco, Cloud SQL per MySQL utilizza la replica GTID. Prima di eseguire la migrazione, gli utenti devono controllare le limitazioni dei GTID elencate di seguito e apportare le eventuali modifiche richieste nell'applicazione, se il flusso di lavoro dell'applicazione dipende da una di queste funzionalità:

• Le istruzioni CREATE TABLE ... SELECT non sono consentite se utilizzi la replica basata su GTID.
• Le istruzioni CREATE TEMPORARY TABLE e DROP TEMPORARY TABLE non sono supportate all'interno di transazioni, procedure, funzioni e trigger. È possibile utilizzare queste istruzioni con i GTID abilitati, ma solo al di fuori di qualsiasi transazione e solo con autocommit=1.

Per scoprire di più sulle limitazioni basate su GTID, leggi la sezione relativa alle limitazioni dei GTID.