Aggiornamenti del motore del database di Aurora MySQL 25/10/2023 (versione 3.05.0, compatibile con MySQL 8.0.32)

È stato aggiunto il supporto per il salvataggio dei dati da un cluster di database Aurora MySQL nei file di testo in un bucket Amazon S3 crittografato con una chiave KMS (SSE-KMS). Per ulteriori informazioni, consulta Salvataggio dei dati da un cluster DB Amazon Aurora MySQL nei file di testo in un bucket Amazon S3.

È stata introdotta una nuova variabile di stato globale aurora_tmz_version per indicare la versione corrente delle informazioni sul fuso orario (TZ) utilizzate dal motore. I valori seguono la versione del database dei fusi orari IANA e sono formattati come "YYYYsuffix«, ad esempio 2022a e 2023c. Per ulteriori informazioni, consulta Variabili di stato globali di Aurora MySQL.

CVE-2022-37434

È stato risolto un problema per cui le istanze database di Aurora MySQL che utilizzavano query parallele potevano subire un riavvio del database durante l'esecuzione di un numero elevato di query parallele simultanee.

È stato risolto un problema di conflitto di blocchi causato da un thread di log di audit che alla fine portava a un utilizzo elevato della CPU e al timeout delle applicazioni client.

È stato risolto un problema che poteva causare il ripristino errato del set GTID eseguito su un cluster di replica di log binario (binlog) con binlog avanzato abilitato quando qualsiasi origine binlog disponeva di gtid_mode impostata su ON o ON_PERMISSIVE. Questo problema può causare il riavvio dell'istanza di scrittura del cluster di replica un'ulteriore volta durante il ripristino o portare a risultati errati durante l'esecuzione di query sul set GTID eseguito.

È stato risolto un problema di gestione della memoria che può causare il riavvio di un'istanza database Aurora MySQL o un failover a causa di una diminuzione della memoria liberabile quando è abilitato il log binario avanzato.

È stato risolto un problema che può causare il riavvio di un'istanza database quando si tenta di leggere una pagina del database che appartiene a una tabella eliminata.

È stato risolto un problema che può causare il riavvio dell'istanza di lettura quando l'istanza di scrittura aumenta il volume del database fino a un multiplo di 160 GB.

È stato risolto un problema a causa del quale un'istanza database Aurora MySQL con la funzionalità di registro binario avanzata abilitata poteva rimanere bloccata durante l'avvio dell'istanza database durante l'esecuzione del processo di ripristino del registro binario.

È stato risolto un problema per cui un'istanza database Aurora MySQL poteva subire più riavvii durante l'avvio dell'istanza mentre venivano inizializzati segmenti di rollback di grandi dimensioni.

È stato risolto un problema durante l'applicazione di patch senza tempi di inattività che causava il riavvio dell'istanza con conseguente chiusura imprevista delle connessioni al database.

È stato risolto un problema che poteva causare il riavvio di un'istanza database a causa di un deadlatch quando si eseguivano contemporaneamente le istruzioni SHOW STATUS e PURGE BINARY LOGS. L'eliminazione dei log binari è un'istruzione gestita che viene eseguita per rispettare il periodo di conservazione di binlog configurato dall'utente.

È stato risolto un problema che poteva causare la non disponibilità del cluster di database al riavvio dell'istanza di scrittura mentre il database stava creando o eliminando i trigger sulle tabelle di sistema interne.

È stato risolto un problema che può causare il riavvio di un'istanza database a causa di una lunga attesa del semaforo quando si utilizza la funzionalità binlog avanzata su un cluster con una replica Aurora.

È stato risolto un problema che può causare il riavvio di un'istanza database durante l'esecuzione di una query che fa riferimento a una funzione di aggregazione.

È stato risolto un problema che, in rare condizioni, può causare il riavvio dell'istanza del database quando Aurora Serverless v2 tenta erroneamente di aggiornare la cache della tabella durante il ridimensionamento.

È stato risolto un problema per cui i metodi di accesso alla scansione degli indici non supportati venivano presi in considerazione per le espressioni di tabella comuni (CTE) durante la materializzazione di tabelle temporanee intermedie, il che poteva portare a comportamenti indesiderati, tra cui riavvii del database o risultati di query errati. Abbiamo risolto questo problema evitando l'uso di tali metodi di accesso alla scansione degli indici non supportati sulle tabelle che utilizzano il TempTable motore di archiviazione.

È stato risolto un problema che può causare l'indisponibilità del database quando il binlog avanzato è abilitato su un Aurora Serverless v2 cluster di database in esecuzione su Aurora MySQL 3.04.0.

Sono stati rimossi i metadati di archiviazione non utilizzati prima di scrivere sull'archiviazione di Aurora quando è abilitata la funzionalità binlog avanzato. Ciò evita determinati scenari in cui potrebbe verificarsi un riavvio o un failover del database a causa della maggiore latenza di scrittura dovuta all'aumento dei byte trasmessi sulla rete.

Con l'aggiunta delle tabelle malloc_stats e malloc_stats_totals in performance_schema, sono state aggiunte tre variabili di sistema avanzate per controllare il comportamento di Jemalloc, un allocatore di memoria interno:

È stato risolto un problema per cui le tabelle degli schemi delle prestazioni specifiche di Aurora non venivano create durante un aggiornamento o una migrazione.

È stata aggiunta una nuova variabile di sistema, aurora_use_vector_instructions. Quando questo parametro è abilitato, Aurora MySQL utilizza istruzioni di elaborazione vettoriale ottimizzate per migliorare le prestazioni su carichi di lavoro I/O pesanti. Questa impostazione è ON per impostazione predefinita in Aurora MySQL 3.05 e versioni successive. Per ulteriori dettagli, consulta Parametri di configurazione Aurora MySQL.

È stato risolto un problema che poteva causare la visualizzazione di risultati errati nelle NumBinaryLogFiles metriche attivate quando CloudWatch è abilitato il binlog avanzato.

Il timeout delle richieste per le operazioni di machine learning di Aurora MySQL su Amazon Sagemaker è stato aumentato da 3 a 30 secondi. Questo aiuta a risolvere un problema per cui i clienti possono riscontrare un numero maggiore di tentativi o errori per le richieste ad Amazon Sagemaker dal machine learning di Aurora MySQL quando utilizzano batch di dimensioni maggiori.

È stato aggiunto il supporto per le tabelle malloc_stats e malloc_stats_totals nel database performance_schema.

La parola chiave FROM nel comando LOAD DATA FROM S3 è stata aggiornata in modo che sia facoltativa. Per ulteriori informazioni, consulta Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3.

È stato aggiunto il supporto per il parametro innodb_aurora_instant_alter_column_allowed, che controlla se è possibile utilizzare l'algoritmo INSTANT per le operazioni ALTER COLUMN. Per ulteriori informazioni, consulta Parametri a livello di cluster.

È stato risolto un problema che può impedire la creazione di nuove connessioni client al database quando è abilitato l'inoltro di scrittura.

È stato risolto un problema che poteva far sì che la modifica del parametro del database table_open_cache non avesse effetto fino al riavvio dell'istanza database.

È stato risolto un problema che poteva causare errori di chiave duplicata per le colonne AUTO_INCREMENT che utilizzavano indici decrescenti dopo un'operazione di ripristino di uno snapshot, un backtrack o un'operazione di clonazione del database.

È stato risolto un problema relativo alle scansioni degli indici in cui poteva essere restituito un risultato impreciso durante l'esecuzione di una query SELECT con la clausola GROUP BY e il parametro aurora_parallel_query impostati su ON.

È stato risolto un problema che poteva causare l'esaurimento della memoria disponibile durante l'esecuzione di query sulla tabella INFORMATION_SCHEMA INNODB_TABLESPACES.

È stato risolto un problema per cui l'istanza di lettura non era in grado di aprire una tabella, con ERROR 1146. Questo problema si verifica quando si eseguono determinati tipi di Data Definition Language (DDL) online mentre l'algoritmo INPLACEviene utilizzato sull'istanza di scrittura.

È stato risolto un problema che impediva il riavvio dell'istanza durante Aurora Serverless v2 scalabilità quando il processo di monitoraggio interno invia erroneamente richieste di ridimensionamento duplicate.

È stato risolto un problema che poteva causare il riavvio del database quando gli utenti di log binario (binlog) connessi utilizzano un server di replica binlog duplicato. IDs

È stata introdotta una cache di log di inoltro in memoria per le repliche di log binari gestite da Aurora MySQL. Questo miglioramento può contribuire a ottenere un aumento fino al 40% della velocità di trasmissione effettiva di replica dei log binari. Questo miglioramento viene abilitato automaticamente quando si utilizza la replica di log binario a thread singolo o quando si utilizza la replica multi-thread con il posizionamento automatico GTID abilitato.

L'aggiornamento da MySQL 5.7 a MySQL 8.0 con un numero molto elevato di tabelle in un unico database ha causato un consumo eccessivo di memoria nel server. È stato riscontrato che, durante il processo di verifica della possibilità di aggiornare le tabelle, abbiamo recuperato in anticipo tutti gli oggetti Table del dizionario di dati, elaborandoli ciascuno e recuperandone il nome, quindi abbiamo eseguito la verifica della compatibilità delle versioni nell'elenco. In questo caso non era necessario recuperare tutti gli oggetti in anticipo e l'operazione ha contribuito notevolmente al consumo di memoria. Per correggere questo problema, in questi casi recuperiamo un oggetto Table alla volta, eseguiamo tutti i controlli necessari, ne recuperiamo il nome e rilasciamo l'oggetto, prima di procedere con quello successivo. (Bug 34526001)

Sono state migliorate le prestazioni degli aggiornamenti delle versioni principali da Aurora MySQL versione 2 alla versione 3 eseguendo controlli del tablespace in parallelo utilizzando tutte le v disponibili sull'istanza del database. CPUs

È stato risolto un problema che può causare un maggiore utilizzo della CPU a causa della rotazione dei certificati TLS in background. (Correzione di un bug della community 34284186)