Aggiornamenti del motore di database Aurora MySQL 25/05/2021 (versione 2.10.0) (obsoleta) - Amazon Aurora

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 25/05/2021 (versione 2.10.0) (obsoleta)

Versione: 2.10.0

Aurora MySQL 2.10.0 è disponibile a livello generale. Le versioni 2.x di Aurora MySQL sono compatibili con MySQL 5.7, mentre le versioni 1.x di Aurora MySQL sono compatibili con MySQL 5.6.

Le versioni di Aurora MySQL attualmente supportate sono 1.19.5, 1.19.6, 1.22.*, 1.23.*, 2.04.*, 2.07.*, 2.08.*, 2.09.*, 2.10.*, 3.01.* e 3.02.*.

È possibile aggiornare un cluster di database Aurora MySQL 2.* esistente a Aurora MySQL 2.10.0. Per i cluster che eseguono la versione Aurora MySQL 1, è possibile aggiornare un cluster Aurora MySQL 1.23 o superiore esistente a 2.10.0. È anche possibile ripristinare uno snapshot da una versione di Aurora MySQL attualmente supportata in Aurora MySQL 2.10.0.

In caso di domande o dubbi, l' AWS assistenza è disponibile nei forum della community e tramite AWS Support. Per ulteriori informazioni, consulta Manutenzione di un cluster database Amazon Aurora nella Guida per l'utente di Amazon Aurora.

Nota

Per informazioni su come aggiornare il cluster di database Aurora MySQL, consulta Aggiornamento della versione secondaria o del livello di patch di un cluster di database Aurora MySQL nella Guida per l'utente di Amazon Aurora.

Miglioramenti

Risolti i problemi di sicurezza ed CVEs elencati di seguito:

Correzioni e altri miglioramenti per ottimizzare la gestione in un ambiente gestito. Ulteriori correzioni CVE riportate di seguito:

Nuove caratteristiche:

  • La classe di istanza db.t3.large è ora supportata per Aurora MySQL.

  • Replica dei log binari:

    • Introdotta la cache I/O binlog per migliorare le prestazioni di binlog riducendo la contesa tra thread di scrittura e thread di dump. Per ulteriori informazioni, consulta Ottimizzazione della replica dei log binari nella Guida per l'utente di Amazon Aurora.

    • Nella versione Aurora MySQL 2.08, abbiamo introdotto una elaborazione log binaria (binlog) migliorata per ridurre il tempo di recupero degli arresti anomali e la latenza del tempo di commit quando sono coinvolte transazioni molto grandi. Questi miglioramenti sono ora supportati per i cluster con GTID abilitato.

  • Maggiore disponibilità delle istanze di lettura:

    • In precedenza, al riavvio di un'istanza di scrittura, tutte le istanze di lettura in un cluster Aurora MySQL venivano riavviate. Con il lancio di oggi, le istanze di lettura nella regione continuano a soddisfare le richieste di lettura durante il riavvio di un'istanza di scrittura, migliorando la disponibilità di lettura nel cluster. Per ulteriori informazioni, consulta la pagina relativa al riavvio di un cluster Aurora MySQL (versione 2.10 e successive) nella Guida per l'utente di Amazon Aurora.

      Importante

      Dopo l'aggiornamento a Aurora MySQL 2.10, il riavvio dell'istanza di scrittura non esegue il riavvio dell'intero cluster. Per riavviare l'intero cluster, ora si riavvia qualsiasi istanza di lettura nel cluster dopo il riavvio dell'istanza di scrittura.

  • Migliorate le prestazioni delle letture della pagina di lettura anticipata richieste dalla tecnica di lettura anticipata logica (LRA). Ciò è stato fatto raggruppando le letture di più pagine in un’unica richiesta inviata allo storage Aurora. Di conseguenza, le query che utilizzano l'ottimizzazione LRA vengono eseguite fino a 3 volte più velocemente.

  • Riavvio e applicazione di patch senza tempi di inattività:

Miglioramenti della disponibilità:

  • Miglioramenti per un avvio più rapido quando il database ha un numero elevato di indici temporanei e tabelle creati durante una precedente attività DDL interrotta.

  • Risolti diversi problemi relativi ai riavvii ripetuti durante il ripristino in caso di arresto di operazioni DDL interrotte, come DROP TRIGGER, ALTER TABLE e in particolare ALTER TABLE che modifica il tipo di partizionamento o il numero di partizioni in una tabella.

  • È stato risolto un problema che poteva causare il riavvio del server durante l'elaborazione dei log DAS (Database Activity Streams).

  • È stato risolto un problema che comportava la stampa di un messaggio di errore durante l'elaborazione di una query ALTER sulle tabelle di sistema.

Miglioramenti generali:

  • È stato risolto un problema per cui la cache delle query poteva restituire risultati non obsoleti su un'istanza di lettura.

  • È stato risolto un problema per cui alcuni parametri di commit Aurora non venivano aggiornati quando la variabile di sistema innodb_flush_log_at_trx_commit era impostata su 0 o 2.

  • È stato risolto un problema per cui un risultato di query memorizzato nella cache delle query non veniva aggiornato dalle transazioni multi-istruzione.

  • È stato risolto un problema che poteva causare l'aggiornamento corretto dell'ultimo timestamp dei file di log binari. Ciò poteva comportare la rimozione prematura dei file di log binari prima di raggiungere il periodo di conservazione configurato dal cliente.

  • Risolto il nome e la posizione del file binlog segnalati errati da InnoDB dopo il ripristino in caso di arresto.

  • Risolto un problema che poteva causare transazioni di grandi dimensioni per generare eventi binlog non corretti se il parametro binlog_checksum era impostato su NONE.

  • È stato risolto un problema che causava l'interruzione di una replica binlog con un errore se la transazione replicata conteneva un'istruzione DDL e un numero elevato di modifiche di riga.

  • È stato risolto un problema che causava un riavvio in un'istanza di lettura quando si lasciava cadere una tabella.

  • È stato risolto un problema che causava il guasto dei connettori open source quando si tentava di utilizzare un file binlog con una transazione di grandi dimensioni.

  • È stato risolto un problema che poteva causare risultati di query errati sulla colonna geometrica di grandi dimensioni dopo aver creato un indice spaziale sulla tabella con i valori geometrici di grandi dimensioni.

  • Il database ora ricrea lo spazio tabella temporaneo durante il riavvio, che consente di liberare e ripristinare lo spazio di archiviazione associato.

  • È stato risolto un problema che impediva il troncamento delle tabelle performance_schema sulle istanze di lettura Aurora.

  • Risolto un problema che causava l'interruzione di una replica binlog con un errore HA_ERR_KEY_NOT_FOUND.

  • È stato risolto un problema che causava il riavvio del database durante l'esecuzione dell'istruzione FLUSH TABLES WITH READ LOCK.

  • È stato risolto un problema che impediva l'uso di funzioni di blocco a livello utente sulle istanze di lettura Aurora.

Integrazione delle correzioni di bug della community di MySQL

  • Le transazioni interleave potevano talvolta bloccare l'applier replica quando il livello di isolamento delle transazioni era impostato su REPEATABLE READ. (Bug 25040331)

  • Quando una procedure archiviata conteneva un'istruzione riferita a una vista che a sua volta faceva riferimento a un'altra vista, la procedura non poteva essere richiamata correttamente più di una volta. (Bug 87858, Bug 26864199)

  • Per le query con molte condizioni OR, l'ottimizzatore ora è più efficiente in termini di memoria e ha meno probabilità di superare il limite di memoria imposto dalla variabile di sistema range_optimizer_max_mem_size. Inoltre, il valore predefinito per tale variabile è stato incrementato da 1.536.000 a 8.388.608. (Bug 79450, Bug 22283790)

  • Replica: nella funzione next_event(), che viene chiamata dal thread SQL di una replica per leggere l'evento successivo dal log di relay, il thread SQL non ha rilasciato l’relaylog.log_lock acquisito quando si è verificato un errore (ad esempio, a causa di un log di relay chiuso), causando il blocco di tutti gli altri thread in attesa di acquisire un blocco sul log di relay. Con questa correzione, il blocco viene rilasciato prima che il thread SQL lasci la funzione nella situazione. (Bug 21697821)

  • Correzione di un danneggiamento della memoria per ALTER TABLE con colonna virtuale. (Bug 24961167, Bug 24960450)

  • Replica: non è stato possibile configurare le repliche multithread con dimensioni di coda ridotte utilizzando slave_pending_jobs_size_max se fosse stato necessario elaborare transazioni più grandi di quelle dimensioni. Qualsiasi pacchetto più grande di slave_pending_jobs_size_max è stato rifiutato con l'errore ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, anche se il pacchetto era più piccolo del limite impostato da slave_max_allowed_packet. Con questa correzione, slave_pending_jobs_size_max diventa un limite flessibile anziché un limite rigido. Se la dimensione di un pacchetto supera slave_pending_jobs_size_max ma è inferiore a slave_max_allowed_packet, la transazione viene trattenuta fino a quando tutti i dipendenti replica non hanno code vuote e quindi elaborate. Tutte le transazioni successive vengono mantenute fino al completamento della transazione di grandi dimensioni. Le dimensioni della coda per i dipendenti replica possono quindi essere limitate, pur consentendo transazioni occasionali più grandi. (Bug 21280753, Bug 77406)

  • Replica: quando si utilizzava una replica multithread, gli errori dell'applicatore visualizzavano i dati dell'ID dipendente che non erano coerenti con i dati esternalizzati nelle tabelle di replica dello schema di prestazioni. (Bug 25231367)

  • Replica: su una replica basata su GTID in esecuzione con -gtid-mode=on, -log-bin=off e che utilizza -, quando si verificava un errore che doveva essere ignorato non veniva aggiornato correttamente slave-skip-errors, causando la perdita della sincronia con. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Se GTID_NEXT non era stato specificato, la replica non aggiornerebbe mai lo stato GTID durante il rollback da una singola transazione di rendiconto. Exec_Master_Log_Pos non verrebbe aggiornato perché anche se la transazione è stata completata, il suo stato GTID mostrerebbe altro. La correzione rimuove il vincolo dell'aggiornamento dello stato GTID quando una transazione viene ripristinata solo se viene specificato GTID_NEXT. (Bug 22268777)

  • Replica: un'istruzione parzialmente fallita non consumava correttamente un GTID generato automaticamente o specificato quando la registrazione binaria è stata disattivata. La correzione assicura che un DROP TABLE parzialmente non riuscito, un DROP USER parzialmente non riuscito o un DROP VIEW parzialmente non riuscito consumino rispettivamente il GTID pertinente e lo salvino nella tabella @@GLOBAL.GTID_EXECUTED e mysql.gtid_executed quando la registrazione binaria è disabilitata. (Bug 21686749)

  • Replica: le repliche che eseguono MySQL 5.7 non sono in grado di connettersi a un'origine MySQL 5.5 a causa di un errore nel recupero del server_uuid, che non fa parte di MySQL 5.5. Ciò è stato causato da modifiche nel metodo di recupero del server_uuid. (Bug 22748612)

  • Replica: il meccanismo di salto delle transazioni GTID che ignora silenziosamente una transazione GTID precedentemente eseguita non ha funzionato correttamente per le transazioni XA. (Bug 25041920)

  • Le istruzioni “>ROLLBACK XA che non sono andate a buon fine a causa di un ID transazione errato, potrebbero essere registrate nel log binario con l'ID della transazione corretto e potrebbero quindi essere eseguite da repliche di replica. Viene ora effettuato un controllo della situazione di errore prima che si verifichi la registrazione binaria e le istruzioni XA ROLLBACK non riuscite non vengono registrate. (Bug 26618925)

  • Replica: se una replica è stata configurata utilizzando un'istruzione CHANGE MASTER TO che non specificava il nome del file di registro di origine e la posizione del registro di origine, veniva chiusa prima dell'emissione di START SLAVE, quindi riavviata con l'opzione - relay-log-recovery set, la replica non veniva avviata. Ciò accadeva perché il thread del ricevitore non era stato avviato prima del tentativo di recupero del log di inoltro, quindi nel log di inoltro non era disponibile alcun evento di rotazione del log per fornire il nome del file di log di origine e la posizione del log di origine. In questa situazione, la replica ora salta il recupero del log di inoltro e registra un avviso, quindi procede all'avvio della replica. (Bug 28996606, Bug 93397)

  • Replica: nella replica basata su riga, veniva restituito un messaggio che visualizzava in modo errato le lunghezze dei campi durante la replica da una tabella con una colonna utf8mb3 a una tabella con la stessa definizione in cui la colonna era stata definita con un set di caratteri utf8mb4. (Bug 25135304, Bug 83918)

  • Replica: quando veniva emessa un'istruzione RESET SLAVE su una replica di replica GTIDs in uso, i file di log di inoltro esistenti venivano eliminati, ma il nuovo file di registro di inoltro sostitutivo veniva generato prima che il set di dati ricevuti GTIDs per il canale fosse cancellato. Il precedente set GTID è stato quindi scritto nel nuovo file di registro di inoltro come PREVIOUS_GTIDS evento, causando un errore fatale nella replica in cui si affermava che la replica aveva GTIDs più dell'origine, anche se il set gtid_executed per entrambi i server era vuoto. Ora, quando RESET SLAVE viene emesso, il set di dati ricevuti GTIDs viene cancellato prima della generazione del nuovo file di log di inoltro, in modo che questa situazione non si verifichi. (Bug 27411175)

  • Replica: utilizzata per la replica, le transazioni che includono le istruzioni che hanno causato un errore di analisi (ER_PARSE_ERROR) non possono essere ignorate manualmente con GTIDs il metodo consigliato di iniettare una transazione vuota o sostitutiva con lo stesso GTID. Questa azione dovrebbe avere come esito che la replica identifichi il GTID come già utilizzato e quindi salti la transazione indesiderata che ha condiviso il suo GTID. Tuttavia, nel caso di un errore di analisi, poiché l'istruzione è stata analizzata prima che il GTID venisse controllato per verificare se dovesse essere saltato, il thread dell'applicatore di replica si è arrestato a causa dell'errore di analisi, anche se l'intenzione era di saltare comunque la transazione. Con questa correzione, il thread dell'applicatore di replica ora ignora gli errori di analisi se la transazione interessata deve essere saltata perché il GTID era già stato utilizzato. Notare che questa modifica di comportamento non si applica nel caso di carichi di lavoro costituiti da output di log binario prodotto da mysqlbinlog. In tale situazione, esisterebbe il rischio che anche una transazione con un errore di analisi che segue immediatamente una transazione saltata venga ignorata in modo silenzioso, quando dovrebbe invece generare un errore. (Bug 27638268)

  • Replica: abilitare il thread SQL a GTID salta una transazione parziale. (Bug 25800025)

  • Replica: quando è stato fornito un parametro di timeout negativo o frazionarioWAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), il server si è comportato in modi imprevisti. Con questa correzione:

    • Un valore di timeout frazionario viene letto così com'è, senza arrotondamento.

    • Un valore di timeout negativo viene rifiutato con un errore se il server è in modalità SQL rigorosa; se il server non è in una modalità SQL rigorosa, il valore restituisce NULL immediatamente la funzione senza alcuna attesa e quindi emette un avviso. (Bug 24976304, Bug 83537)

  • Replica: se la funzione WAIT_FOR_EXECUTED_GTID_SET() è stata utilizzata con un valore di timeout che include una parte frazionaria (ad esempio 1,5), un errore nella logica di casting significava che il timeout è stato arrotondato al secondo intero più vicino e a zero per valori inferiori a 1 secondo (ad esempio 0,1). La logica di casting è stata ora corretta in modo che il valore di timeout venga applicato come originariamente specificato senza arrotondamento. Grazie a Dirkjan Bussink per il contributo. (Bug 29324564, Bug 94247)

  • GTIDs Se abilitato, XA COMMIT su una transazione XA disconnessa all'interno di una transazione con più dichiarazioni generava un'asserzione. (Bug 22173903)

  • Replica: è stata generata un'asserzione nelle build di debug se è stata emessa un'istruzione ROLLBACK XA per un identificatore di transazione sconosciuto quando il valore gtid_next era stato impostato manualmente. Il server ora non tenta di aggiornare lo stato GTID se un'istruzione ROLLBACK XA non va a buon fine con un errore. (Bug 27928837, Bug 90640)

  • Risolve il problema dell'ordinamento errato quando vengono utilizzate più CASE funzioni nella clausola ORDER BY (Bug 22810883).

  • Alcune query che utilizzavano l'ordinamento potevano accedere a una colonna non inizializzata durante l'ottimizzazione e causare la chiusura del server. (Bug 27389294)

Confronto con Aurora MySQL Versione 1

Le seguenti caratteristiche di Amazon Aurora MySQL sono supportate in Aurora MySQL versione 1 (compatibile con MySQL 5.6), ma non sono al momento supportate in Aurora MySQL versione 2 (compatibile con MySQL 5.7).

Compatibilità MySQL 5.7

Questa versione Aurora MySQL è compatibile con MySQL 5.7 e include funzionalità come il supporto JSON, gli indici spaziali e le colonne generate. Aurora MySQL utilizza un'implementazione nativa degli indici spaziali attraverso curve di ordine z per offrire prestazioni di scrittura migliorate di 20 volte e prestazioni di lettura migliorate di 10 volte rispetto a MySQL 5.7 per i set di dati spaziali.

Questa versione di Aurora MySQL al momento non supporta le seguenti caratteristiche di MySQL 5.7:

  • Plugin replica gruppi

  • Maggiori dimensioni pagina

  • Caricamento buffer pool InnoDB all'avvio

  • Plugin parser full-text InnoDB

  • Replica multi-source

  • Ridimensionamento buffer pool online

  • Plugin convalida password

  • Plugin riscrittura query

  • Filtri replica

  • Istruzione SQL CREATE TABLESPACE