Aggiornamenti del motore di database Aurora MySQL 2025-05-14 (versione 3.09.0, compatibile con MySQL 8.0.40)

Prestazioni ottimizzate di aggiornamento delle versioni secondarie attraverso l'elaborazione parallela degli aggiornamenti dello schema delle prestazioni, riducendo la durata dell'aggiornamento quando sono necessarie modifiche allo schema delle prestazioni.

Database globali Aurora MySQL migliorati per consentire alle istanze di lettura secondarie di completare l'avvio e soddisfare le richieste di lettura durante eventi non pianificati (guasti hardware, interruzioni della rete). In precedenza, le istanze del lettore secondario non potevano riavviarsi durante tali eventi. Per ulteriori informazioni, consulta la resilienza interregionale per i cluster secondari di Global Database nella Guida per l'utente di Amazon Aurora.

Riduzione dei tempi di inattività della scrittura durante gli switchover interregionali di Aurora MySQL Database a meno di un minuto, riducendo al minimo i tempi di inattività durante gli switch regionali pianificati.

CVE-2024-11053

CVE-2024-37371

CVE-2024-7264

CVE-2024-21193

CVE-2024-21194

CVE-2024-21196

CVE-2024-21197

CVE-2024-21198

CVE-2024-21199

CVE-2024-21201

CVE-2024-21203

CVE-2024-21207

CVE-2024-21212

CVE-2024-21213

CVE-2024-21218

CVE-2024-21219

CVE-2024-21230

CVE-2024-21236

CVE-2024-21238

CVE-2024-21239

CVE-2024-21241

CVE-2025-21494

CVE-2025-21504

CVE-2025-21525

CVE-2025-21534

CVE-2025-21536

È stato risolto un problema per cui le query con più istruzioni inoltrate dalle istanze Reader a Writer potevano bloccarsi quando innodb_flush_log_at_trx_commit era impostata su on the writer e diversa da zero 0 sul reader, prevenendo potenziali errori di inoltro della scrittura.

È stato risolto un problema di deadlock con Enhanced Binlog abilitato che poteva causare il riavvio del database durante l'esecuzione SHOW BINARY LOGS simultanea del commit delle transazioni sui motori BLACKHOLE o dell'esecuzione di istruzioni, evitando potenziali scritture bloccate e problemi di disponibilità delle istanze. XA PREPARE

Sono state corrette le condizioni di gara nell'inoltro di scrittura che potevano causare il riavvio dell'istanza di Aurora writer impedendo l'accettazione di nuove richieste prima del completamento completo delle richieste precedenti, migliorando la stabilità delle operazioni di inoltro di scrittura.

È stato risolto un problema sulla replica a causa del quale un'interruzione di rete poteva non ristabilire correttamente la connessione con il writer, causando il blocco della replica e il potenziale riavvio dell'istanza.

La risposta Aurora MySQL Out of Memory (OOM) ora implementa il ridimensionamento a fasi del pool di buffer che riduce gradualmente l'utilizzo della memoria in base allo stato della memoria di sistema (LOW/RESERVED) quando abilitato tramite il parametro DB, offrendo una migliore gestione della memoria durante le situazioni di pressione della memoria. aurora_oom_response

È stato migliorato il tempo di ripristino dei file Binlog durante il riavvio del database ottimizzando il processo di ripristino in modo che richieda un tempo costante indipendentemente dalla dimensione del file Binlog. In precedenza, in alcuni casi, il tempo di ripristino era proporzionale alla dimensione dell'ultimo file Binlog.

È stato risolto un problema che poteva causare riavvii imprevisti del server MySQL durante l'esecuzione simultanea di operazioni di troncamento delle tabelle InnoDB durante l'interrogazione. performance_schema.data_lock_waits

È stato risolto un problema che poteva causare il riavvio di un'istanza di database quando si eseguivano eventi binlog di grandi dimensioni in condizioni di scarsa archiviazione.

È stato risolto un problema a causa del quale le operazioni di ridimensionamento del pool di buffer attivate durante la prevenzione dell'esaurimento della memoria (OOM) potevano non rispondere durante scenari con carichi di lavoro elevati, con conseguente possibile riavvio del database.

È stato risolto un problema che poteva causare un ciclo di riavvio del database durante la creazione di un trigger. Il problema può verificarsi anche quando viene aggiunto un nuovo file Binlog o Relaylog o quando questi file ruotano.

È stato risolto un problema che poteva causare il riavvio dell'istanza del lettore Aurora quando si utilizzava l'inoltro di scrittura con query di commit implicite o a più istruzioni.

È stato risolto un problema per cui ALTER TABLE ... REBUILD / OPTIMIZE TABLE le operazioni potevano consumare una quantità eccessiva di memoria allocando innodb_ddl_buffer_size byte per thread DDL anziché dividere la dimensione del buffer tra i thread, impedendo il potenziale utilizzo eccessivo della memoria durante le operazioni DDL.

È stato modificato il valore predefinito peraurora_oom_response, su tutte le classi di istanze DB che hanno più di 4 GiB di memoria, da print a print, decline, kill_connect. Per ulteriori informazioni, consulta i problemi relativi ad Amazon Aurora MySQL nella Guida per out-of-memory l'utente di Amazon Aurora.

I seguenti privilegi sono stati aggiunti a:,,,rds_superuser_role. FLUSH_OPTIMIZER_COSTS FLUSH_STATUS FLUSH_TABLES FLUSH_USER_RESOURCES Per informazioni surds_superuser_role, consulta la documentazione relativa agli account utente Amazon Master con Amazon Aurora. Per ulteriori informazioni su questi privilegi dinamici, consulta la documentazione MySQL.

L'ottimizzazione rapida degli inserti non è più abilitata a partire da questa versione di Aurora MySQL. Per informazioni Aurora, consulta Miglioramenti alle prestazioni di Amazon Aurora MySQL nella Guida per l'utente di Amazon Aurora.

È stato risolto un problema relativo a una violazione errata della max_user_connections soglia, che causava errori di connessione per alcuni utenti. Ciò si verifica in alcuni casi limite, ad esempio quando le connessioni vengono create e interrotte quasi immediatamente.

È stato risolto un problema di registrazione di controllo che causava un elevato utilizzo della CPU, con conseguente mancata risposta dell'istanza del server di database.

È stato risolto un problema di gestione della memoria durante l'utilizzo di transazioni XA, che impediva il possibile riavvio dell'istanza quando Enhanced Binlog era abilitato.

È stato risolto un problema a causa del quale le prestazioni delle query peggioravano quando l'ottimizzatore effettuava stime dei costi errate a causa dell'aggiornamento errato delle statistiche dell'indice di Bufferpool dopo il riavvio del server del database.

È stato risolto un problema che impediva ai clienti di disattivare la funzionalità di inoltro di scrittura locale a causa di un thread di lavoro bloccato.

È stato risolto un problema a causa del quale l'esecuzione del SHOW BINARY LOGS comando richiedeva più tempo in un cluster in cui Enhanced Binlog era abilitato o era abilitato in precedenza. Questo problema potrebbe anche causare un aumento della latenza di commit se più SHOW BINARY LOGS comandi venivano eseguiti contemporaneamente.

È stato risolto un problema per cui Zero Downtime Patching (ZDP) poteva avere esito negativo durante il tentativo di preservare la connessione, appartenente a un utente che era stato interrotto. Ulteriori informazioni sul DROP USER comando e sul suo effetto sulle connessioni attive sono disponibili nella documentazione di MySQL.

Mentre venivano ricevute e applicate transazioni di grandi dimensioni e veniva effettuata una richiesta di interruzione del canale di replica utilizzandoSTOP REPLICA, MySQL non lo faceva correttamente e successivamente non elaborava alcun comando di canale. Inoltre, il processo di spegnimento del server non è stato completato correttamente e ha richiesto l'interruzione del processo MySQL o il riavvio del sistema host. (Bug #115966, Bug #37008345)