Aggiornamenti del motore di database Aurora MySQL 07/08/2017 (versione 1.14) (obsoleta) - Amazon Aurora
Applicazione di patch senza tempi di inattivitàMiglioramentiIntegrazione delle correzioni di bug di MySQL.

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 07/08/2017 (versione 1.14) (obsoleta)

Versione: 1.14

Aurora MySQL 1.14 è disponibile a livello generale. Tutti i nuovi cluster di database, compresi quelli ripristinati da snapshot, verranno creati in Aurora MySQL versione 1.14. Inoltre, Aurora MySQL versione 1.14 è un aggiornamento obbligatorio per i cluster del database di Aurora MySQL esistenti. Verrà inviato un annuncio distinto con le tempistiche per l'eliminazione delle versioni precedenti di Aurora MySQL.

Con la versione 1.14 di Aurora MySQL, viene utilizzato un modello di patch del cluster che consente di applicare le patch a tutti i nodi del cluster di database Aurora contemporaneamente. Gli aggiornamenti richiedono un riavvio del database, pertanto ci sarà un tempo di inattività di 20-30 secondi, al termine del quale si potranno ricominciare a usare i cluster del DB. Se i cluster di database eseguono la versione 1.13, l'applicazione di patch senza tempi di inattività di Aurora consente la conservazione delle connessioni client all'istanza primaria di Aurora durante l'aggiornamento, a seconda del carico di lavoro.

In caso di domande o dubbi, l' AWS assistenza è disponibile nei forum della community e tramite AWS Support.

Applicazione di patch senza tempi di inattività

I tentativi dell'applicazione di patch senza tempi di inattività funzionano sulla base del miglior tentativo per preservare le connessioni client attraverso le patch del motore. Per ulteriori informazioni su ZDP, consulta Applicazione di patch senza tempi di inattività (ZDP) nella Guida per l'utente di Amazon Aurora.

Miglioramenti

  • È stato risolto un messaggio "record non trovato" che veniva visualizzato erroneamente quando un record veniva individuato nell'indice secondario ma non in quello primario.

  • È stato risolto un problema di stabilità che si verificava a causa di un'asserzione difensiva (aggiunta nella versione 1.12) troppo evidente nel caso di una singola scrittura di più di 32 pagine. Questa situazione poteva verificarsi, ad esempio, con valori BLOB alti.

  • È stato risolto un problema di stabilità provocato da incoerenze tra la cache degli spazi tabelle e la cache dei dizionari.

  • È stato risolto un problema a causa del quale la replica di Aurora smetteva di rispondere dopo aver superato il numero massimo di tentativi di connessione all'istanza primaria. Ora una replica di Aurora si riavvia se il periodo di inattività è più lungo del periodo di timeout di heartbeat utilizzato per il controllo dello stato dall'istanza primaria.

  • È stato risolto un livelock che si verificava in caso di alta simultaneità nel tentativo di una connessione di acquisire un blocco a livello di metadati (MDL) durante l'esecuzione di un comando, ad esempio ALTER TABLE.

  • È stato risolto un problema di stabilità in una replica di lettura di Aurora in presenza di una lettura anticipata logica/parallela.

  • Miglioramento di LOAD FROM S3 in due modi:

    1. Migliore gestione degli errori di timeout di Amazon S3 attraverso lo schema di nuovi tentativi SDK oltre allo schema di nuovi tentativi esistente.

    2. Ottimizzazione delle prestazioni durante il caricamento di file di grandi dimensioni o di un numero elevato di file mediante il loro caching e il riutilizzo dello stato del client.

  • Sono stati risolti i seguenti problemi di stabilità con Fast DDL per le operazioni ALTER TABLE:

    1. Quando l'istruzione ALTER TABLE prevede più comandi ADD COLUMN e i nomi delle colonne non sono in ordine ascendente.

    2. Quando la stringa del nome della colonna deve essere aggiornata e la stringa del nome corrispondente, prelevata dalla tabella del sistema interna, è diversa a causa di un carattere finale nullo (/0).

    3. Nel caso di alcune operazioni di suddivisione albero B

    4. Quando la tabella dispone di una chiave primaria di lunghezza variabile.

  • È stato risolto un problema di stabilità con le repliche di Aurora nei casi in cui richiedeva troppo tempo rendere l'indice FTS coerente con quello dell'istanza primaria. Questo poteva verificarsi se un gran numero delle voci dell'indice FTS creato nell'istanza primaria non era stato incluso nel disco.

  • È stato risolto un problema di stabilità che si verificava durante la creazione dell'indice.

  • Nuova infrastruttura che tiene traccia del consumo di memoria per ogni connessione e telemetria associata da utilizzare per creare strategie volte a ridurre i problemi di esaurimento di memoria.

  • È stato risolto un problema a causa del quale ANALYZE TABLE veniva consentito erroneamente nelle repliche Aurora. Questo codice è stato bloccato.

  • È stato risolto un problema di stabilità provocato da un deadlock raro, conseguenza di una race condition tra la lettura anticipata logica e la rimozione.

Integrazione delle correzioni di bug di MySQL.

  • Una ricerca full-text combinata con le tabelle derivate (sottoquery nella clausola FROM) ha provocato un'uscita dal server. Ora, se un'operazione full-text dipende da una tabella derivata, il server genera un errore in cui viene indicato che non è possibile eseguire una ricerca full-text in una tabella materializzata. (Bug 68751, 16539903)