Utilizzo dell'applicazione di patch senza tempi di inattività

L'esecuzione degli aggiornamenti per i cluster Aurora SQL My DB comporta la possibilità di un'interruzione quando il database viene chiuso 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.

La funzionalità zero-downtime patching (ZDP) tenta, nel migliore dei modi, di preservare le connessioni client tramite un aggiornamento Aurora My. SQL Se viene ZDP completata correttamente, le sessioni dell'applicazione vengono conservate e il motore di database si riavvia mentre è in corso l'aggiornamento. Il riavvio del motore del database può causare un calo del throughput della durata di alcuni secondi fino a circa un minuto.

ZDPnon si applica a quanto segue:

• Patch e aggiornamenti del sistema operativo

• Aggiornamenti di una versione principale

ZDPè disponibile per tutte le SQL versioni di Aurora My supportate e le classi di istanze DB.

ZDPnon è supportato per Aurora Serverless v1 o database globali 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.

Puoi visualizzare le metriche degli attributi importanti ZDP nella sezione Il mio log degli SQL errori. È inoltre possibile visualizzare informazioni su quando Aurora My SQL utilizza ZDP o sceglie di non utilizzare nella ZDP pagina Eventi del AWS Management Console.

In Aurora My SQL versione 2.10 e successive e versione 3, Aurora può eseguire una patch senza downtime indipendentemente dal fatto che la replica dei log binari sia abilitata o meno. Se la replica dei log binari è abilitata, Aurora SQL My interrompe automaticamente la connessione alla destinazione binlog durante un'operazione. ZDP Aurora My si riconnette SQL automaticamente alla destinazione binlog e riprende la replica al termine del riavvio.

ZDPfunziona anche in combinazione con i miglioramenti al riavvio in Aurora My 2.10 e versioni successive. SQL 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. Prima di Aurora My SQL 2.10, ZDP si applica solo all'istanza Writer DB di un cluster.

ZDPpotrebbe non essere completato correttamente nelle seguenti condizioni:

• Durante l'esecuzione di query o transazioni di lunga durata. Se Aurora è ZDP in grado di eseguire questa operazione, tutte le transazioni aperte vengono annullate ma le relative connessioni vengono mantenute.

• Vengono utilizzate tabelle temporanee, blocchi utente o blocchi tabellari, ad esempio durante l'esecuzione delle istruzioni Data Definition Language (). DDL Aurora interrompe queste connessioni.

• Esistono modifiche ai parametri in attesa.

Se non è ZDP disponibile una finestra temporale adeguata per l'esecuzione a causa di una o più di queste condizioni, l'applicazione delle patch torna al comportamento standard.

Nota

Per Aurora My SQL versione 2 precedente alla 2.11.0 e versione 3 precedente alla 3.04.0, ZDP potrebbe non essere completata correttamente quando sono presenti connessioni Secure Socket Layer (SSL) o Transport Layer Security () aperte. TLS

Sebbene le connessioni rimangano intatte dopo un'ZDPoperazione 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 operatività riportato dallo stato del motore viene ripristinato dopo un riavvio che utilizza i meccanismi or. ZDR 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, vedere My SQL Reference Manual.

• 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.