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 8.4.8, 3 settembre 2026
**Versione**: 8.4.8
Questa versione di Aurora MySQL è compatibile con MySQL 8.4.8. Per ulteriori informazioni sulle modifiche apportate alla community, consulta le note di rilascio di MySQL 8.4 sul sito Web di [ MySQL. ](https://dev.mysql.com/doc/relnotes/mysql/8.4/en/)
Per i dettagli sulle nuove funzionalità di Aurora MySQL versione 8.4, vedi [ Aurora MySQL versione 8.4 compatibile con MySQL 8.4. ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL84.html) Per le differenze tra Aurora MySQL versione 8.4 e versione 3, vedi Confronto tra Aurora MySQL versione 3 e Aurora MySQL versione 8.4. [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v3-v84.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v3-v84.html) Per un confronto con MySQL 8.4 Community Edition, consulta il confronto tra Aurora MySQL versione 8.4 e MySQL 8.4 Community Edition nella [ Amazon Aurora User Guide. ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v84-community.html) * *
Puoi eseguire un aggiornamento della versione principale sul posto, ripristinare un'istantanea con l'upgrade o avviare un aggiornamento gestito utilizzando Amazon RDS Deployments. blue/green [ Blue/Green ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html) Puoi eseguire l'upgrade da qualsiasi cluster Aurora MySQL versione 3 attualmente supportato ad Aurora MySQL versione 8.4.8.
Per informazioni sulla pianificazione di un aggiornamento ad Aurora MySQL versione 8.4, consulta Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL. [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Planning](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Planning) Per informazioni generali sugli aggiornamenti di Aurora MySQL, consulta [Aggiornamento dei cluster database Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html) nella *Guida per l'utente di Amazon Aurora*.
Per informazioni sulla risoluzione dei problemi, consulta [ Troubleshooting for Aurora MySQL in-place upgrade nella Amazon Aurora User Guide. ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting) * *
In caso di domande o dubbi, l' AWS assistenza è disponibile nei forum della community e tramite Support. [AWS](https://aws.amazon.com/support) Per ulteriori informazioni, consulta [ Maintaining an Aurora DB cluster ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) nella * Amazon Aurora User Guide. *
## Nuove funzionalità
+ È stato aggiunto il supporto per la replica di log binari (binlog) da più fonti. Questa funzionalità consente a un cluster Aurora MySQL DB di replicare i dati da più database di origine contemporaneamente MySQL-compatible . Ogni connessione di origine è gestita tramite un canale di replica dedicato con il proprio thread di ricezione, thread di applicazione e log di inoltro. È possibile configurare e gestire i canali utilizzando nuove stored procedure per canale. Per ulteriori informazioni, consulta [ Using multi-source replication with Aurora MySQL ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MultiSource.html) nella Amazon Aurora User Guide. * *
+ È stato aggiunto il supporto per la replica differita dei log binari (binlog), in cui un cluster DB Aurora MySQL che funge da replica binlog può essere configurato per attendere un determinato numero di secondi prima di applicare le transazioni ricevute dall'origine. La replica ritardata può essere utilizzata per proteggersi da modifiche accidentali dei dati, ad esempio `DELETE` dichiarazioni `DROP TABLE` o involontarie, offrendo una finestra di ripristino per identificare e correggere gli errori prima che si propaghino nella replica. Per ulteriori informazioni, consulta [ Configurazione dell'intervallo di ritardo della replica nella Amazon Aurora User Guide. ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.Delayed.html) * *
+ Introdotto il parametro. `aurora_transaction_timeout` Questo parametro imposta la durata massima, in secondi, per una transazione InnoDB. È possibile utilizzare questo parametro per evitare che transazioni di lunga durata (attive o inattive) blocchino l'eliminazione di InnoDB, il che può portare a problemi di prestazioni. Per ulteriori informazioni, consulta [ Aurora MySQL transaction timeout ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.TransactionTimeout.html) nella Amazon Aurora User Guide. * *
+ È stato aggiunto il supporto per lo scambio di chiavi ibrido post-quantistico (X25519MLKEM768 e SECP256R1MLKEM768) per le connessioni TLS 1.3. I client che supportano lo scambio di chiavi post-quantistico negoziano automaticamente un segreto condiviso resistente ai livelli quantistici. Per confermare il gruppo negoziato dalla sessione corrente, interroga la variabile di stato. `Aurora_ssl_named_group` Ad esempio: `SHOW STATUS LIKE 'Aurora_ssl_named_group';`.
## Miglioramenti
Di seguito sono riportati i miglioramenti apportati rispetto ad Aurora MySQL 8.4.7, vedi [ le note di rilascio di Aurora MySQL 8.4.7. ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.847.html)
### Correzioni di sicurezza
+ È stato risolto un problema per cui il log di Advanced Audit registrava un utente e un host errati per le istruzioni SQL eseguite all'interno di una routine SQL SECURITY DEFINER (procedura memorizzata, funzione o trigger). Questi record mostravano l'utente e l'host che definiscono la routine (ad esempio`'user'@'%'`) anziché il client SQL che richiamava la routine. Dopo questa correzione, i record mostrano l'utente e l'host del client SQL richiamante.
+ È stato risolto un problema per cui le interrogazioni eseguite tramite istruzioni preparate potevano generare voci duplicate nel registro di Advanced Audit.
+ È stato risolto un problema `SET ROLE NONE` che impediva di cancellare correttamente i privilegi di un ruolo precedentemente attivo nelle sessioni utilizzando l'inoltro della scrittura, che poteva consentire operazioni che avrebbero dovuto essere negate dopo la disattivazione del ruolo.
Questa versione include correzioni per i seguenti CVE ad alta gravità:
+ [CVE-2026-46863](https://www.cve.org/CVERecord?id=CVE-2026-46863)
+ [CVE-2026-60163](https://www.cve.org/CVERecord?id=CVE-2026-60163)
+ [CVE-2026-61094](https://www.cve.org/CVERecord?id=CVE-2026-61094)
Questa versione include correzioni per i seguenti CVE di gravità media:
+ [CVE-2026-21936](https://www.cve.org/CVERecord?id=CVE-2026-21936)
+ [CVE-2026-21937](https://www.cve.org/CVERecord?id=CVE-2026-21937)
+ [CVE-2026-21941](https://www.cve.org/CVERecord?id=CVE-2026-21941)
+ [CVE-2026-21948](https://www.cve.org/CVERecord?id=CVE-2026-21948)
+ [CVE-2026-21968](https://www.cve.org/CVERecord?id=CVE-2026-21968)
+ [CVE-2026-60585](https://www.cve.org/CVERecord?id=CVE-2026-60585)
+ [CVE-2026-60332](https://www.cve.org/CVERecord?id=CVE-2026-60332)
+ [CVE-2026-60331](https://www.cve.org/CVERecord?id=CVE-2026-60331)
+ [CVE-2026-60747](https://www.cve.org/CVERecord?id=CVE-2026-60747)
+ [CVE-2026-47023](https://www.cve.org/CVERecord?id=CVE-2026-47023)
+ [CVE-2026-60186](https://www.cve.org/CVERecord?id=CVE-2026-60186)
+ [CVE-2026-60184](https://www.cve.org/CVERecord?id=CVE-2026-60184)
+ [CVE-2026-60185](https://www.cve.org/CVERecord?id=CVE-2026-60185)
+ [CVE-2026-60187](https://www.cve.org/CVERecord?id=CVE-2026-60187)
+ [CVE-2026-60188](https://www.cve.org/CVERecord?id=CVE-2026-60188)
+ [CVE-2026-60189](https://www.cve.org/CVERecord?id=CVE-2026-60189)
+ [CVE-2026-60191](https://www.cve.org/CVERecord?id=CVE-2026-60191)
Questa versione include correzioni per i seguenti CVE a bassa gravità:
+ [CVE-2026-60190](https://www.cve.org/CVERecord?id=CVE-2026-60190)
### Miglioramenti della disponibilità
+ È stato risolto un problema che poteva causare il riavvio dell'istanza del database durante l'esecuzione `ALTER TABLE ... REORGANIZE PARTITION` o `ADD PARTITION` durante l'accesso alla stessa tabella di operazioni simultanee (come query sullo schema delle prestazioni, ottimizzazione della ricerca full-text o raccolta di statistiche). `DROP PARTITION`
+ È stato risolto un problema che può causare il riavvio dell'istanza del database quando le query vengono `performance_schema.data_locks` eseguite `performance_schema.data_lock_waits` o eseguite contemporaneamente `ALTER TABLE ... REORGANIZE PARTITION` su tabelle a cui sono state aggiunte colonne utilizzando. `ALGORITHM=INSTANT`
+ È stato risolto un problema che poteva causare il riavvio dell'istanza del writer durante l'elaborazione di un'istruzione `ALTER TABLE ... REORGANIZE PARTITION` SQL che modifica l'ordine delle partizioni secondarie.
+ È stato risolto un problema per cui le operazioni DDL sull'istanza writer potevano bloccare o eliminare determinate istruzioni SQL sulle istanze del lettore. Le istruzioni interessate includevano operazioni di scrittura come `UPDATE` o `TRUNCATE` su `performance_schema` tabelle e operazioni di scrittura su tabelle e `JOIN` operazioni temporanee.
+ È stato risolto un problema a causa del quale l'istanza del database writer poteva riavviarsi in modo imprevisto durante un'operazione di passaggio globale al database durante la pulizia delle tabelle temporanee dopo l'elaborazione delle istruzioni SQL. Questo riavvio poteva comportare un allungamento del tempo di completamento dello switchover.
+ È stato risolto un problema che poteva causare l'interruzione dell'inoltro di scrittura su un'istanza DB del lettore, richiedendo il riavvio del lettore per ripristinare l'inoltro di scrittura. Ciò poteva verificarsi quando una query inoltrata veniva annullata o scaduta durante l'utilizzo dell'inoltro di scrittura globale o dell'inoltro di scrittura locale.
+ È stato risolto un problema per cui un ritardo nel ridimensionamento della struttura dei dati critici durante le operazioni di ridimensionamento poteva causare il riavvio dell'istanza del database da parte del Aurora serverless monitoraggio dello stato di RDS.
+ È stato risolto un problema che poteva causare il riavvio dell'istanza di scrittura a causa di un conflitto di temporizzazione interno durante operazioni di scrittura molto simultanee.
+ È stato risolto un problema che poteva causare il riavvio di un'istanza di database quando il binlog avanzato è abilitato.
+ È stato corretto un bug che poteva far sì che la replica si disconnettesse e si riconnettesse brevemente al writer, causando un picco temporaneo nel ritardo di replica (). `AuroraReplicaLag`
+ È stato risolto un problema in Aurora Storage Daemon che in rari casi poteva causare un riavvio imprevisto del database.
### Miglioramenti generali
+ È stato risolto un problema per cui, con l'inoltro di scrittura abilitato, una sessione di lettura `aurora_replica_read_consistency` impostata su ha `global` potuto non leggere le ultime modifiche apportate.
+ È stato risolto un problema che poteva causare il riavvio del motore quando un'interrogazione GIS spaziale utilizza un indice Z-order spaziale su una colonna dichiarata con un'annotazione SRID esplicita.
+ È stato risolto un problema per cui le disconnessioni del lettore potevano aumentare `Aborted_clients` erroneamente sull'istanza di scrittura quando l'inoltro in scrittura è abilitato.
+ È stato risolto un problema per cui, in alcuni casi, lo stato della connessione non veniva mantenuto dopo un aggiornamento senza tempi di inattività, il che poteva causare un comportamento imprevisto.
+ È stato risolto un problema per cui, durante l'inoltro in scrittura, il riavvio di un'istanza del lettore poteva lasciare inattiva una sessione di inoltro sull'istanza di scrittura e l'interruzione di tale sessione poteva causare il riavvio del writer.
+ Riduzione dei tempi di inattività durante lo zero-downtime patching (ZDP) ottimizzando la comunicazione tra l'istanza del database e il livello di storage dopo l'applicazione delle patch.
+ È stato risolto un problema relativo alla gestione della memoria di Aurora MySQL per cui le azioni di risposta in esaurimento della memoria (OOM) non venivano disattivate in modo affidabile dopo un periodo di timeout interno, in caso di modifica simultanea del valore del parametro DB. `aurora_oom_response`
+ È stato risolto un problema in Enhanced Binlog che segnalava coordinate di log binarie errate dopo il ripristino di un'istantanea. In precedenza, ciò poteva comportare una configurazione di replica binlog non valida quando Enhanced Binlog era in esecuzione sul cluster di origine e veniva eseguito il rollback di alcune transazioni.
+ È stato risolto un problema nella funzionalità di ripristino con incremento automatico per cui i valori di incremento automatico per le tabelle partizionate non venivano ripristinati correttamente, il che poteva portare a potenziali errori DUPLICATE KEY.
+ È stata aggiunta una nuova CloudWatch metrica`AuroraTempTableVolumeTotalBytes`, che riporta i byte totali del volume del cluster utilizzati dai tablespace temporanei InnoDB interni ed esterni sulle istanze di writer. Questa metrica riporta il consumo temporaneo di storage del tablespace in tutte le sessioni attive. Puoi utilizzarla per monitorare le tendenze di crescita, identificare carichi di lavoro che richiedono molto spazio di archiviazione e impostare allarmi. CloudWatch Per ulteriori informazioni su questa metrica, consulta le metriche di Amazon per [ Amazon CloudWatch Aurora nella Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) User Guide. * * Per ulteriori informazioni sulle tabelle temporanee, consulta le tabelle temporanee [ esterne ](https://dev.mysql.com/doc/refman/8.4/en/create-temporary-table.html) e le tabelle temporanee [ interne ](https://dev.mysql.com/doc/refman/8.4/en/internal-temporary-tables.html) sul sito Web MySQL.
+ È stato risolto un problema per cui le metriche di trasmissione in scrittura e latenza riportavano erroneamente 0 dopo un evento di failover sui cluster con l'inoltro di scrittura abilitato. Queste metriche ora riflettono accuratamente l'attività di inoltro di scrittura a seguito di un failover:,, e. `ForwardingReplicaDMLLatency` `ForwardingReplicaDMLThroughput` `ForwardingReplicaSelectLatency` `ForwardingReplicaSelectThroughput`
+ È stato risolto un problema di prestazioni per cui l'ottimizzatore seleziona un piano di esecuzione delle query non ottimale con istruzioni preparate che utilizzano valori parametrizzati. `IN`
+ È stato risolto un problema che poteva far sì che le query che utilizzano hash join restituissero risultati errati quando la query parallela è abilitata e la memoria richiesta per un hash join supera il limite.
### Aggiornamenti e migrazioni
+ È stato risolto un problema che poteva causare il completamento delle operazioni di clonazione del cluster di database.
## Integrazione delle correzioni di bug di MySQL Community Edition
Questa versione è basata su MySQL 8.4.8. Per ulteriori informazioni, consulta le note di rilascio di [ MySQL 8.4 sul sito Web MySQL. ](https://dev.mysql.com/doc/relnotes/mysql/8.4/en/)
+ È stata corretta una regressione introdotta in MySQL 8.0.42 per cui l'inserimento in una tabella partizionata utilizzando un'istruzione preparata o una stored procedure poteva fallire («Trovata una riga che non corrisponde al set di partizioni specificato»). `ERROR 1748` Ciò si è `DEFAULT CURRENT_TIMESTAMP` verificato quando viene utilizzata la colonna della chiave di partizione. L'eliminazione delle partizioni in fase di preparazione ha bloccato una partizione in base al timestamp corrente, ma alla successiva riesecuzione il timestamp potrebbe essere associato a una partizione diversa. Per ulteriori informazioni su questa correzione, consulta MySQL upstream Bug \#119784 sul sito Web MySQL Bugs. [https://bugs.mysql.com/bug.php?id=119784](https://bugs.mysql.com/bug.php?id=119784)