Aggiornamenti del motore di database Aurora MySQL 14/12/2016 (versione 1.10) (obsoleta)

Applicazione di patch senza tempi di inattività:– questa caratteristica consente di applicare patch a un'istanza del database senza tempi di inattività. Ciò significa che gli aggiornamenti del database vengono eseguiti senza scollegare le applicazioni client o senza riavviare il database. Questo approccio consente di aumentare la disponibilità dei cluster del database di Aurora durante la finestra di manutenzione. I dati temporanei come quelli dello schema di prestazioni vengono ripristinati durante l'aggiornamento. Questa caratteristica applica le patch fornite dal servizio e le patch avviate dall'utente durante la finestra di manutenzione.

Quando si avvia una patch, il servizio garantisce che non vi siano blocchi, transazioni o tabelle temporanee aperti e attende un periodo di tempo appropriato durante il quale si possono applicare le patch e il database può essere riavviato. Le sessioni delle applicazioni vengono conservate, tuttavia si potrebbe registrare un peggioramento delle prestazioni durante l'applicazione della patch (circa 5 secondi). Se non è disponibile una finestra appropriata, per impostazione predefinita viene applicato il comportamento di applicazione delle patch standard.

L'applicazione di patch senza tempi di inattività si svolge sulla base del miglior tentativo ed è soggetta alle seguenti limitazioni:

Indicizzazione spaziale:– l'indicizzazione spaziale consente di migliorare le prestazioni delle query su set di dati di grandi dimensioni per le query che usano i dati spaziali. Per ulteriori informazioni sull'uso dell'indicizzazione spaziale, consulta Amazon Aurora MySQL e dati spaziali nella Guida per l'utente di Amazon Aurora.

Questa caratteristica è disattivata per impostazione predefinita ma può essere attivata nella modalità di laboratorio di Aurora. Per informazioni Aurora, consulta Modalità di laboratorio per Amazon Aurora MySQL nella Guida per l'utente di Amazon Aurora.

Miglioramenti della pipeline di replica:– Aurora MySQL ora utilizza un meccanismo migliorato per applicare gli aggiornamenti del flusso di log alla cache del buffer di una replica di Aurora. Questa funzione migliora la stabilità e le prestazioni di lettura delle repliche di Aurora nel caso di un carico di scrittura elevato sul master, ma anche di un carico di lettura significativo sulla replica. Questa caratteristica viene attivata per impostazione predefinita.

Miglioramento delle prestazioni per i carichi di lavoro con letture memorizzate nella cache:– Aurora MySQL ora utilizza un algoritmo simultaneo senza latch per implementare le viste delle letture, per ottenere un miglioramento delle prestazioni delle query di lettura gestite dalla cache del buffer. Grazie a questo e ad altri miglioramenti, Amazon Aurora MySQL può raggiungere un throughput fino a 625.000 letture al secondo rispetto alle 164.000 letture al secondo di MySQL 5.7 per un carico di lavoro solo Select. SysBench

Miglioramento delle prestazioni per i carichi di lavoro con righe in conflitto:– Aurora MySQL ora utilizza un nuovo algoritmo per il rilascio dei blocchi che migliora le prestazioni, in particolare nel caso di conflitto nelle pagine (ovvero di molte transazioni che si contendono le righe di una stessa pagina). Nei test con il benchmark TPC-C, si può ottenere un miglioramento di 16 volte superiore delle transazioni al minuto relative a MySQL 5.7. Questa caratteristica è disattivata per impostazione predefinita ma può essere attivata nella modalità di laboratorio di Aurora. Per informazioni Aurora, consulta Modalità di laboratorio per Amazon Aurora MySQL nella Guida per l'utente di Amazon Aurora.

La velocità della replica della cache dell'indice di ricerca full-text è stata migliorata attraverso l'aggiornamento della cache solo dopo una richiesta di lettura in una replica di Aurora. Questo approccio evita eventuali letture nel disco da parte del thread di replica.

È stato risolto un problema a causa del quale l'invalidazione della cache del dizionario non funziona in una replica di Aurora per le tabelle contenenti un carattere speciale nel nome del database o della tabella.

È stato risolto un problema relativo a STUCK IO che si verificava durante la migrazione dei dati e relativo ai nodi di storage distribuiti, quando era attivata la gestione dell'utilizzo dello storage.

È stato risolto un problema relativo alla gestione dei blocchi a causa del quale un controllo delle asserzioni non andava a buon fine per il thread in attesa per il blocco delle transazioni durante la preparazione del rollback o del commit di una transazione.

È stato risolto un problema relativo a una tabella di dizionario danneggiata tramite l'aggiornamento corretto del numero di riferimenti alle voci della tabella di dizionario.

È stato corretto un bug in cui il punto di lettura minimo del cluster del database poteva essere conservato dalle repliche di Aurora lenta.

È stato risolto un problema relativo a una potenziale perdita di memoria nella cache della query.

È stato corretto un bug a causa del quale una replica di Aurora attivava un blocco a livello di riga in una tabella quando si utilizzava una query IF di una procedura archiviata.

L'unione delle tabelle derivate genera risultati errati con clausole "1=0/false". (Bug 69471)

Si verifica un arresto anomalo del server in ITEM_FUNC_GROUP_CONCAT::FIX_FIELDS durante la seconda esecuzione della procedura archiviata. (Bug 20755389)

Impedire lo stallo delle query di MySQL per un periodo troppo lungo durante la sincronizzazione della cache FTS sul disco tramite l'offload di un'attività di sincronizzazione in un thread separato non appena la cache raggiunge il 10% della sua dimensione totale. (Bug 22516559, 73816)