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à. # Aurora MySQL versione 3 compatibile con MySQL 8.0 È possibile utilizzare Aurora MySQL versione 3 per ottenere le più recenti funzionalità compatibili con MySQL, miglioramenti delle prestazioni e correzioni di bug. Di seguito, è possibile conoscere Aurora MySQL versione 3, con compatibilità MySQL 8.0. Puoi imparare come aggiornare cluster e applicazioni ad Aurora MySQL versione 3. Alcune caratteristiche di Aurora, come Aurora Serverless v2, richiedono Aurora MySQL versione 3. **Topics** + [Funzionalità della community MySQL 8.0](#AuroraMySQL.8.0-features-community) + [Aurora MySQL versione 3 prerequisito per Aurora MySQL Serverless v2](#AuroraMySQL.serverless-v2-8.0-prereq) + [Note di rilascio di Aurora MySQL versione 3](#AuroraMySQL.mysql80-bugs-fixed) + [Nuove ottimizzazioni delle query parallele](#AuroraMySQL.8.0-features-pq) + [Ottimizzazioni per ridurre i tempi di riavvio del database](#ReducedRestartTime) + [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md) + [Confronto tra Aurora MySQL versione 2 e Aurora MySQL versione 3](AuroraMySQL.Compare-v2-v3.md) + [Confronto tra Aurora MySQL versione 3 e MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md) + [Aggiornamento ad Aurora MySQL versione 3](AuroraMySQL.mysql80-upgrade-procedure.md) ## Funzionalità della community MySQL 8.0 La versione iniziale di Aurora MySQL versione 3 è compatibile con la community MySQL 8.0.23. MySQL 8.0 introduce diverse nuove funzionalità, tra cui: + Supporto per Atomic DDL (Data Definition Language). Per ulteriori informazioni, consulta [Supporto per Atomic DDL (Data Definition Language).](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl). + Funzioni JSON. Per informazioni sull'utilizzo, consulta [Funzioni JSON](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html) nel *Manuale di riferimento MySQL*. + Funzioni finestra Per informazioni sull'utilizzo, consulta [Funzioni finestra](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html) nel *Manuale di riferimento MySQL*. + Espressioni di tabella comuni (CTE), utilizzando la clausola `WITH`. Per informazioni sull'utilizzo, consulta [WITH (espressioni di tabella comuni)](https://dev.mysql.com/doc/refman/8.0/en/with.html) nel *Manuale di riferimento MySQL*. + Ottimizzazione `ADD COLUMN` e clausole `RENAME COLUMN` per l'istruzione `ALTER TABLE`. Queste ottimizzazioni sono chiamate «DDL istantaneo». Aurora MySQL versione 3 è compatibile con la funzionalità DDL istantanea MySQL della community. L'ex caratteristica DDL veloce Aurora non viene utilizzata. Per informazioni sull'utilizzo del DDL istantaneo, vedere [DDL istantaneo (Aurora MySQL versione 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl). + Indici discendenti, funzionali e invisibili. Per informazioni sull'utilizzo, consulta [Indici invisibili](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html),[Indici discendenti](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html), e [Istruzioni CREATE INDEX](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts) nel *Manuale di riferimento MySQL*. + Privilegi basati sui ruoli controllati tramite istruzioni SQL. Per ulteriori informazioni sulle modifiche al modello di privilegi, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). + clausole `NOWAIT` e `SKIP LOCKED` con istruzioni `SELECT ... FOR SHARE`. Queste clausole evitano di attendere che altre transazioni rilascino blocchi di riga. Per informazioni sull'utilizzo, consultare [Blocco letture](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html), nel *manuale di riferimento di MySQL*. + Miglioramenti alla replica dei log binari (binlog). Per i dettagli di Aurora MySQL, consultare [Replica dei log binari](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog). In particolare, è possibile eseguire la replica filtrata. Per informazioni sull'utilizzo sulla replica filtrata, vedere [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*. + Suggerimenti. Alcuni dei suggerimenti compatibili con MySQL 8.0 erano già stati sottoposti a backport su Aurora MySQL versione 2. Per ulteriori informazioni sulla sicurezza con Aurora MySQL, consultare [Suggerimenti di Aurora MySQL](AuroraMySQL.Reference.Hints.md). Per l'elenco completo dei suggerimenti nella community MySQL 8.0, consulta[Suggerimenti di ottimizzazione](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) nel *Manuale di riferimento MySQL*. Per l'elenco completo delle funzionalità aggiunte all'edizione della community di MySQL 8.0, consulta il post del blog [L'elenco completo delle nuove funzionalità di MySQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/). Aurora MySQL versione 3 include anche modifiche alle parole chiave per un linguaggio inclusivo, con backport dalla community MySQL 8.0.26. Per i dettagli su tali modifiche, consultare [Cambiamenti linguistici inclusivi per Aurora MySQL versione 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language). ## Aurora MySQL versione 3 prerequisito per Aurora MySQL Serverless v2 Aurora MySQL versione 3 è un prerequisito per tutte le istanze database in un cluster Aurora MySQL Serverless v2. Aurora MySQL Serverless v2 include il supporto per le istanze di lettura in un cluster di database e altre caratteristiche di Aurora che non sono disponibili per Aurora MySQL Serverless v1. Dispone anche di un dimensionamento più rapido e granulare rispetto ad Aurora MySQL Serverless v1. ## Note di rilascio di Aurora MySQL versione 3 Per le Note di rilascio di tutte le release di Aurora MySQL versione 3, consultare [Aggiornamenti del motore del database per Amazon Aurora MySQL versione 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) nelle *Note di rilascio di Aurora MySQL*. ## Nuove ottimizzazioni delle query parallele L'ottimizzazione delle query parallele Aurora ora si applica a più operazioni SQL: + La query parallela ora si applica alle tabelle contenenti i tipi di dati `TEXT`, `BLOB`, `JSON`, `GEOMETRY`, e `VARCHAR` e `CHAR` superiori a 768 byte. + La query parallela può ottimizzare le query che coinvolgono tabelle partizionate. + La query parallela può ottimizzare le query che coinvolgono chiamate di funzioni aggregate nell'elenco di selezione e nella clausola `HAVING`. Per ulteriori informazioni su questi miglioramenti, consultare [Aggiornare cluster di query paralleli a Aurora MySQL versione 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). Per informazioni generali sulle query parallele Aurora, consultare [Query parallela per Amazon Aurora MySQL](aurora-mysql-parallel-query.md). ## Ottimizzazioni per ridurre i tempi di riavvio del database Il cluster di database Aurora MySQL deve essere a disponibilità elevata durante le interruzioni pianificate e non pianificate. Gli amministratori di database devono eseguire la manutenzione occasionale del database. Attività incluse nella manutenzione sono l'applicazione di patch al database, gli aggiornamenti, la modifica dei parametri del database che richiedono un riavvio manuale, l'esecuzione di un failover per ridurre il tempo impiegato da un'istanza per modificare la classe. Queste operazioni pianificate comportano tempi di inattività. Tuttavia, i tempi di inattività possono essere causati anche da operazioni non pianificate, come un failover imprevisto dovuto a un guasto hardware sottostante o a una limitazione delle risorse del database. Tutte queste operazioni pianificate e non pianificate comportano il riavvio del database. In Aurora MySQL 3.05 e versioni successive, abbiamo introdotto ottimizzazioni che riducono il tempo di riavvio del database. Queste ottimizzazioni consentono di ridurre fino al 65% i tempi di inattività rispetto alle ottimizzazioni precedenti e di ridurre le interruzioni dei carichi di lavoro del database dopo un riavvio. Durante l'avvio del database, vengono inizializzati molti componenti della memoria interna. Il più grande di questi è il [pool di buffer InnoDB](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), che in Aurora MySQL costituisce per impostazione predefinita il 75% della dimensione della memoria dell'istanza. I nostri test hanno rilevato che il tempo di inizializzazione è proporzionale alla dimensione del pool di buffer InnoDB e che si dimensiona in base alla grandezza della classe dell'istanza del database. Durante questa fase di inizializzazione, il database non può accettare connessioni, il che causa tempi di inattività più lunghi durante i riavvii. Durante la prima fase del riavvio rapido, Aurora MySQL ottimizza l'inizializzazione del pool di buffer, riducendo i tempi di inizializzazione del database e quindi il tempo di riavvio complessivo. Per maggiori dettagli, consulta il blog [Reduce downtime with Amazon Aurora MySQL database restart time optimizations](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/). # Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3 Aurora MySQL versione 3 gestisce le tabelle temporanee in maniera diversa dalle versioni precedenti di Aurora MySQL. Questo nuovo comportamento è ereditato dalla edizione della comunità MySQL 8.0. Esistono due tipi di tabelle temporanee che possono essere create con Aurora MySQL versione 3: + Tabelle temporanee interne (o *implicite*): create dal motore MySQL di Aurora per gestire operazioni come l'aggregazione di ordinamento, le tabelle derivate o le espressioni di tabella comuni (). CTEs + Tabelle temporanee create dall'utente (o *esplicite*): create dal motore Aurora MySQL quando si utilizza l'istruzione `CREATE TEMPORARY TABLE`. Ci sono ulteriori considerazioni per le tabelle temporanee interne e create dall'utente sulle istanze database di lettura Aurora. Queste modifiche vengono illustrate nelle sezioni seguenti. **Topics** + [Motore di storage per tabelle temporanee (implicite) interne](#ams3-temptable-behavior-engine) + [Limitazione delle dimensioni delle tabelle temporanee interne in memoria](#ams3-temptable-behavior-limit) + [Mitigazione dei problemi di pienezza per le tabelle temporanee interne su repliche Aurora](#ams3-temptable-behavior-mitigate) + [Ottimizzazione del parametro temptable\$1max\$1mmap nelle istanze database di Aurora MySQL](#ams-optimize-temptable_max_mmap) + [Tabelle temporanee create dall'utente (esplicite) su istanze database di lettura](#ams3-temptable-behavior.user) + [Errori di creazione tabelle temporanee e mitigazione](#ams3-temptable-behavior.errors) ## Motore di storage per tabelle temporanee (implicite) interne Quando si generano set di risultati intermedi, Aurora MySQL tenta inizialmente di scrivere nelle tabelle temporanee in memoria. Questa operazione potrebbe non riuscire, a causa di tipi di dati incompatibili o limiti configurati. In tal caso, la tabella temporanea viene convertita in una tabella temporanea su disco anziché essere conservata in memoria. Ulteriori informazioni sono disponibili in [Utilizzo della tabella temporanea interna in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) nella documentazione MySQL. In Aurora MySQL versione 3, il modo in cui funzionano le tabelle temporanee interne è diverso dalle versioni precedenti di Aurora MySQL. Invece di scegliere tra i motori di archiviazione InnoDB e MyISAM per tali tabelle temporanee, ora è possibile scegliere tra i motori di archiviazione `TempTable` e `MEMORY`. Con il motore di archiviazione `TempTable`, è possibile fare una scelta aggiuntiva su come gestire determinati dati. I dati interessati fanno traboccare il pool di memoria che contiene tutte le tabelle temporanee interne per l'istanza database. Tali scelte possono influenzare le prestazioni delle query che generano volumi elevati di dati temporanei, ad esempio durante l'esecuzione di aggregazioni come `GROUP BY` su tabelle grandi. **Suggerimento** Se il carico di lavoro include query che generano tabelle temporanee interne, verificare le prestazioni dell'applicazione con questa modifica eseguendo benchmark e monitorando le metriche relative alle prestazioni. In alcuni casi, la quantità di dati temporanei si inserisce nella pool di memoria `TempTable` o fa solo traboccare il pool di memoria in piccola misura. In questi casi, si consiglia di utilizzare l'impostazione `TempTable` per tabelle temporanee interne e file mappati in memoria per contenere i dati di overflow. Questa è l'impostazione di default. Il motore di archiviazione `TempTable` è il valore di default. `TempTable` utilizza un pool di memoria comune per tutte le tabelle temporanee che utilizzano questo motore, anziché un limite massimo di memoria per tabella. La dimensione di questo pool di memoria è specificata dal parametro [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram). Il valore predefinito è 1 GiB su istanze database con 16 o più GiB di memoria e 16 MB su istanze database con meno di 16 GiB di memoria. La dimensione del pool di memoria influisce sul consumo di memoria a livello di sessione. In alcuni casi, quando si utilizza il motore di archiviazione `TempTable` i dati temporanei potrebbero superare le dimensioni del pool di memoria. In tal caso, Aurora MySQL archivia i dati di overflow utilizzando un meccanismo secondario. È possibile impostare il parametro [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) per scegliere se i dati eseguono l'overflow in file temporanei mappati in memoria o in tabelle temporanee interne di InnoDB su disco. I diversi formati di dati e i criteri di overflow di questi meccanismi di overflow possono influire sulle prestazioni delle query. Lo fanno influenzando la quantità di dati scritti su disco e la domanda sulla velocità effettiva di archiviazione su disco. Aurora MySQL versione 3 archivia i dati di overflow nel modo seguente: + Nell’istanza database di scrittura, i dati che eseguono l’overflow nelle tabelle temporanee interne di InnoDB o nei file temporanei mappati in memoria risiedono nella memoria locale dell’istanza. + Nelle istanze database di lettura, i dati di overflow risiedono sempre in file temporanei mappati in memoria nella memoria locale. Le istanze di sola lettura non possono memorizzare dati sul volume del cluster Aurora. I parametri di configurazione relativi alle tabelle temporanee interne si applicano in modo diverso alle istanze di scrittura e lettura nel cluster: + Nelle istanze di lettura, Aurora MySQL utilizza sempre il motore di archiviazione `TempTable`. + La dimensione per il valore di `temptable_max_mmap` predefinito è 1 GiB, per entrambe le istanze di scrittura e lettura, indipendentemente dalle dimensioni della memoria dell'istanza database. È possibile modificare questo valore sia nelle istanze di scrittura che in quelle di lettura. + L'impostazione di `temptable_max_mmap` su `0` disattiva l'uso dei file temporanei mappati in memoria nelle istanze di scrittura. + Non puoi impostare `temptable_max_mmap` su `0` nelle istanze di lettura. **Nota** Ti consigliamo di non utilizzare il parametro [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap). È deprecato e il relativo supporto verrà rimosso in una versione futura di MySQL. ## Limitazione delle dimensioni delle tabelle temporanee interne in memoria Come discusso in [Motore di storage per tabelle temporanee (implicite) interne](#ams3-temptable-behavior-engine), è possibile controllare le risorse temporanee delle tabelle a livello globale utilizzando le impostazioni [temptable max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) e [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap). Inoltre, è possibile limitare le dimensioni di ogni singola tabella temporanea interna in memoria utilizzando il parametro database [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size). Questo limite serve a evitare che le singole query consumino una quantità eccessiva di risorse globali delle tabelle temporanee, che può influire sulle prestazioni delle query simultanee che richiedono tali risorse. Il parametro `tmp_table_size` definisce le dimensioni massime delle tabelle temporanee create dal motore di storage `MEMORY` in Aurora MySQL versione 3. In Aurora MySQL versione 3.04 e successive, il parametro `tmp_table_size` definisce anche le dimensioni massime delle tabelle temporanee create dal motore di storage `TempTable` quando il parametro database `aurora_tmptable_enable_per_table_limit` è impostato su `ON`. Questo comportamento è disabilitato per impostazione predefinita (`OFF`), che è identico al comportamento in Aurora MySQL versione 3.03 e precedenti. + Quando `aurora_tmptable_enable_per_table_limit` è `OFF`, `tmp_table_size` non è considerato per le tabelle temporanee interne in memoria create dal motore di storage `TempTable`. Tuttavia, il limite di risorse `TempTable` globali rimane comunque in essere. Aurora MySQL presenta il seguente comportamento quando viene raggiunto il limite di risorse `TempTable` globale: + Istanze database di scrittura: Aurora MySQL converte automaticamente la tabella temporanea in memoria in una tabella temporanea su disco InnoDB. + Istanze database di lettura: la query termina con un errore. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` + Quando `aurora_tmptable_enable_per_table_limit` è `ON`, Aurora MySQL presenta il seguente comportamento quando viene raggiunto il limite `tmp_table_size`: + Istanze database di scrittura: Aurora MySQL converte automaticamente la tabella temporanea in memoria in una tabella temporanea su disco InnoDB. + Istanze database di lettura: la query termina con un errore. ``` ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full ``` Il limite di risorse `TempTable` globale e il limite per tabella si applicano entrambi in questo caso. **Nota** Il parametro `aurora_tmptable_enable_per_table_limit` non ha effetto quando [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) è impostato su `MEMORY`. In questo caso, le dimensioni massime di una tabella temporanea in memoria sono definite dal valore [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) o [dimensione max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size), a seconda di quale sia il più piccolo. Gli esempi seguenti mostrano il comportamento del parametro `aurora_tmptable_enable_per_table_limit`per le istanze database di scrittura e lettura. **Example dell'istanza database di scrittura con `aurora_tmptable_enable_per_table_limit` impostato su `OFF`** La tabella temporanea in memoria non viene convertita in una tabella temporanea su disco InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 0 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (13.99 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example dell'istanza database di scrittura con `aurora_tmptable_enable_per_table_limit` impostato su `ON`** La tabella temporanea in memoria viene convertita in una tabella temporanea su disco InnoDB. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 0 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; +---------+ | max(n) | +---------+ | 6000000 | +---------+ 1 row in set (4.10 sec) mysql> show status like '%created_tmp_disk%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | +-------------------------+-------+ 1 row in set (0.00 sec) ``` **Example dell'istanza database di lettura con `aurora_tmptable_enable_per_table_limit` impostato su `OFF`** La query termina senza errori perché `tmp_table_size` non è applicabile e il limite di risorse `TempTable` globale non è stato raggiunto. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte; +----------+ | max(n) | +----------+ | 60000000 | +----------+ 1 row in set (14.05 sec) ``` **Example dell’istanza database di lettura con `aurora_tmptable_enable_per_table_limit` impostato su `OFF`** Questa query raggiunge il limite di TempTable risorse globali se impostata su OFF. `aurora_tmptable_enable_per_table_limit` La query termina con un errore su istanze di lettura. ``` mysql> set aurora_tmptable_enable_per_table_limit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap; +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ | 1 | 3.04.0 | 0 | 1073741824 | 1073741824 | +--------------------+------------------+------------------------------------------+---------------------+----------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.01 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full ``` **Example dell'istanza database di lettura con `aurora_tmptable_enable_per_table_limit` impostato su `ON`** La query termina con un errore quando viene raggiunto il limite `tmp_table_size`. ``` mysql> set aurora_tmptable_enable_per_table_limit=1; Query OK, 0 rows affected (0.00 sec) mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size; +--------------------+------------------+------------------------------------------+------------------+ | @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size | +--------------------+------------------+------------------------------------------+------------------+ | 1 | 3.04.0 | 1 | 16777216 | +--------------------+------------------+------------------------------------------+------------------+ 1 row in set (0.00 sec) mysql> set cte_max_recursion_depth=4294967295; Query OK, 0 rows affected (0.00 sec) mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte; ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full ``` ## Mitigazione dei problemi di pienezza per le tabelle temporanee interne su repliche Aurora Per evitare problemi di limitazione delle dimensioni per le tabelle temporanee, impostare i parametri `temptable_max_ram` e `temptable_max_mmap` su un valore combinato in grado di soddisfare i requisiti del carico di lavoro. Presta attenzione durante l'impostazione del valore del parametro `temptable_max_ram`. L'impostazione di un valore troppo alto riduce la memoria disponibile sull'istanza del database, il che può causare una out-of-memory condizione. Monitora la memoria liberabile media sull'istanza database. Quindi determina un valore appropriato per `temptable_max_ram` in modo da avere ancora una quantità ragionevole di memoria libera sull'istanza. Per ulteriori informazioni, consulta [Problemi di memoria liberabile in Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory). È inoltre importante monitorare le dimensioni dello storage locale e il consumo temporaneo di spazio della tabella. Puoi monitorare lo storage temporaneo disponibile per una specifica istanza DB con il CloudWatch parametro `FreeLocalStorage` Amazon, descritto in[CloudWatch Parametri Amazon per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). **Nota** Questa procedura non funziona quando il parametro `aurora_tmptable_enable_per_table_limit` è impostato su `ON`. Per ulteriori informazioni, consulta [Limitazione delle dimensioni delle tabelle temporanee interne in memoria](#ams3-temptable-behavior-limit). **Example 1** È noto che le tabelle temporanee raggiungono una dimensione cumulativa di 20 GiB. Desideri impostare tabelle temporanee in memoria su 2 GiB e aumentare fino a un massimo di 20 GiB su disco. Imposta `temptable_max_ram` su **2,147,483,648** e `temptable_max_mmap` su **21,474,836,480**. Questi valori sono espressi in byte. Queste impostazioni dei parametri garantiscono che le dimensioni delle tabelle temporanee possano aumentare fino a un totale cumulativo di 22 GiB. **Example 2** La dimensione istanza corrente è 16xlarge o superiore. Non conosci le dimensioni totali delle tabelle temporanee che potrebbero essere richieste. Vuoi poter utilizzare fino a 4 GiB in memoria e fino alla dimensione di storage massima disponibile su disco. Imposta `temptable_max_ram` su **4,294,967,296** e `temptable_max_mmap` su **1,099,511,627,776**. Questi valori sono espressi in byte. Qui stai impostando `temptable_max_mmap` su 1 TiB, che è inferiore allo storage locale massimo di 1,2 TiB su un'istanza database di Aurora 16xlarge. Su una dimensione istanza più piccola, regola il valore di `temptable_max_mmap` in modo che non riempia lo storage locale disponibile. Ad esempio, un'istanza 2xlarge dispone solo di 160 GiB di storage locale disponibile. Pertanto, si consiglia di impostare su un valore inferiore a 160 GiB. Per ulteriori informazioni sullo storage locale disponibile per le dimensioni delle istanze database, consulta [Limiti di storage temporaneo per Aurora MySQLLimiti di storage temporaneo](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). ## Ottimizzazione del parametro temptable\$1max\$1mmap nelle istanze database di Aurora MySQL Il parametro `temptable_max_mmap` in Aurora MySQL controlla la quantità massima di spazio su disco locale che può essere utilizzata dai file mappati in memoria prima di eseguire l’overflow nelle tabelle temporanee InnoDB su disco (nelle istanze database di scrittura) o causare un errore (nelle istanze database di lettura). L’impostazione corretta di questo parametro dell’istanza database può aiutare a ottimizzare le prestazioni delle istanze database. **Prerequisiti** 1. Assicurarsi che lo schema delle prestazioni sia abilitato. È possibile verificarlo eseguendo il comando SQL seguente: ``` SELECT @@performance_schema; ``` Un valore di output di `1` indica che è abilitato. 1. Verificare che la strumentazione della memoria delle tabelle temporanee sia abilitata. È possibile verificarlo eseguendo il comando SQL seguente: ``` SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%'; ``` La colonna `enabled` mostra `YES` per le voci relative alla strumentazione della memoria delle tabelle temporanee. **Monitoraggio dell’utilizzo delle tabelle temporanee** Quando si imposta il valore iniziale per `temptable_max_mmap`, si consiglia di iniziare con l’80% della dimensione di archiviazione locale per la classe di istanze database che si sta utilizzando. Ciò garantisce che le tabelle temporanee dispongano di spazio su disco sufficiente per funzionare in modo efficiente, lasciando spazio per altri utilizzi del disco nell’istanza. Per trovare la dimensione di archiviazione locale per la classe di istanze database, consulta [Limiti di storage temporaneo per Aurora MySQLLimiti di storage temporaneo](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage). Ad esempio, se si utilizza la classe di istanze database db.r5.large, la dimensione di archiviazione locale è di 32 GiB. In questo caso, inizialmente si imposterà il parametro `temptable_max_mmap` sull’80% di 32 GiB, ovvero 25,6 GiB. Dopo aver impostato il valore `temptable_max_mmap` iniziale, eseguire il carico di lavoro di picco sulle istanze Aurora MySQL. Monitorare l’utilizzo corrente e massimo del disco delle tabelle temporanee utilizzando la seguente query SQL: ``` SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%'; ``` Questa query recupera le seguenti informazioni: + `event_name`: nome dell’evento relativo all’utilizzo della memoria o del disco delle tabelle temporanee. + `current_count`: numero corrente di blocchi di memoria o di disco allocati per le tabelle temporanee. + `current_alloc`: quantità corrente di memoria o disco allocata per le tabelle temporanee. + `current_avg_alloc`: dimensione media corrente dei blocchi di memoria o di disco per le tabelle temporanee. + `high_count`: numero massimo di blocchi di memoria o di disco allocati per le tabelle temporanee. + `high_alloc`: quantità massima di memoria o disco allocata per le tabelle temporanee. + `high_avg_alloc`: dimensione media massima dei blocchi di memoria o di disco per le tabelle temporanee. Se le query hanno esito negativo con un errore di tabella piena utilizzando questa impostazione, significa che il carico di lavoro richiede più spazio su disco per le operazioni sulle tabelle temporanee. In questo caso, valutare la possibilità di aumentare la dimensione dell’istanza database scegliendo un’istanza con più spazio di archiviazione locale. **Impostazione del valore `temptable_max_mmap` ottimale** Utilizzare la seguente procedura per monitorare e impostare la dimensione corretta per il parametro `temptable_max_mmap`. 1. Esaminare l’output della query precedente e individuare il picco di utilizzo del disco delle tabelle temporanee, come indicato dalla colonna `high_alloc`. 1. In base al picco di utilizzo del disco delle tabelle temporanee, modificare il parametro `temptable_max_mmap` nel gruppo di parametri di database per le istanze database di Aurora MySQL. Impostare il valore in modo che sia leggermente superiore al picco di utilizzo del disco delle tabelle temporanee per far fronte a incrementi futuri. 1. Applicare le modifiche al gruppo di parametri alle istanze database. 1. Monitorare nuovamente l’utilizzo del disco delle tabelle temporanee durante il picco di carico di lavoro per assicurarsi che il nuovo valore `temptable_max_mmap` sia appropriato. 1. Ripetere i passaggi precedenti se necessario per eseguire il fine-tuning del parametro `temptable_max_mmap`. ## Tabelle temporanee create dall'utente (esplicite) su istanze database di lettura Puoi creare tabelle temporanee esplicite utilizzando la parola chiave `TEMPORARY` nell'istruzione `CREATE TABLE`. Le tabelle temporanee esplicite sono supportate nell'istanza database di scrittura in un cluster di database Aurora. Puoi inoltre utilizzare tabelle temporanee esplicite sulle istanze database di lettura, ma le tabelle non possono applicare l'uso del motore di storage InnoDB. Per evitare errori durante la creazione di tabelle temporanee esplicite su istanze database di lettura di Aurora MySQL, assicurati che tutte le istruzioni `CREATE TEMPORARY TABLE` vengano eseguite in uno o entrambi i seguenti modi: + Non specificare la clausola `ENGINE=InnoDB`. + Non impostare la modalità SQL su `NO_ENGINE_SUBSTITUTION`. ## Errori di creazione tabelle temporanee e mitigazione L'errore che si riceve è diverso a seconda che si utilizzi una semplice istruzione `CREATE TEMPORARY TABLE` o la variazione `CREATE TEMPORARY TABLE AS SELECT`. Nell'esempio seguente vengono illustrati tipi diversi di errori. Questo comportamento temporaneo della tabella si applica solo alle istanze di sola lettura. Questo primo esempio conferma che è il tipo di istanza a cui è connessa la sessione. ``` mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+ ``` Per istruzioni semplici `CREATE TEMPORARY TABLE`, l'istruzione fallisce quando la modalità SQL `NO_ENGINE_SUBSTITUTION` è attivata. Quando `NO_ENGINE_SUBSTITUTION` è disattivato (impostazione predefinita), viene effettuata la sostituzione motore appropriata e la creazione della tabella temporanea ha esito positivo. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` Per le istruzioni `CREATE TEMPORARY TABLE AS SELECT`, l'istruzione ha esito negativo quando la modalità SQL `NO_ENGINE_SUBSTITUTION` è attivata. Quando `NO_ENGINE_SUBSTITUTION` è disattivato (impostazione predefinita), viene effettuata la sostituzione motore appropriata e la creazione della tabella temporanea ha esito positivo. ``` mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> show create table tt3; +-------+----------------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------------+ | tt3 | CREATE TEMPORARY TABLE `tt3` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +-------+----------------------------------------------------------+ 1 row in set (0.00 sec) ``` Per ulteriori informazioni sugli aspetti di storage e le implicazioni prestazionali delle tabelle temporanee in Aurora MySQL versione 3, consulta il post del blog [Use the TempTable storage engine on Amazon RDS for MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). # 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. # Confronto tra Aurora MySQL versione 3 e MySQL 8.0 Community Edition È possibile utilizzare le seguenti informazioni per conoscere le modifiche di cui essere a conoscenza quando si converte da un sistema diverso compatibile con MySQL 8.0 a Aurora MySQL versione 3. In generale, Aurora MySQL versione 3 supporta il set di funzionalità della community MySQL 8.0.23. Alcune nuove funzionalità dell'edizione della community di MySQL 8.0 non si applicano ad Aurora MySQL. Alcune di queste funzionalità non sono compatibili con alcuni aspetti di Aurora, come l'architettura di archiviazione Aurora. Non sono necessarie altre funzionalità perché il servizio di gestione Amazon RDS offre funzionalità equivalenti. Le seguenti funzionalità della community MySQL 8.0 non sono supportate o funzionano in modo diverso in Aurora MySQL versione 3. Per le note di rilascio di tutte le release di Aurora MySQL versione 3, consultare [Aggiornamenti del motore del database per Amazon Aurora MySQL versione 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) nelle *Note di rilascio di Aurora MySQL*. **Topics** + [Funzionalità di MySQL 8.0 non disponibili in Aurora MySQL versione 3](#AuroraMySQL.Compare-80-v3-features) + [Privilegio basato sui ruoli](#AuroraMySQL.privilege-model) + [Individuazione dell’ID server del database](#AuroraMySQL.server-id) + [Autenticazione](#AuroraMySQL.mysql80-authentication) ## Funzionalità di MySQL 8.0 non disponibili in Aurora MySQL versione 3 Le seguenti funzionalità della community MySQL 8.0 non sono disponibili o funzionano in modo diverso in Aurora MySQL versione 3. + I Resource groups e le istruzioni SQL associate non sono supportati in Aurora MySQL. + Aurora MySQL non supporta i tablespace di undo definiti dall’utente e le istruzioni SQL associate, come `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE` e `DROP UNDO TABLESPACE`. + Aurora MySQL non supporta il troncamento dei tablespace di undo per le versioni di Aurora MySQL precedenti alla 3.06. In Aurora MySQL versioni 3.06 e successive, è supportato il [troncamento automatico dei tablespace di undo](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace). + È supportato il plugin di convalida della password. + Non è possibile modificare le impostazioni dei plugin MySQL, incluso il plugin di convalida della password. + Il plugin X non è supportato. + La replica da più origini non è supportata. ## Privilegio basato sui ruoli Con Aurora MySQL versione 3, non è possibile modificare le tabelle direttamente nel database `mysql`. In particolare, non è possibile configurare gli utenti inserendoli nella tabella `mysql.user`. Invece, si utilizzano istruzioni SQL per concedere privilegi basati sui ruoli. Inoltre, nel database `mysql`, non è possibile creare altri tipi di oggetti come le stored procedure. È comunque possibile interrogare le tabelle di `mysql`. Se si utilizza la replica del registro binario, le modifiche apportate direttamente alle tabelle di `mysql` sul cluster fonte non vengono replicate nel cluster di destinazione. In alcuni casi, l'applicazione potrebbe utilizzare scorciatoie per creare utenti o altri oggetti inserendoli nelle tabelle di `mysql`. In tal caso, modifica il codice dell'applicazione per utilizzare le istruzioni corrispondenti come `CREATE USER`. Se l'applicazione crea stored procedure o altri oggetti nel database `mysql`, utilizzare un database di tipo diverso. Per esportare i metadati per gli utenti del database durante la migrazione da un database MySQL esterno, è possibile utilizzare il comando MySQL Shell anziché `mysqldump`. Per ulteriori informazioni, consulta [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). Per semplificare la gestione delle autorizzazioni per molti utenti o applicazioni, è possibile utilizzare l'istruzione `CREATE ROLE` per creare un ruolo con una serie di autorizzazioni. Puoi quindi utilizzare le istruzioni `GRANT` e `SET ROLE` e la funzione `current_role` per assegnare ruoli a utenti o applicazioni, cambiare il ruolo corrente e verificare quali ruoli sono in vigore. Per ulteriori informazioni sul sistema di autorizzazione basato sui ruoli in MySQL 8.0, consultare [Utilizzo di ruoli](https://dev.mysql.com/doc/refman/8.0/en/roles.html) nel Manuale di riferimento di MySQL. **Importante** Si consiglia di non utilizzare l'utente master direttamente nelle applicazioni. Rispetta piuttosto la best practice di utilizzare un utente del database creato con i privilegi minimi richiesti per l'applicazione. **Topics** + [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role) + [Utente con ruolo di controllo dei privilegi per la replica di log binari](#AuroraMySQL.privilege-model.binlog) + [Ruoli per l'accesso ad altri servizi AWS](#AuroraMySQL.privilege-model.other) ### rds\$1superuser\$1role Aurora MySQL versione 3 include un ruolo speciale che ha tutti i seguenti privilegi. Il ruolo è denominato `rds_superuser_role`. L'utente amministrativo principale per ciascun cluster ha già concesso questo ruolo. Il ruolo `rds_superuser_role` include i seguenti privilegi per tutti gli oggetti del database: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CONNECTION_ADMIN` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `FLUSH_OPTIMIZER_COSTS`(Aurora MySQL versione 3.09 e successive) + `FLUSH_STATUS`(Aurora MySQL versione 3.09 e successive) + `FLUSH_TABLES`(Aurora MySQL versione 3.09 e successive) + `FLUSH_USER_RESOURCES`(Aurora MySQL versione 3.09 e successive) + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW_ROUTINE` (Aurora MySQL versione 3.04 e successive) + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` La definizione del ruolo include anche la `WITH GRANT OPTION` in modo che un utente amministrativo possa concedere tale ruolo ad altri utenti. In particolare, l'amministratore deve concedere tutti i privilegi necessari per eseguire la replica del log binario con il cluster Aurora MySQL come destinazione. **Suggerimento** Per visualizzare i dettagli completi delle autorizzazioni, inserire le seguenti istruzioni. ``` SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%'; ``` ### Utente con ruolo di controllo dei privilegi per la replica di log binari Aurora MySQL versione 3 include un utente con ruolo di controllo dei privilegi per la replica dei log binari (binlog), ossia `rdsrepladmin_priv_checks_user`. Oltre ai privilegi di `rds_superuser_role`, questo utente dispone del privilegio `replication_applier`. Quando si attiva la replica binlog chiamando la stored procedure `mysql.rds_start_replication`, viene creato `rdsrepladmin_priv_checks_user`. L’utente `rdsrepladmin_priv_checks_user@localhost` è un utente riservato. Non modificarlo. ### Ruoli per l'accesso ad altri servizi AWS Aurora MySQL versione 3 include ruoli che è possibile utilizzare per accedere ad altri servizi. AWS È possibile impostare molti di questi ruoli come alternativa alla concessione di privilegi. Ad esempio, specificare `GRANT AWS_LAMBDA_ACCESS TO user` anziché`GRANT INVOKE LAMBDA ON *.* TO user`. Per le procedure di accesso ad altri AWS servizi, consulta. [Integrazione di Amazon Aurora MySQL con altri servizi AWS](AuroraMySQL.Integrating.md) Aurora MySQL versione 3 include i seguenti ruoli relativi all'accesso ad altri servizi: AWS + `AWS_LAMBDA_ACCESS`: alternativa al privilegio `INVOKE LAMBDA`. Per informazioni sull'utilizzo, consulta [Chiamare una funzione Lambda da un cluster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). + `AWS_LOAD_S3_ACCESS`: alternativa al privilegio `LOAD FROM S3`. Per informazioni sull'utilizzo, consulta [Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). + `AWS_SELECT_S3_ACCESS`: alternativa al privilegio `SELECT INTO S3`. Per informazioni sull'utilizzo, consulta [Salvataggio dei dati da un cluster DB Amazon Aurora MySQL nei file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). + `AWS_COMPREHEND_ACCESS`: alternativa al privilegio `INVOKE COMPREHEND`. Per informazioni sull'utilizzo, consulta [Concessione agli utenti del database dell'accesso a machine learning di Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_SAGEMAKER_ACCESS`: alternativa al privilegio `INVOKE SAGEMAKER`. Per informazioni sull'utilizzo, consulta [Concessione agli utenti del database dell'accesso a machine learning di Aurora](mysql-ml.md#aurora-ml-sql-privileges). + `AWS_BEDROCK_ACCESS`: non esiste un privilegio `INVOKE` analogo per Amazon Bedrock. Per informazioni sull'utilizzo, consulta [Concessione agli utenti del database dell'accesso a machine learning di Aurora](mysql-ml.md#aurora-ml-sql-privileges). Quando si concede l'accesso utilizzando i ruoli in Aurora MySQL versione 3, si attiva anche il ruolo utilizzando l'istruzione `SET ROLE role_name` o `SET ROLE ALL`. L’esempio seguente mostra come. Sostituire il nome del ruolo appropriato per `AWS_SELECT_S3_ACCESS`. ``` # Grant role to user. mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +-----------------------------------------------------+ | CURRENT_ROLE() | +-----------------------------------------------------+ | `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` | +-----------------------------------------------------+ ``` ## Individuazione dell’ID server del database L’ID del server del database (`server_id`) è necessario per la replica di log binari (binlog). Il metodo per l’individuazione dell’ID server è diverso in Aurora MySQL e in Community MySQL. In Community MySQL, l’ID server è un numero, che si ottiene utilizzando la seguente sintassi durante la connessione al server: ``` mysql> select @@server_id; +-------------+ | @@server_id | +-------------+ | 2 | +-------------+ 1 row in set (0.00 sec) ``` In Aurora MySQL, l’ID server è l’ID dell’istanza database, che si ottiene utilizzando la seguente sintassi durante la connessione all’istanza database: ``` mysql> select @@aurora_server_id; +------------------------+ | @@aurora_server_id | +------------------------+ | mydbcluster-instance-2 | +------------------------+ 1 row in set (0.00 sec) ``` Per ulteriori informazioni sulla replica binlog, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). ## Autenticazione Nella community MySQL 8.0, il plug-in di autenticazione di default è `caching_sha2_password`. Aurora MySQL versione 3 utilizza ancora il plug-in `mysql_native_password`. Non è possibile modificare l'impostazione `default_authentication_plugin`. Tuttavia, è possibile creare nuovi utenti e modificare gli utenti correnti; le password individuali degli utenti utilizzano il nuovo plugin di autenticazione. Di seguito è riportato un esempio. ``` mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword'; Query OK, 0 rows affected (0.74 sec) ``` # Aggiornamento ad Aurora MySQL versione 3 Per informazioni sull’aggiornamento del database da Aurora MySQL versione 2 alla versione 3, consulta [Aggiornamento della versione principale di un cluster di database Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md).