Aggiornamento di un database globale Amazon Aurora - 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à.

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 globale Aurora PostgreSQL a una versione principale superiore, consulta 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 caratteristica Recovery point objective (RPO) (Obiettivo del punto di ripristino (RPO)) è attivata. Per ulteriori informazioni sulla caratteristica RPO, consulta Gestione degli RPO per database globali basati su Aurora PostgreSQL–.

Per informazioni su come aggiornare un database globale Aurora MySQL a una versione principale superiore, consulta Principali aggiornamenti in loco per database globali.

Nota

Con un database globale Aurora basato su Aurora MySQL, non puoi eseguire un aggiornamento locale da Aurora MySQL versione 2 alla versione 3 se il parametro lower_case_table_names è attivato.

Per eseguire un aggiornamento della versione principale ad Aurora MySQL versione 3 usando lower_case_table_names, puoi utilizzare la seguente procedura:

  1. Rimuovi tutte le regioni secondarie dal cluster globale. Seguire la procedura riportata in Rimozione di un cluster da un database globale Amazon Aurora.

  2. Esegui l'aggiornamento della versione del motore della regione principale ad Aurora MySQL versione 3. Seguire la procedura riportata in Come eseguire un aggiornamento in loco.

  3. Aggiungi le regioni secondarie al cluster globale. Seguire la procedura riportata in Aggiunta di una Regione AWS a un database globale 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 globale Aurora PostgreSQL a una versione secondaria superiore, consulta Come eseguire aggiornamenti della versione secondaria e applicare patch. Per informazioni su come aggiornare un database globale Aurora MySQL a una versione secondaria superiore, consulta Aggiornamento di Aurora MySQL 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 aggiorni un database globale Aurora MySQL alla versione 2.11.*, devi aggiornare i tuoi cluster di database 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 MySQL

Nessuna versione secondaria

Con tutte le versioni secondarie, è possibile eseguire switchover o failover interregionali gestiti solo se i livelli di patch dei cluster DB primari e secondari corrispondono.

Aurora PostgreSQL

  • Versione 14.5 o versione secondaria successiva

  • Versione 13.8 o versione secondaria successiva

  • Versione 12.12 o versione secondaria successiva

  • Versione 11.17 o versione secondaria successiva

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 aree geografiche solo se i livelli di patch dei cluster DB primari e secondari corrispondono.