Utilizzo dell'applicazione di patch senza tempi di inattività - 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à.

Utilizzo dell'applicazione di patch senza tempi di inattività

L'esecuzione di aggiornamenti per i cluster Aurora MySQL DB comporta la possibilità di un'interruzione quando il database viene spento e durante l'aggiornamento. Per impostazione predefinita, se si avvia l'aggiornamento mentre il database è occupato, si perdono tutte le connessioni e le transazioni elaborate dal cluster di database. Se si aspetta che il database sia inattivo per eseguire l'aggiornamento, potrebbe essere necessario attendere a lungo.

L'applicazione di patch senza tempi di inattività si basa sul miglior tentativo per preservare le connessioni client attraverso un aggiornamento Aurora MySQL. Se l'applicazione di patch senza tempi di inattività viene completata correttamente, le sessioni delle applicazioni vengono conservate e il motore del database si riavvia mentre l'aggiornamento è in corso. Il riavvio del motore del database può causare un calo del throughput della durata di alcuni secondi fino a circa un minuto.

ZDP non si applica a quanto segue:

  • Patch e aggiornamenti del sistema operativo

  • Aggiornamenti di una versione principale

ZDP è disponibile per tutte le versioni di Aurora MySQL e le classi di istanze database supportate.

ZDP non è supportato per i database globali Aurora Serverless v1 o Aurora.

Nota

Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta Utilizzo delle classi di istanza T per lo sviluppo e i test.

È possibile visualizzare i parametri degli attributi importanti durante ZDP nel log degli errori MySQL. È inoltre possibile visualizzare informazioni su quando Aurora MySQL utilizza ZDP o sceglie di non utilizzare ZDP nella pagina Eventi nella Console di gestione AWS.

In Aurora MySQL, Aurora può eseguire una patch senza tempi di inattività indipendentemente dal fatto che la replica dei log binari sia abilitata o meno. Se la replica dei log binari è abilitata, Aurora MySQL elimina automaticamente la connessione alla destinazione binlog durante un'operazione di applicazione di patch senza tempi di inattività. Aurora MySQL si riconnette automaticamente alla destinazione binlog e riprende la replica al termine del riavvio.

ZDP funziona anche in combinazione con i miglioramenti del riavvio in Aurora MySQL. L'applicazione di patch all'istanza database scrittore applica automaticamente le patch ai lettori contemporaneamente. Dopo aver applicato la patch, Aurora ripristina le connessioni sia sulle istanze DB dello scrittore che del lettore.

L'applicazione di patch senza tempi di inattività potrebbe non essere completata correttamente nelle condizioni seguenti:

  • Durante l'esecuzione di query o transazioni di lunga durata. Se Aurora è in grado di eseguire l’applicazione di patch senza tempi di inattività, qualsiasi transazione aperta è annullata, ma le relative connessioni vengono mantenute.

  • Sono in uso tabelle temporanee, blocchi utente temporanei e blocchi tabella temporanei, per esempio durante l’esecuzione di istruzioni DDL (Data Definition Language). Aurora interrompe queste connessioni.

  • Esistono modifiche ai parametri in attesa.

Se non è disponibile alcuna finestra temporale appropriata per l'esecuzione dell'applicazione di patch senza tempi di inattività a causa di una o più di queste condizioni, viene ripristinato il comportamento standard dell'applicazione delle patch.

Sebbene le connessioni rimangano intatte a seguito di un'operazione ZDP riuscita, alcune variabili e funzionalità vengono reinizializzate. I seguenti tipi di informazioni non vengono conservati tramite un riavvio causato da zero-downtime patching:

  • Variabili globali. Aurora ripristina le variabili di sessione, ma non ripristina le variabili globali dopo il riavvio.

  • Variabili di stato. In particolare, il valore di attività riportato dallo stato del motore viene ripristinato dopo un riavvio che utilizza i meccanismi ZDR o ZDP.

  • LAST_INSERT_ID.

  • Stato auto_increment in memoria per le tabelle. Lo stato di incremento automatico in memoria viene reinizializzato. Per ulteriori informazioni sui valori di incremento automatico, consulta il Manuale di riferimento di MySQL.

  • Informazioni diagnostiche dalle tabelle INFORMATION_SCHEMA e PERFORMANCE_SCHEMA. Queste informazioni diagnostiche vengono visualizzate anche nell'output di comandi come SHOW PROFILE e SHOW PROFILES.

Le seguenti attività relative a zero-downtime restart sono riportate nella pagina Eventi:

  • Tentativo di aggiornare il database senza tempi di inattività.

  • Tentativo di aggiornare il database senza tempi di inattività terminato. L'evento riporta quanto tempo è durato il processo. L'evento segnala inoltre quante connessioni sono state mantenute durante il riavvio e quante connessioni sono state interrotte. È possibile consultare il registro degli errori del database per visualizzare ulteriori dettagli su ciò che è successo durante il riavvio.