Aurora MySQL 8.4.8, 3 settembre 2026

È 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 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.

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 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';.

È 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.

CVE-2026-46863

CVE-2026-60163

CVE-2026-61094

CVE-2026-21936

CVE-2026-21937

CVE-2026-21941

CVE-2026-21948

CVE-2026-21968

CVE-2026-60585

CVE-2026-60332

CVE-2026-60331

CVE-2026-60747

CVE-2026-47023

CVE-2026-60186

CVE-2026-60184

CVE-2026-60185

CVE-2026-60187

CVE-2026-60188

CVE-2026-60189

CVE-2026-60191

CVE-2026-60190

È 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.

È 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 metricaAuroraTempTableVolumeTotalBytes, 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 User Guide. Per ulteriori informazioni sulle tabelle temporanee, consulta le tabelle temporanee esterne e le tabelle temporanee interne 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.

È stato risolto un problema che poteva causare il completamento delle operazioni di clonazione del cluster di database.

È 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