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à.
Aggiornamento di un database globale Amazon Aurora
L'aggiornamento di un database globale Aurora segue le stesse procedure dell'aggiornamento dei cluster di database Aurora. Tuttavia, di seguito sono riportate alcune importanti differenze di cui prendere nota prima di iniziare il processo.
Ti consigliamo di eseguire l'aggiornamento dei cluster di database primario e secondario alla stessa versione. È possibile eseguire un failover gestito del database tra regioni su un database globale Aurora solo se i cluster di database primario e secondario hanno la stessa versione principale e secondaria e lo stesso livello di patch del motore. Tuttavia, i livelli di patch possono essere diversi, a seconda della versione secondaria del motore. Per ulteriori informazioni, consulta Compatibilità del livello di patch per switchover e failover gestiti tra regioni.
Aggiornamenti di una versione principale
Quando esegui un aggiornamento della versione principale di un database globale Amazon Aurora, aggiorni il cluster di database globale invece dei singoli cluster in esso contenuti.
Per informazioni su come aggiornare un database SQL globale di Aurora Postgre a una versione principale superiore, vedere. Principali aggiornamenti per database globali
Nota
Con un database globale Aurora basato su Aurora PostgreSQL, non è possibile eseguire un aggiornamento della versione principale del motore Aurora DB se la funzionalità Recovery Point Objective () è attivata. RPO Per informazioni sulla funzionalità, consulta. RPO Gestione RPOs di database globali basati su Aurora SQL Postgre
Per informazioni su come aggiornare un database SQL globale Aurora My a una versione principale superiore, vedere. Principali aggiornamenti in loco per database globali
Nota
Con un database globale Aurora basato su Aurora MySQL, non è possibile eseguire un aggiornamento sul posto da Aurora SQL My versione 2 alla versione 3 se il parametro è attivato. lower_case_table_names
Per eseguire un aggiornamento della versione principale a Aurora My SQL versione 3 quando si utilizzalower_case_table_names, utilizzare la seguente procedura:
-
Rimuovi tutte le regioni secondarie dal cluster globale. Seguire la procedura riportata in Rimozione di un cluster da un database globale Amazon Aurora.
-
Aggiorna la versione del motore della regione principale alla SQL versione 3 di Aurora My. Seguire la procedura riportata in Come eseguire un aggiornamento in loco.
-
Aggiungi le regioni secondarie al cluster globale. Seguire la procedura riportata in Aggiungere un file Regione AWS a un database globale di Amazon Aurora.
Puoi anche utilizzare il metodo di ripristino snapshot. Per ulteriori informazioni, consulta Ripristino da uno snapshot cluster database.
Aggiornamenti della versione secondaria
Per un aggiornamento secondario su un database globale Aurora, è necessario aggiornare tutti i cluster secondari prima di aggiornare il cluster primario.
Per informazioni su come aggiornare un database SQL globale Aurora Postgre a una versione secondaria superiore, vedere. Come eseguire aggiornamenti della versione secondaria e applicare patch Per informazioni su come aggiornare un database SQL globale Aurora My a una versione secondaria superiore, vedere. Aggiornamento di Aurora My SQL modificando la versione del motore
Prima di eseguire l'aggiornamento, esamina le seguenti considerazioni:
L'aggiornamento della versione secondaria di un cluster secondario non influisce in alcun modo sulla disponibilità o sull'utilizzo del cluster primario.
Un cluster secondario deve disporre almeno di un'istanza database per eseguire un aggiornamento a una versione secondaria.
Se si aggiorna un database SQL globale Aurora My alla versione 2.11.*, è necessario aggiornare i cluster DB primari e secondari alla stessa identica versione, incluso il livello di patch.
Per supportare switchover o failover gestiti tra regioni, puoi eseguire l'aggiornamento dei cluster database primario e secondari alla stessa versione, incluso il livello di patch, a seconda della versione del motore. Per ulteriori informazioni, consulta Compatibilità del livello di patch per switchover e failover gestiti tra regioni.
Compatibilità del livello di patch per switchover e failover gestiti tra regioni
Quando aggiorni il database globale Aurora a una delle seguenti versioni secondarie del motore, puoi eseguire switchover o failover gestiti tra regioni anche se i livelli di patch dei cluster database primario e secondari non corrispondono. Per le versioni secondarie del motore precedenti a quelle presenti in questo elenco, è necessario aggiornare i cluster database primario e secondari alla stessa versione principale e secondaria e allo stesso livello di patch per eseguire switchover o failover gestiti tra regioni. Assicurati di esaminare le informazioni sulla versione e le note nella tabella seguente.
Nota
Per i failover manuali tra regioni, è possibile eseguire il processo di failover purché il cluster database secondario di destinazione esegua la stessa versione principale e secondaria del motore del cluster database primario. In questo caso, i livelli di patch non devono necessariamente corrispondere.
| Motore del database | Versioni secondarie del motore | Note |
|---|---|---|
Aurora Mia SQL |
Nessuna versione secondaria |
Con tutte le versioni secondarie, è possibile eseguire switchover o failover gestiti tra regioni solo se i livelli di patch dei cluster DB primari e secondari corrispondono. |
Aurora Postger SQL |
|
Con le versioni secondarie del motore elencate nella colonna precedente, è possibile eseguire switchover o failover gestiti tra regioni da un cluster database primario con un livello di patch a un cluster database secondario con un livello di patch diverso. Con versioni minori inferiori a queste, è possibile eseguire switchover o failover gestiti tra regioni solo se i livelli di patch dei cluster DB primari e secondari corrispondono. |
