Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Confronto tra Aurora MySQL versione 2 e Aurora MySQL versione 3
Utilizzare quanto segue per scoprire le modifiche di cui essere a conoscenza quando si aggiorna il cluster Aurora MySQL versione 2 alla versione 3.
**Topics**
+ [Supporto per Atomic DDL (Data Definition Language).](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Differenze di funzionalità tra Aurora MySQL versione 2 e 3](#AuroraMySQL.Compare-v2-v3-features)
+ [Supporto delle classi di istanza](#AuroraMySQL.mysql80-instance-classes)
+ [Modifiche ai parametri per Aurora MySQL versione 3](#AuroraMySQL.mysql80-parameter-changes)
+ [Variabili di stato](#AuroraMySQL.mysql80-status-vars)
+ [Cambiamenti linguistici inclusivi per Aurora MySQL versione 3](#AuroraMySQL.8.0-inclusive-language)
+ [Valori AUTO\$1INCREMENT](#AuroraMySQL.mysql80-autoincrement)
+ [Replica dei log binari](#AuroraMySQL.mysql80-binlog)
## Supporto per Atomic DDL (Data Definition Language).
Una delle modifiche più importanti da MySQL 5.7 a 8.0 è l’introduzione dell’[Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). Prima di MySQL 8.0, il dizionario dei dati MySQL utilizzava un approccio basato su file per archiviare metadati come definizioni di tabelle (.frm), trigger (.trg) e funzioni separatamente dai metadati del motore di archiviazione (come quelli di InnoDB). Ciò presentava alcuni problemi, tra cui il rischio che le tabelle diventassero [orfane](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html) in caso di imprevisti durante un’operazione DDL, il che causava la mancata sincronizzazione tra metadati basati su file e metadati del motore di archiviazione.
Per risolvere questo problema, MySQL 8.0 ha introdotto l’Atomic Data Dictionary, che archivia tutti i metadati in un set di tabelle InnoDB interne nello schema `mysql`. Questa nuova architettura offre un modo transazionale e conforme agli standard [ACID](https://en.wikipedia.org/wiki/ACID) per gestire i metadati del database, risolvendo il problema di “Atomic DDL” derivante dal precedente approccio basato su file. Per ulteriori informazioni sull’Atomic Data Dictionary, consulta [Removal of file-based metadata storage](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) e [Atomic data definition statement support](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) nel *manuale di riferimento di MySQL*.
A causa di questa modifica all’architettura, è necessario considerare quanto segue durante l’aggiornamento da Aurora MySQL versione 2 alla versione 3:
+ È necessario eseguire la migrazione dei metadati basati su file della versione 2 nelle nuove tabelle dei dizionari di dati durante il processo di aggiornamento alla versione 3. A seconda del numero di oggetti del database di cui viene eseguita la migrazione, questa operazione potrebbe richiedere tempo.
+ Le modifiche hanno inoltre introdotto alcune nuove incompatibilità che potrebbero dover essere risolte prima di poter eseguire l’aggiornamento da MySQL 5.7 a 8.0. Ad esempio, 8.0 include alcune nuove parole chiave riservate che potrebbero entrare in conflitto con i nomi degli oggetti del database esistenti.
Per aiutarti a identificare queste incompatibilità prima di aggiornare il motore, Aurora MySQL esegue una serie di controlli di compatibilità degli aggiornamenti (controlli preliminari) per determinare se ci sono oggetti incompatibili nel dizionario del database, prima di eseguire l’aggiornamento del dizionario dei dati. Per ulteriori informazioni sui controlli preliminari, consulta [Controlli preliminari per gli aggiornamenti a versioni principali per Aurora MySQL](AuroraMySQL.upgrade-prechecks.md).
## Differenze di funzionalità tra Aurora MySQL versione 2 e 3
Le seguenti caratteristiche di Amazon Aurora MySQL sono supportate in Aurora MySQL 5.7, ma attualmente non in Aurora MySQL 8.0:
+ Non puoi utilizzare Aurora MySQL versione 3 per cluster Aurora Serverless v1. Aurora MySQL versione 3 funziona con Aurora Serverless v2.
+ La modalità Lab non si applica ad Aurora MySQL versione 3. Non ci sono funzionalità in modalità laboratorio in Aurora MySQL versione 3. Instant DDL sostituisce la veloce funzionalità DDL online precedentemente disponibile in modalità laboratorio. Per vedere un esempio, consulta [DDL istantaneo (Aurora MySQL versione 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl).
+ La cache delle query viene rimossa dalla community MySQL 8.0 e anche da Aurora MySQL versione 3.
+ Aurora MySQL versione 3 è compatibile con la funzionalità hash join MySQL della community. L'implementazione specifica di Aurora di hash join in Aurora MySQL versione 2 non viene utilizzata. Per informazioni sull'utilizzo di hash join con la query parallela Aurora, consultare [Abilitazione dell'hash join per cluster di query parallele](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) e [Suggerimenti di Aurora MySQL](AuroraMySQL.Reference.Hints.md). Per informazioni generali sull'utilizzo su hash join, vedere [Ottimizzazione hash join](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html) nel *Manuale di riferimento MySQL*.
+ La procedura archiviata `mysql.lambda_async` resa obsoleta in Aurora MySQL versione 2 viene rimossa nella versione 3. Per la versione 3, utilizzare invece la funzione asincrona `lambda_async`.
+ Il set di caratteri predefinito in Aurora MySQL versione 3 è `utf8mb4`. In Aurora MySQL versione 2, il set di caratteri predefinito era `latin1`. Per informazioni su questo set di caratteri, consultare [Il set di caratteri utf8mb4 (4-Byte UTF-8 Unicode Encoding)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) nel *Manuale di riferimento MySQL*.
Alcune funzionalità di Aurora MySQL sono disponibili per alcune combinazioni di regione AWS e versione del motore del database. Per dettagli, consultare [Funzionalità supportate in Amazon Aurora by e Regione AWS Aurora DB engine](Concepts.AuroraFeaturesRegionsDBEngines.grids.md).
## Supporto delle classi di istanza
Aurora MySQL versione 3 supporta un set di classi di istanza diverso da quello di Aurora MySQL versione 2:
+ Per istanze più grandi, è possibile utilizzare le classi di istanza moderne come`db.r5`,`db.r6g`, e`db.x2g`.
+ Per istanze più piccole, è possibile utilizzare le classi di istanza moderne come `db.t3` e `db.t4g`.
**Nota**
Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta [Utilizzo delle classi di istanza T per lo sviluppo e i test](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Le seguenti classi di istanza di Aurora MySQL versione 2 non sono disponibili per Aurora MySQL versione 3:
+ `db.r4`
+ `db.r3`
+ `db.t3.small`
+ `db.t2`
Controllare gli script di amministrazione per eventuali istruzioni CLI che creano istanze database Aurora MySQL. Codificare i nomi delle classi di istanza che non sono disponibili per Aurora MySQL versione 3. Se necessario, modificare i nomi delle classi di istanza con quelli supportati da Aurora MySQL versione 3.
**Suggerimento**
Per controllare le classi di istanza che è possibile utilizzare per una combinazione specifica della versione di Aurora MySQL e regione AWS, utilizza il comando `describe-orderable-db-instance-options` AWS CLI.
Per i dettagli sulle classi di istanza Aurora, consultare [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
## Modifiche ai parametri per Aurora MySQL versione 3
Aurora MySQL versione 3 include nuovi parametri di configurazione a livello di cluster e a livello di istanza. Aurora MySQL versione 3 rimuove anche alcuni parametri presenti in Aurora MySQL versione 2. Alcuni nomi dei parametri vengono modificati a seguito dell'iniziativa per un linguaggio inclusivo. Per la compatibilità con le versioni precedenti, è comunque possibile recuperare i valori dei parametri utilizzando i vecchi nomi o i nuovi nomi. Tuttavia, è necessario utilizzare i nuovi nomi per specificare i valori dei parametri in un gruppo di parametri personalizzato.
In Aurora MySQL versione 3, il valore del parametro `lower_case_table_names` viene impostato in modo permanente al momento della creazione del cluster. Se si utilizza un valore non predefinito per questa opzione, configurare il gruppo di parametri personalizzati Aurora MySQL versione 3 prima dell'aggiornamento. Quindi specificare il gruppo di parametri durante l'operazione di creazione del cluster o del ripristino dello snapshot.
**Nota**
Con un database globale Aurora basato su Aurora MySQL, non puoi eseguire un aggiornamento locale da Aurora MySQL versione 2 alla versione 3 se il parametro `lower_case_table_names` è attivato. Utilizzare invece il metodo di ripristino snapshot.
In Aurora MySQL versione 3, i parametri `init_connect` e `read_only` non si applicano agli utenti che dispongono del privilegio `CONNECTION_ADMIN`, incluso l'utente master Aurora. Per ulteriori informazioni, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Per un elenco di tutti i parametri del cluster Aurora MySQL, consultare [Parametri a livello di cluster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). La tabella copre tutti i parametri di Aurora MySQL versione 2 e 3. La tabella include note che mostrano quali parametri sono nuovi in Aurora MySQL versione 3 o sono stati rimossi da Aurora MySQL versione 3.
Per un elenco di tutti i parametri dell'istanza Aurora MySQL, consultare [Parametri a livello di istanza](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). La tabella copre tutti i parametri di Aurora MySQL versione 2 e 3. La tabella include note che mostrano quali parametri sono nuovi in Aurora MySQL versione 3 e quali parametri sono stati rimossi da Aurora MySQL versione 3. Include anche note che mostrano quali parametri erano modificabili nelle versioni precedenti ma non Aurora MySQL versione 3.
Per informazioni sui nomi dei parametri modificati, consultare [Cambiamenti linguistici inclusivi per Aurora MySQL versione 3](#AuroraMySQL.8.0-inclusive-language).
## Variabili di stato
Per informazioni sulle variabili di stato che non sono applicabili a Aurora MySQL, vedere [Le variabili di stato MySQL seguenti non si applicano ad Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable).
## Cambiamenti linguistici inclusivi per Aurora MySQL versione 3
La versione iniziale di Aurora MySQL versione 3 è compatibile con la community MySQL 8.0.23. Aurora MySQL versione 3 include anche i cambiamenti da MySQL 8.0.26 relativi alle parole chiave e agli schemi di sistema per il linguaggio inclusivo. Ad esempio, il comando `SHOW REPLICA STATUS` è ora preferito invece di `SHOW SLAVE STATUS`.
Le seguenti metriche Amazon CloudWatch hanno nuovi nomi in Aurora MySQL versione 3.
In Aurora MySQL versione 3, sono disponibili solo i nuovi nomi delle metriche. Assicurati di aggiornare qualsiasi allarme o altra automazione basata sui nomi delle metriche quando esegui l'aggiornamento a Aurora MySQL versione 3.
| Vecchio nome | Nuovo nome |
| --- | --- |
| ForwardingMasterDMLLatency | ForwardingWriterDMLLatency |
| ForwardingMasterOpenSessions | ForwardingWriterOpenSessions |
| AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull |
| ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput |
Le seguenti variabili di stato hanno nuovi nomi in Aurora MySQL versione 3.
Per compatibilità, è possibile utilizzare entrambi i nomi nella versione iniziale di Aurora MySQL versione 3. I nomi delle variabili di stato precedenti devono essere rimossi in una versione futura.
| Nome da rimuovere | Nome nuovo o preferito |
| --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout |
| Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions |
| Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit |
| Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout |
I seguenti parametri di configurazione hanno nuovi nomi in Aurora MySQL versione 3.
Per la compatibilità, è possibile controllare i valori dei parametri nel client di `mysql` utilizzando entrambi i nomi nella versione iniziale di Aurora MySQL versione 3. Puoi utilizzare i nuovi nomi solo quando modifichi i valori in un gruppo di parametri personalizzati. I nomi dei parametri precedenti devono essere rimossi in una versione futura.
| Nome da rimuovere | Nome nuovo o preferito |
| --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct |
| master\$1verify\$1checksum | source\$1verify\$1checksum |
| sync\$1master\$1info | sync\$1source\$1info |
| init\$1slave | init\$1replica |
| rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout |
| log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements |
| slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet |
| slave\$1compressed\$1protocol | replica\$1compressed\$1protocol |
| slave\$1exec\$1mode | replica\$1exec\$1mode |
| slave\$1type\$1conversions | replica\$1type\$1conversions |
| slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum |
| slave\$1parallel\$1type | replica\$1parallel\$1type |
| slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order |
| log\$1slave\$1updates | log\$1replica\$1updates |
| slave\$1allow\$1batching | replica\$1allow\$1batching |
| slave\$1load\$1tmpdir | replica\$1load\$1tmpdir |
| slave\$1net\$1timeout | replica\$1net\$1timeout |
| sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter |
| slave\$1skip\$1errors | replica\$1skip\$1errors |
| slave\$1checkpoint\$1period | replica\$1checkpoint\$1period |
| slave\$1checkpoint\$1group | replica\$1checkpoint\$1group |
| slave\$1transaction\$1retries | replica\$1transaction\$1retries |
| slave\$1parallel\$1workers | replica\$1parallel\$1workers |
| slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max |
| pseudo\$1slave\$1mode | pseudo\$1replica\$1mode |
Le seguenti stored procedure hanno nuovi nomi in Aurora MySQL versione 3.
Per compatibilità, è possibile utilizzare entrambi i nomi nella versione iniziale di Aurora MySQL versione 3. I nomi delle procedure precedenti devono essere rimossi in una versione futura.
| Nome da rimuovere | Nome nuovo o preferito |
| --- | --- |
| mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position |
| mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source |
| mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position |
| mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source |
| mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log |
## Valori AUTO\$1INCREMENT
In Aurora MySQL versione 3, Aurora conserva il valore `AUTO_INCREMENT` per ogni tabella quando riavvia ogni istanza database. In Aurora MySQL versione 2, il valore `AUTO_INCREMENT` non è stato conservato dopo un riavvio.
Il valore `AUTO_INCREMENT` non viene mantenuto quando si configura un nuovo cluster ripristinando da uno snapshot, eseguendo un ripristino point-in-time (PITR) e clonando un cluster. In questi casi, il valore `AUTO_INCREMENT` viene inizializzato sul valore in base al valore di colonna più grande nella tabella al momento della creazione dello snapshot. Questo comportamento è diverso da quello in RDS per MySQL 8.0, dove il valore `AUTO_INCREMENT` viene mantenuto durante queste operazioni.
## Replica dei log binari
Nell'edizione della community MySQL 8.0, la replica del log binario è attivata per impostazione predefinita. In Aurora MySQL versione 3, la replica del log binario è disattivata per impostazione predefinita.
**Suggerimento**
Se i requisiti di elevata disponibilità sono soddisfatti dalle funzionalità di replica incorporate di Aurora, è possibile lasciare disattivata la replica del log binario. In questo modo, è possibile evitare il sovraccarico delle prestazioni della replica del log binario. È inoltre possibile evitare il monitoraggio e la risoluzione dei problemi associati necessari per gestire la replica dei log binari.
Aurora supporta la replica dei log binari da una fonte compatibile con MySQL 5.7 a Aurora MySQL versione 3. Il sistema fonte può essere un cluster database Aurora MySQL, un'istanza database RDS for MySQL o un'istanza MySQL locale.
Come fa MySQL della community, Aurora MySQL supporta la replica da una fonte che esegue una versione specifica a una destinazione che esegue la stessa versione principale o una versione principale superiore. Ad esempio, la replica da un sistema compatibile con MySQL 5.6 ad Aurora MySQL versione 3 non è supportata. La replica da Aurora MySQL versione 3 a un sistema compatibile con MySQL 5.7 o compatibile con MySQL 5.6 non è supportata. Per i dettagli sull'utilizzo della replica dei log binari, consultare [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md).
Aurora MySQL versione 3 include miglioramenti alla replica dei log binari nella community MySQL 8.0, come la replica filtrata. Per informazioni dettagliate sui miglioramenti di MySQL 8.0 della community, consultare [Come i server valutano le regole di filtro delle repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) nel *Manuale di riferimento MySQL*.
### Compressione delle transazioni per la replica dei registri binari
Per informazioni sull'utilizzo sulla compressione del log binario, vedere [Compressione delle transazioni dei registri ](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html) nel Manuale di riferimento di MySQL.
Le seguenti limitazioni si applicano alla compressione dei log binari in Aurora MySQL versione 3:
+ Le transazioni i cui dati di registro binario sono superiori alla dimensione massima consentita del pacchetto non vengono compresse. Ciò è vero a prescindere che l'impostazione di compressione del registro binario di Aurora MySQL sia attivata. Tali transazioni vengono replicate senza essere compresse.
+ Se si utilizza un connettore per l'acquisizione dati di modifica (CDC) che non supporta ancora MySQL 8.0, non è possibile utilizzare questa funzione. Ti consigliamo di testare accuratamente tutti i connettori di terze parti con la compressione del registro binario. Inoltre, ti consigliamo di eseguire questa operazione prima di attivare la compressione binlog su sistemi che utilizzano la replica del binlog per CDC.