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à.
# Aggiornamenti del motore di database Aurora MySQL 11/09/2020 (versione 1.22.3) (obsoleta)
**Versione:** 1.22.3
Aurora MySQL 1.22.3 è disponibile a livello generale. Le versioni 1.\$1 di Aurora MySQL sono compatibili con MySQL 5.6, mentre le versioni 2.\$1 di Aurora MySQL sono compatibili con MySQL 5.7.
Questa versione del motore è pianificata per essere resa obsoleta il 28 febbraio 2023. Per ulteriori informazioni, consulta [Preparazione per la fine del ciclo di vita di Amazon Aurora edizione compatibile con MySQL versione 1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Le versioni di Aurora MySQL attualmente supportate sono 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 e 3.02.\$1.
Per creare un cluster con una versione precedente di Aurora MySQL, specifica la versione del motore tramite la console RDS, la AWS CLI o l'API Amazon RDS.
**Nota**
Questa versione è designata come versione di supporto a lungo termine (LTS). Per ulteriori informazioni, consulta [Versioni con supporto a lungo termine (Long-Term Support, LTS) di Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) nella *Guida per l'utente di Amazon Aurora.*
In caso di domande o dubbi, l' AWS assistenza è disponibile nei forum della community e tramite [AWS Support](https://aws.amazon.com/support). Per ulteriori informazioni, consulta [Manutenzione di un cluster database Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) nella *Guida per l'utente di Amazon Aurora*.
## Miglioramenti
**Correzioni di sicurezza:**
Correzioni e altri miglioramenti per ottimizzare la gestione in un ambiente gestito. Ulteriori correzioni CVE riportate di seguito:
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
+ [CVE-2020-2579](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2579)
+ [CVE-2020-2812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2812)
+ [CVE-2020-2780](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2780)
+ [CVE-2020-2763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2763)
**Modifiche non compatibili:**
Questa versione introduce una modifica dell'autorizzazione che influisce sul comportamento del `mysqldump` comando. Gli utenti devono disporre del `PROCESS` privilegio per accedere alla `INFORMATION_SCHEMA.FILES` tabella. Per eseguire il `mysqldump` comando senza alcuna modifica, concedere il `PROCESS` privilegio all'utente del database a cui si connette il `mysqldump` comando. Inoltre puoi eseguire il`mysqldump`comando con l'`--no-tablespaces`opzione. Con questa opzione,l'`mysqldump `output non include alcuna`CREATE LOGFILE GROUP`o`CREATE TABLESPACE`istruzioni. In tal caso, il `mysqldump` comando non accede alla `INFORMATION_SCHEMA.FILES` tabella e non è necessario che tu conceda l' `PROCESS` autorizzazione.
**Miglioramenti della disponibilità:**
+ Risolti i problemi che potevano causare il riavvio del server durante il ripristino di un'istruzione DDL di cui non era stato eseguito il commit.
+ Risolte le race condition nel gestore dei blocchi che possono causare il riavvio del server.
+ Risolto un problema per il quale l'agente di monitoraggio riavviava il server durante il ripristino di una transazione di grandi dimensioni
**Miglioramenti generali:**
+ Modificato il comportamento da mappare `MIXED` `binlog_format` a `ROW` invece che `STATEMENT` durante l'esecuzione di `LOAD DATA FROM INFILE | S3`.
+ Risolto un problema per cui una replica binlog connessa a un binlog primario di Aurora MySQL potrebbe mostrare dati incompleti quando il primario ha eseguito `LOAD DATA FROM S3` e `binlog_format` è impostato su `STATEMENT`.
## Integrazione delle correzioni di bug della community di MySQL
+ Bug 26654685: Un ID indice danneggiato rilevato durante un controllo di chiave esterna generava un'asserzione
+ Bug 15831300: Per impostazione predefinita, quando si promuovono numeri interi da un tipo più piccolo sul master a un tipo più grande sullo slave (ad esempio, da una colonna [SMALLINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) sul master a una colonna [BIGINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) sullo slave), i valori promossi vengono trattati come se fossero firmati. Ora in questi casi è possibile modificare o sovrascrivere questo comportamento utilizzando uno o entrambi `ALL_SIGNED`, `ALL_UNSIGNED` nell'insieme di valori specificati per la variabile di sistema server [slave\$1type\$1conversions](https://dev.mysql.com/doc/refman/5.6/en/replication-options-replica.html#sysvar_slave_type_conversions) . Per ulteriori informazioni, consultare [Replica basata su righe: promozione e riduzione di livello degli attributi](https://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html#replication-features-attribute-promotion), nonché la descrizione della variabile.
+ Bug 17449901: Con `foreign_key_checks=0`, InnoDB consentiva l'eliminazione di un indice richiesto da un vincolo di chiave esterna, posizionando la tabella in uno stato incoerente e causando il fallimento del controllo della chiave esterna che si verifica al caricamento della tabella. Ora InnoDB impedisce di eliminare un indice richiesto da un vincolo di chiave esterna, anche con foreign\$1key\$1checks=0. Il vincolo di chiave esterna deve essere rimosso prima di eliminare l'indice di chiave esterna.
+ BUG n. 20768847: Una operazione [ALTER TABLE ... DROP INDEX](https://dev.mysql.com/doc/refman/5.7/en/alter-table.html) su una tabella con dipendenze da chiavi esterne ha generato un’asserzione.