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 di Database globale Amazon Aurora
Con la funzionalità Database globale Amazon Aurora, puoi configurare più cluster di database Aurora che si estendono su più cluster. Regioni AWS Aurora sincronizza automaticamente tutte le modifiche apportate nel cluster di database primario con uno o più cluster secondari. Un database globale Aurora ha un cluster di database primario in una Regione e fino a dieci cluster di database secondari in Regioni differenti. Questa configurazione multi-Regione consente un ripristino di emergenza rapido in caso di eventuali interruzioni che potrebbero interessare un’intera Regione AWS. La disponibilità di una copia completa di tutti i dati in più aree geografiche consente inoltre operazioni di lettura a bassa latenza per le applicazioni che si connettono da località molto diverse in tutto il mondo.
**Topics**
+ [Panoramica di Database globale Amazon Aurora](#aurora-global-database-overview)
+ [Vantaggi di Database globale Amazon Aurora](#aurora-global-database.advantages)
+ [Disponibilità di regioni e versioni](#aurora-global-database.Availability)
+ [Limitazioni di Database globale Amazon Aurora](#aurora-global-database.limitations)
+ [Nozioni di base sul Database globale Amazon Aurora](aurora-global-database-getting-started.md)
+ [Gestione di un database globale Amazon Aurora](aurora-global-database-managing.md)
+ [Connessione a Database globale Amazon Aurora](aurora-global-database-connecting.md)
+ [Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora](aurora-global-database-write-forwarding.md)
+ [Utilizzo dello switchover o failover in un Database globale Amazon Aurora](aurora-global-database-disaster-recovery.md)
+ [Monitoraggio di un database globale Amazon Aurora](aurora-global-database-monitoring.md)
+ [Utilizzo Blue/Green delle distribuzioni per Amazon Aurora Global Database](aurora-global-database-bluegreen.md)
+ [Utilizzo dei database globali di Amazon Aurora con altri servizi AWS](aurora-global-database-interop.md)
+ [Aggiornamento di un database globale Amazon Aurora](aurora-global-database-upgrade.md)
## Panoramica di Database globale Amazon Aurora
Utilizzando la funzionalità Database globale Amazon Aurora, puoi eseguire le applicazioni distribuite globalmente utilizzando un singolo database Aurora che si sviluppa su più Regioni AWS.
*Un database globale Aurora è costituito da un database *primario* Regione AWS in cui vengono scritti i dati e fino a 10 secondari di sola lettura.* Regioni AWS Emetti operazioni di scrittura al cluster di database primario nella Regione AWS primaria. Il modo più comodo per farlo è connettersi all’endpoint di scrittura del database globale Aurora, che punta sempre al cluster di database primario, anche dopo uno switchover o un failover verso un altro Regione AWS. Dopo ogni operazione di scrittura, Aurora replica i dati sul secondario Regioni AWS utilizzando un'infrastruttura dedicata, con una latenza in genere inferiore a un secondo.
Nel diagramma seguente, è possibile trovare un esempio di database globale Aurora che si estende su due. Regioni AWS
![\[Un database globale Aurora dispone di un singolo cluster di database primario e di almeno un cluster di database Aurora secondario.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-conceptual-illo.png)
Puoi aumentare verticalmente le dimensioni del cluster secondario in maniera indipendente aggiungendo una o più istanze di lettura Aurora per servire carichi di lavoro di sola lettura. È possibile utilizzare Aurora Serverless v2 per le istanze di lettura per un dimensionamento ancora più granulare e flessibile.
Solo il cluster primario eseguire operazioni di scrittura. I client che eseguono operazioni di scrittura si connettono all’endpoint di scrittura del database globale Aurora, che punta sempre all’istanza di scrittura di database, che punta sempre all’istanza database del cluster di database. Come illustrato nel diagramma, Aurora utilizza il volume di archiviazione del cluster e non il motore di database per una replica rapida e con sovraccarico ridotto. Per ulteriori informazioni, consulta [Panoramica dell'archiviazione di Amazon Aurora](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage).
Il database globale Aurora è progettato per le applicazioni con una presenza globale. I cluster DB secondari multipli di sola lettura Regioni AWS aiutano a ottimizzare le operazioni di lettura più vicine agli utenti delle applicazioni. Attraverso la funzionalità di inoltro di scrittura, è possibile anche configurare un database globale in modo che i cluster secondari inviino i dati le richieste di scrittura al primario. Per ulteriori informazioni, consulta [Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora](aurora-global-database-write-forwarding.md).
Un database globale Aurora supporta due diverse operazioni per modificare la Regione del cluster di database primario, a seconda dello scenario: *switchover del Database globale Aurora* e *failover globale del database Aurora*.
+ Per le procedure operative pianificate come la rotazione delle Regioni, utilizza il meccanismo di switchover (precedentemente chiamato “failover pianificato gestito”). Con questa funzionalità, puoi rilocare il cluster primario di un Database globale Aurora integro in una delle Regioni secondarie senza alcuna perdita di dati. Per ulteriori informazioni, consulta [Esecuzione di switchover per database globali Amazon Aurora](aurora-global-database-disaster-recovery.md#aurora-global-database-disaster-recovery.managed-failover).
+ Per ripristinare il database globale Aurora dopo un’interruzione nella Regione primaria, utilizza il meccanismo di failover. Con questa funzionalità, esegui il failover del cluster di database primario in un’altra Regione (failover tra Regioni). Per ulteriori informazioni, consulta [Esecuzione di failover gestiti per database globali Aurora](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.managed-unplanned).
## Vantaggi di Database globale Amazon Aurora
Utilizzando Database globale Aurora, è possibile ottenere i seguenti vantaggi:
+ **Letture globali con latenza locale**: le aziende che hanno uffici in tutto il mondo possono utilizzare Database globale Aurora per mantenere aggiornate le principali fonti di informazioni nella Regione AWS primaria. Gli uffici nelle altre regioni possono accedere alle informazioni nella propria regione, con una latenza locale.
+ **Cluster di database Aurora secondari scalabili**: è possibile dimensionare i cluster secondari aggiungendo più istanze di sola lettura a una Regione AWS secondaria. Il cluster secondario è di sola lettura, quindi può supportare fino a 16 istanze database di sola lettura, anziché il limite abituale di 15 per un singolo cluster Aurora.
+ **Replica rapida dai cluster di database Aurora primari a quelli secondari** – La replica eseguita da un database globale Aurora ha un impatto ridotto sulle prestazioni del cluster di database primario. Le risorse delle istanze database sono totalmente dedicate a servire carichi di lavoro di lettura e scrittura delle applicazioni.
+ **Ripristino da interruzioni a livello regionale**: i cluster secondari consentono di creare un database globale Aurora disponibile in una nuova Regione AWS primaria più rapidamente (RTO inferiore) e con minore perdita di dati (RPO inferiore) rispetto alle soluzioni di replica tradizionali.
## Disponibilità di regioni e versioni
Il supporto e la disponibilità di questa funzionalità variano a seconda delle versioni specifiche di ciascun motore di database Aurora e tra Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e Regioni con database globali Aurora, consulta [Regioni e motori di database supportati per i database globali Aurora](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
## Limitazioni di Database globale Amazon Aurora
Le seguenti limitazioni si applicano attualmente ai database globali Aurora:
+ Aurora Global Database è disponibile in alcune Regioni AWS e per versioni specifiche di Aurora MySQL e Aurora PostgreSQL. Per ulteriori informazioni, consulta [Regioni e motori di database supportati per i database globali Aurora](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
+ I database globali Aurora hanno determinati requisiti di configurazione per le classi di istanza database Aurora supportate, il numero massimo di Regioni AWS e così via. Per ulteriori informazioni, consulta [Requisiti di configurazione di un database globale Amazon Aurora](aurora-global-database.configuration.requirements.md).
+ Per Aurora MySQL con compatibilità MySQL 5.7, gli switchover di Database globale Aurora richiedono Aurora versione 2.09.1 o una versione secondaria superiore.
+ È possibile eseguire uno switchover o un failover gestito tra Regioni su un database globale Aurora solo se i cluster di database primario e secondario hanno la stessa versione principale e secondaria e le stesse versioni di motore. A seconda del motore e delle versioni del motore, può essere necessario che i livelli di patch siano identici oppure possono essere diversi. Per un elenco dei motori e delle versioni dei motori che consentono queste operazioni tra cluster primari e secondari con diversi livelli di patch, consulta [Compatibilità del livello di patch per switchover e failover gestiti tra regioni](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). Se le versioni del motore richiedono identici livelli di patch, puoi eseguire il failover manualmente seguendo i passaggi indicati in [Esecuzione di failover manuali per i Database globali Aurora](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.manual-unplanned).
+ Database globale Aurora attualmente non supporta le seguenti funzionalità di Aurora:
+ Aurora Serverless v1
+ Backtrack in Aurora
+ Per le limitazioni all’utilizzo della funzionalità Server proxy per RDS con i database globali Aurora, consulta [Limitazioni di Server proxy per RDS con i database globali](rds-proxy-gdb.md#rds-proxy-gdb.limitations).
+ L’aggiornamento automatico della versione secondaria non si applica ai cluster Aurora MySQL e Aurora PostgreSQL che fanno parte di un database globale. Si noti che questa impostazione può essere specificata per un'istanza database che fa parte di un cluster di database globale, ma l'impostazione non ha effetto.
+ Database globale Aurora attualmente non supporta il dimensionamento automatico per i cluster di database secondari.
+ Per utilizzare Database Activity Streams (DAS) su Database globale Aurora che esegue Aurora MySQL 5.7, la versione del motore deve essere la versione 2.08 o successiva. Per informazioni su DAS, consulta [Monitoraggio di Amazon Aurora tramite i flussi di attività del database](DBActivityStreams.md).
+ Le seguenti limitazioni si applicano attualmente a Database globale Aurora:
+ Non è possibile applicare un gruppo di parametri personalizzato al cluster di database globale mentre si esegue un aggiornamento della versione principale del database globale Aurora. È possibile creare i gruppi di parametri personalizzati in ciascuna Regione del cluster globale e applicarli manualmente ai cluster regionali dopo l'aggiornamento.
+ 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 ulteriori informazioni sui metodi disponibili all'uso, consulta [Aggiornamenti di una versione principale](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
+ Con Database globale Aurora basato su Aurora PostgreSQL, non è possibile eseguire un aggiornamento della versione principale del motore Aurora PostgreSQL DB se la funzionalità Obiettivo del punto di ripristino (RPO) è attivata. Per ulteriori informazioni sulla caratteristica RPO, consulta [Gestione degli RPO per database globali basati su Aurora PostgreSQL–](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
+ Con Database globale Aurora basato su Aurora MySQL, non è possibile eseguire un aggiornamento della versione secondaria dalla versione 3.01 o 3.02 alla versione 3.03 o successiva di Aurora MySQL utilizzando il processo standard. Per informazioni dettagliate sul processo da usare, consulta [Aggiornamento di Aurora MySQL modificando la versione del motore](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md).
Per informazioni sull’aggiornamento di Database globale Aurora, consulta [Aggiornamento di un database globale Amazon Aurora](aurora-global-database-upgrade.md).
+ Non è possibile interrompere o avviare i cluster di database Aurora nel database globale in modo individuale. Per ulteriori informazioni, consulta [Avvio e arresto di un cluster di database Amazon Aurora](aurora-cluster-stop-start.md).
+ Le istanze database di lettura Aurora collegate al cluster di database Aurora secondario possono essere riavviate in determinate circostanze. Se l'istanza Writer DB principale Regione AWS viene riavviata o failover, vengono riavviate anche le istanze DB Reader nelle regioni secondarie. Il cluster secondario non sarà quindi disponibile fino a quando tutte le istanze database di lettura al suo interno non sono nuovamente sincronizzate con l’istanza di scrittura del cluster di database primario. Il comportamento del cluster primario durante il riavvio o il failover è uguale a quello di un singolo cluster di database non globale. Per ulteriori informazioni, consulta [Replica con Amazon Aurora](Aurora.Replication.md).
Prima di apportare modifiche al cluster di database primario, assicurarsi di comprendere l’impatto sul database globale. Per ulteriori informazioni, consulta [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
+ Aurora Global Database attualmente non supporta lo `inaccessible-encryption-credentials-recoverable` stato in cui Amazon Aurora perde l'accesso alla chiave per AWS KMS il cluster DB. In questi casi, il cluster database crittografato entra nello stato terminale `inaccessible-encryption-credentials`. Per ulteriori informazioni su questi stati, consulta [Visualizzazione dello stato del cluster del DB](accessing-monitoring.md#Aurora.Status).
+ Secrets Manager non supporta Database globale Aurora. Quando aggiungi una Regione a un database globale, è necessario prima disattivare l’integrazione di Secrets Manager per l’istanza database.
+ I cluster di database basati su Aurora PostgreSQL che utilizzano un database globale Aurora hanno le seguenti limitazioni:
+ La gestione della cache del cluster non è supportata per i cluster di database secondari Aurora PostgreSQL che fanno parte dei database globali Aurora.
+ Se il cluster di database primario del database globale è basato su una replica di un’istanza PostgreSQL Amazon RDS, non è possibile creare un cluster secondario. Non tentare di creare un file secondario da quel cluster utilizzando l' Console di gestione AWS operazione AWS CLI, the o l'`CreateDBCluster`API. I tentativi di eseguire questa operazione scadono e il cluster secondario non viene creato.
Per i database globali si consiglia di creare cluster di database secondari utilizzando la stessa versione del motore di database Aurora del cluster primario. Per ulteriori informazioni, consulta [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md).
# Nozioni di base sul Database globale Amazon Aurora
Per iniziare a utilizzare Database globale Aurora, è necessario innanzitutto decidere quale motore di database Aurora utilizzare e in quali Regioni AWS. Solo determinate versioni dei motori di database Aurora PostgreSQL e Aurora MySQL in alcune Regioni AWS supportano Database globale Aurora. Per l'elenco completo, consulta [Regioni e motori di database supportati per i database globali Aurora](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
È possibile creare un Database globale Aurora in uno dei modi seguenti:
+ **Creare un nuovo Database globale Aurora con nuovi cluster di database Aurora e istanze database Aurora**: puoi eseguire questa operazione seguendo la procedura descritta in [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md). Dopo aver creato il cluster di database Aurora primario, aggiungere la Regione AWS secondaria seguendo la procedura descritta in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
+ **Utilizza un cluster di database Aurora esistente che supporta la funzionalità Database globale Aurora e aggiungi una Regione AWS**: puoi eseguire questa operazione solo se il cluster di database Aurora esistente utilizza una versione del motore database compatibile con il globale.
Verifica se è possibile scegliere **Aggiungi regione** per **Operazione** nella Console di gestione AWS quando è selezionato il cluster database Aurora. Se è possibile, è possibile utilizzare tale cluster database Aurora per il cluster Aurora globale. Per ulteriori informazioni, consulta [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
Prima di creare un Database globale Aurora, è consigliabile conoscere tutti i requisiti di configurazione.
**Topics**
+ [Requisiti di configurazione di un database globale Amazon Aurora](aurora-global-database.configuration.requirements.md)
+ [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md)
+ [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md)
+ [Creazione di un cluster database Aurora headless in una regione secondaria](aurora-global-database-attach.console.headless.md)
+ [Creazione di un database globale Amazon Aurora da uno snapshot Amazon Aurora o Amazon RDS](aurora-global-database.use-snapshot.md)
# Requisiti di configurazione di un database globale Amazon Aurora
Prima di iniziare a lavorare con il database globale, pianifica i nomi del cluster e delle istanze, le Regioni AWS, il numero di istanze e le classi di istanze che intendi utilizzare. Assicurati che le tue scelte siano conformi ai seguenti requisiti di configurazione.
Un database globale Aurora si sviluppa su almeno due Regioni AWS. La Regione AWS principale supporta un cluster di database Aurora con un'istanza di database writer Aurora. Una Regione AWS secondaria esegue un cluster di database Aurora di sola lettura costituito interamente da repliche Aurora. È necessaria almeno una Regione AWS secondaria, tuttavia un database globale Aurora può avere fino a 10 Regioni AWS secondarie. Nella tabella sono elencati il numero massimo di cluster di database Aurora, di istanze database Aurora e repliche Aurora consentiti in un database globale Aurora.
| Descrizione | Regione AWS principale | Regioni AWS secondarie |
| --- | --- | --- |
| Cluster di database Aurora | 1 | 10 (massimo) |
| Istanze di scrittura | 1 | 0 |
| Istanze di sola lettura (repliche Aurora), per cluster di database Aurora | 15 (massimo) | 16 (totali) |
| Istanze di sola lettura (massimo consentito, dato il numero effettivo di Regioni secondarie) | 15 - *s* | *s* = numero totale di Regioni AWS secondarie |
I cluster di database Aurora che compongono un database globale Aurora hanno i seguenti requisiti specifici:
+ **Requisiti delle classi di istanza database** – Un database globale Aurora richiede classi di istanza database ottimizzate per le applicazioni che fanno un uso intensivo della memoria. Per informazioni sulle classi di istanza database ottimizzate per la memoria, consulta [Tipi di classi di istanza database](Concepts.DBInstanceClass.Types.md). Si consiglia di utilizzare una classe di istanza db.r5 o superiore.
+ **Requisiti di Regione AWS**: un database globale Aurora richiede un cluster di database Aurora primario in una Regione AWS e almeno un cluster di database Aurora secondario in una regione diversa. È possibile creare fino a 10 cluster di database Aurora secondari (di sola lettura) e ciascuno deve trovarsi in una Regione diversa. In altre parole, nessun cluster di database Aurora in un database globale Aurora può trovarsi nella stessa Regione AWS.
Per informazioni su quali combinazioni di motore di database Aurora, versione del motore e Regione AWS è possibile utilizzare con Database globale Aurora, consulta [Regioni e motori di database supportati per i database globali Aurora](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md)
+ **Requisiti di denominazione**: i nomi scelti per ciascuno dei cluster di database Aurora devono essere univoci in tutte le Regioni AWS. Non è possibile utilizzare lo stesso nome per cluster di database Aurora diversi anche se si trovano in regioni diverse.
+ **Requisiti di capacità per Aurora Serverless v2**: per un database globale con Aurora Serverless v2, la [capacità minima richiesta](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations) per il cluster di database nella Regione AWS primaria è di 8 ACU.
Prima di poter seguire le procedure descritte in questa sezione, è necessario disporre di un Account AWS. Completare le attività di configurazione per lavorare con Amazon Aurora. Per ulteriori informazioni, consulta [Configurazione dell'ambiente per Amazon Aurora](CHAP_SettingUp_Aurora.md). È inoltre necessario completare altre fasi preliminari per la creazione di un cluster di database Aurora. Per ulteriori informazioni, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Quando sei pronto per configurare il tuo database globale, consulta [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md) per la procedura per creare tutte le risorse necessarie. È inoltre possibile seguire la procedura illustrata in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md) per creare un database globale usando un cluster Aurora esistente come cluster primario.
# Creazione di un database globale Amazon Aurora
Per creare un database globale Aurora e le relative risorse associate utilizzando l' Console di gestione AWS, la o l' AWS CLI API RDS, utilizzare la procedura seguente.
**Nota**
Se è presente un cluster di database Aurora che esegue un motore di database Aurora compatibile a livello globale, è possibile utilizzare una forma più breve di questa procedura. In tal caso, puoi aggiungerne un altro Regione AWS al cluster DB esistente per creare il tuo database globale Aurora. A questo proposito, consulta [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
## Console
I passaggi per la creazione di un database globale Aurora iniziano con l'accesso a un database Regione AWS che supporta la funzionalità di database globale Aurora. Per un elenco completo, consulta [Regioni e motori di database supportati per i database globali Aurora](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
Uno dei passaggi seguenti consiste nel selezionare un Virtual Private Cloud (VPC) basato su Amazon VPC per il cluster di database Aurora. Per utilizzare il tuo VPC, ti consigliamo di crearlo in anticipo in modo che sia possibile sceglierlo. Allo stesso tempo, crea tutte le sottoreti correlate e, in base alle esigenze, un gruppo di sottoreti e un gruppo di sicurezza. Per scoprire come, consulta [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md).
Per informazioni generali sulla creazione di un cluster di database Aurora, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
**Per creare un database globale Aurora**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Create database (Crea database)**. Nella pagina **Crea database** completa le seguenti operazioni:
+ Scegli **Standard create (Creazione standard)** per il metodo di creazione del database. (Non selezionare Easy Create (Creazione rapida)).
+ Per `Engine type` nella sezione **Opzioni motore** scegli il tipo di motore applicabile, **Aurora (compatibile con MySQL)** o **Aurora (compatibile con PostgreSQL)**.
1. Continua a creare il database globale Aurora utilizzando i passaggi descritti nelle procedure riportate di seguito.
### Creazione di un database globale tramite Aurora MySQL
La procedura seguente si applica a tutte le versioni di Aurora MySQL.
**Per creare un database globale Aurora tramite Aurora MySQL**
Completare la pagina **Create database (Crea database)**.
1. Per **Opzioni motore**, scegli quanto segue:
1. Per **Engine version** (Versione motore), scegli la versione di Aurora MySQL che desideri utilizzare per il database globale Aurora.
1. Per **Templates (Modelli)**, scegliere **Production (Produzione)**. Oppure puoi scegliere Dev/Test se è appropriato per il tuo caso d'uso. Non utilizzare Dev/Test in ambienti di produzione.
1. In **Settings (Impostazioni)**, eseguire la seguente operazione:
1. Immettere un nome specifico per l'identificatore del cluster di database. Al termine della creazione del database globale Aurora, questo nome identificherà il cluster di database primario.
1. Specifica la password per l'account utente `admin` per l'istanza database o lascia che Aurora ne generi una. Se scegli di generare automaticamente una password, apparirà l'opzione per copiare la password.
![\[Schermata delle selezioni su Impostazioni durante la creazione di un database globale.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-3.png)
1. Per **DB instance class (Classe dell'istanza database)**, scegli `db.r5.large` o un'altra classe dell'istanza database ottimizzata per la memoria. Si consiglia di utilizzare una classe di istanza db.r5 o superiore.
1. Per **Disponibilità e durata**, ti consigliamo di lasciare che Aurora crei autonomamente una replica Aurora in una zona di disponibilità differente. Se non crei subito una replica Aurora, sarà necessario farlo in un secondo momento.
![\[Schermata di Availability & durability (Disponibilità e durata).\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-4b.png)
1. Per **Connectivity (Connettività)**, scegliere il Virtual Private Cloud (VPC) basato su Amazon VPC che definisce l'ambiente di rete virtuale per questa istanza di database. È possibile scegliere i valori predefiniti per semplificare questa attività.
1. Completa le impostazioni **di autenticazione del database** . Per semplificare il processo, puoi scegliere subito **Autenticazione password** e configurare AWS Identity and Access Management (IAM) in un secondo momento.
1. In **Additional configuration (Configurazione aggiuntiva)**, eseguire le operazioni seguenti:
1. Immettere un nome per **Initial database name (Nome del database iniziale)** per creare l'istanza database Aurora primaria per il cluster. Questo è il nodo di scrittura per il cluster di database Aurora primario.
Lasciare i valori predefiniti selezionati per il gruppo di parametri del cluster di database e il gruppo di parametri di database, a meno che non si disponga di gruppi di parametri personalizzati che si desidera utilizzare.
1. Se selezionata, deseleziona l’opzione **Abilita backtrack**. I database globali Aurora non supportano il backtracking. Puoi accettare tutte le altre impostazioni predefinite per **Configurazione aggiuntiva**.
1. Scegliere **Create database (Crea database)**.
Il completamento del processo di creazione dell'istanza database Aurora, della replica Aurora e del cluster di database Aurora può richiedere alcuni minuti ad Aurora. È possibile sapere quando il cluster database Aurora è pronto per l'uso come cluster database primario in un database globale Aurora in base al relativo stato. Quando è così, il suo stato e quello del writer e del nodo di replica sarà **Disponibile**, come illustrato di seguito.
![\[Schermata dei database con un cluster database Aurora pronto per l'uso con il database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-5.png)
Quando il cluster di database primario è disponibile, crea il database globale Aurora aggiungendo un cluster secondario. A tale scopo, segui le fasi in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
### Creazione di un database globale tramite Aurora PostgreSQL
**Per creare un database globale Aurora tramite Aurora PostgreSQL**
Completare la pagina **Create database (Crea database)**.
1. Per **Opzioni motore**, scegli quanto segue:
1. Per **Engine version** (Versione motore), scegli la versione di Aurora PostgreSQL che desideri utilizzare per il database globale Aurora.
1. Per **Templates (Modelli)**, scegliere **Production (Produzione)**. Oppure puoi scegliere Dev/Test se appropriato. Non utilizzare Dev/Test in ambienti di produzione.
1. In **Settings (Impostazioni)**, eseguire la seguente operazione:
1. Immettere un nome specifico per l'identificatore del cluster di database. Al termine della creazione del database globale Aurora, questo nome identificherà il cluster di database primario.
1. Specifica la password per l'account amministratore predefinito per il cluster database o lascia che Aurora ne generi una. Se si sceglie Genera automaticamente una password, apparirà l'opzione per copiare la password.
![\[Schermata delle selezioni su Impostazioni durante la creazione di un database globale.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-2.png)
1. Per **DB instance class (Classe dell'istanza database)**, scegli `db.r5.large` o un'altra classe dell'istanza database ottimizzata per la memoria. Si consiglia di utilizzare una classe di istanza db.r5 o superiore.
1. Per **Availability & durability (Disponibilità e durata)**, consigliamo di lasciare che Aurora crei autonomamente una replica Aurora in un'altra zona di disponibilità. Se non crei subito una replica Aurora, sarà necessario farlo in un secondo momento.
1. Per **Connectivity (Connettività)**, scegliere il Virtual Private Cloud (VPC) basato su Amazon VPC che definisce l'ambiente di rete virtuale per questa istanza di database. È possibile scegliere i valori predefiniti per semplificare questa attività.
1. (Facoltativo) Completa le impostazioni di **Database authentication** (Autenticazione database). L'autenticazione password è sempre abilitata. Per semplificare il processo, puoi ignorare questa sezione e impostare IAM o Autenticazione di password e Kerberos in un secondo momento.
1. In **Additional configuration (Configurazione aggiuntiva)**, eseguire le operazioni seguenti:
1. Immettere un nome per **Initial database name (Nome del database iniziale)** per creare l'istanza database Aurora primaria per il cluster. Questo è il nodo di scrittura per il cluster di database Aurora primario.
Lasciare i valori predefiniti selezionati per il gruppo di parametri del cluster di database e il gruppo di parametri di database, a meno che non si disponga di gruppi di parametri personalizzati che si desidera utilizzare.
1. Accetta tutte le altre impostazioni predefinite per **Configurazione aggiuntiva**, ad esempio Crittografia, Esportazioni log e così via.
1. Scegliere **Create database (Crea database)**.
Il completamento del processo di creazione dell'istanza database Aurora, della replica Aurora e del cluster di database Aurora può richiedere alcuni minuti ad Aurora. Quando il cluster è pronto per l'uso, il cluster di database Aurora e i relativi nodi di scrittura e replica presentano tutti lo stato **Disponibile**. Questo diventa il cluster di database primario del database globale Aurora, dopo averne aggiunto uno secondario.
![\[Schermata dei database con un cluster database Aurora pronto per l'uso con il database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-5-add-region.png)
Dopo che il cluster di database primario è disponibile, creare uno o più cluster secondari seguendo le fasi in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
## AWS CLI
I AWS CLI comandi nelle procedure seguenti eseguono le seguenti attività:
1. Crea un database globale Aurora, assegnandogli un nome e specificando il tipo di motore del database Aurora che si desidera utilizzare.
1. Creare un cluster di database Aurora per il database globale Aurora.
1. Creare l'istanza database Aurora per il cluster. Questo è il cluster database Aurora primario per il database globale.
1. Creare una seconda istanza database per il cluster di database Aurora. Questo è un reader per completare il cluster di database Aurora.
1. Creare un secondo cluster di database Aurora in un'altra regione e aggiungerlo al database globale Aurora, seguendo la procedura descritta in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
Segui la procedura per il motore di database Aurora.
### Creazione di un database globale tramite Aurora MySQL
**Per creare un database globale Aurora tramite Aurora MySQL**
1. Usa il comando `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-global-cluster.html)` CLI, passando il nome e la versione del motore di database Regione AWS Aurora.
Per Linux, macOS o Unix:
```
aws rds create-global-cluster --region primary_region \
--global-cluster-identifier global_database_id \
--engine aurora-mysql \
--engine-version version # optional
```
Per Windows:
```
aws rds create-global-cluster ^
--global-cluster-identifier global_database_id ^
--engine aurora-mysql ^
--engine-version version # optional
```
Questo crea un database globale Aurora "vuoto", con solo un nome (identificatore) e un motore di database Aurora. Prima che il database globale Aurora sia disponibile, potrebbero essere necessari alcuni minuti. Prima di passare alla fase successiva, utilizzare il comando CLI `[describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html)` per verificare se è disponibile.
```
aws rds describe-global-clusters --region primary_region --global-cluster-identifier global_database_id
```
Quando il database globale Aurora è disponibile, è possibile creare il relativo cluster di database Aurora primario.
1. Per creare un cluster di database Aurora primario, utilizzare il comando CLI `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)`. Includi il nome del database globale Aurora utilizzando il parametro `--global-cluster-identifier`.
Per Linux, macOS o Unix:
```
aws rds create-db-cluster \
--region primary_region \
--db-cluster-identifier primary_db_cluster_id \
--master-username userid \
--master-user-password password \
--engine aurora-mysql \
--engine-version version \
--global-cluster-identifier global_database_id
```
Per Windows:
```
aws rds create-db-cluster ^
--region primary_region ^
--db-cluster-identifier primary_db_cluster_id ^
--master-username userid ^
--master-user-password password ^
--engine aurora-mysql ^
--engine-version version ^
--global-cluster-identifier global_database_id
```
Usa il `[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)` AWS CLI comando per confermare che il cluster Aurora DB è pronto. Per individuare un cluster di database Aurora specifico, utilizzare il parametro `--db-cluster-identifier`. Oppure è possibile lasciare vuoto il nome del cluster di database Aurora nel comando per ottenere dettagli su tutti i cluster di database Aurora nella regione specificata.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier primary_db_cluster_id
```
Quando per il cluster viene visualizzata la risposta `"Status": "available"`, significa che è pronto per l'uso.
1. Creare l'istanza database per il cluster di database Aurora primario. A tale scopo, utilizza il comando della CLI `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`. Assegnare al comando il nome del cluster di database Aurora e specificare i dettagli di configurazione per l'istanza. Nel comando non è necessario passare i parametri `--master-username` e `--master-user-password`, perché li ottiene dal cluster di database Aurora.
Per `--db-instance-class`, è possibile utilizzare solo quelli dalle classi ottimizzate per la memoria, ad esempio `db.r5.large`. Si consiglia di utilizzare una classe di istanza db.r5 o superiore. Per informazioni su queste classi, consulta [Tipi di classi di istanza database](Concepts.DBInstanceClass.Types.md).
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier db_instance_id \
--engine aurora-mysql \
--engine-version version \
--region primary_region
```
Per Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier db_instance_id ^
--engine aurora-mysql ^
--engine-version version ^
--region primary_region
```
L'operazione `create-db-instance` potrebbe richiedere alcuni minuti per il completamento. Prima di continuare, controllare lo stato per verificare se l'istanza di database Aurora è disponibile.
```
aws rds describe-db-clusters --db-cluster-identifier primary_db_cluster_id
```
Quando il comando restituisce lo stato `available`, è possibile creare un’altra istanza database Aurora per il cluster di database primario. Si tratta dell'istanza del reader (la replica Aurora) per il cluster di database Aurora.
1. Per creare un'altra istanza database Aurora per il cluster, utilizza il comando della CLI `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`:
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier replica_db_instance_id \
--engine aurora-mysql
```
Per Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier replica_db_instance_id ^
--engine aurora-mysql
```
Quando l'istanza database è disponibile, la replica inizia dal nodo del writer al nodo di replica. Prima di continuare, verificare che l'istanza database sia disponibile utilizzando il comando CLI `[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)`.
A questo punto, si dispone di un database globale Aurora con il relativo cluster di database Aurora primario contenente un'istanza database writer e una replica Aurora. A questo punto è possibile aggiungere un cluster di database Aurora di sola lettura in una regione diversa per completare il database globale Aurora. A tale scopo, segui la procedura in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
### Creazione di un database globale tramite Aurora PostgreSQL
Quando si creano oggetti Aurora per un database globale Aurora utilizzando i comandi seguenti, possono essere necessari alcuni minuti prima che ciascuno diventi disponibile. Dopo aver completato un determinato comando, si consiglia di controllare lo stato dell'oggetto Aurora specifico per assicurarsi che lo stato sia disponibile.
A tale scopo, utilizza il comando della CLI `[describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html)`.
```
aws rds describe-global-clusters --region primary_region
--global-cluster-identifier global_database_id
```
**Per creare un database globale Aurora tramite Aurora PostgreSQL**
1. Utilizza il comando della CLI `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-global-cluster.html)`.
Per Linux, macOS o Unix:
```
aws rds create-global-cluster --region primary_region \
--global-cluster-identifier global_database_id \
--engine aurora-postgresql \
--engine-version version # optional
```
Per Windows:
```
aws rds create-global-cluster ^
--global-cluster-identifier global_database_id ^
--engine aurora-postgresql ^
--engine-version version # optional
```
Quando il database globale Aurora è disponibile, è possibile creare il relativo cluster di database Aurora primario.
1. Per creare un cluster di database Aurora primario, utilizzare il comando CLI `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)`. Includi il nome del database globale Aurora utilizzando il parametro `--global-cluster-identifier`.
Per Linux, macOS o Unix:
```
aws rds create-db-cluster \
--region primary_region \
--db-cluster-identifier primary_db_cluster_id \
--master-username userid \
--master-user-password password \
--engine aurora-postgresql \
--engine-version version \
--global-cluster-identifier global_database_id
```
Per Windows:
```
aws rds create-db-cluster ^
--region primary_region ^
--db-cluster-identifier primary_db_cluster_id ^
--master-username userid ^
--master-user-password password ^
--engine aurora-postgresql ^
--engine-version version ^
--global-cluster-identifier global_database_id
```
Verificare che il cluster di database Aurora sia pronto. Quando dal seguente comando viene visualizzata la risposta `"Status": "available"` per il cluster di database Aurora, è possibile continuare.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier primary_db_cluster_id
```
1. Creare l'istanza database per il cluster di database Aurora primario. A tale scopo, utilizza il comando della CLI `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`.
Invia il nome del cluster di database Aurora con il parametro `--db-cluster-identifier`.
Nel comando non è necessario passare i parametri `--master-username` e `--master-user-password`, perché li ottiene dal cluster di database Aurora.
Per `--db-instance-class`, è possibile utilizzare solo quelli dalle classi ottimizzate per la memoria, ad esempio `db.r5.large`. Si consiglia di utilizzare una classe di istanza db.r5 o superiore. Per informazioni su queste classi, consulta [Tipi di classi di istanza database](Concepts.DBInstanceClass.Types.md).
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier db_instance_id \
--engine aurora-postgresql \
--engine-version version \
--region primary_region
```
Per Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier db_instance_id ^
--engine aurora-postgresql ^
--engine-version version ^
--region primary_region
```
1. Prima di continuare, controllare lo stato dell'istanza database Aurora.
```
aws rds describe-db-clusters --db-cluster-identifier primary_db_cluster_id
```
Se la risposta mostra che lo stato dell’istanza database Aurora è `available`, è possibile creare un’altra istanza database Aurora per il cluster di database primario.
1. Per creare una replica Aurora per cluster di database Aurora, utilizzare il comando CLI `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`.
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier replica_db_instance_id \
--engine aurora-postgresql
```
Per Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier replica_db_instance_id ^
--engine aurora-postgresql
```
Quando l'istanza database è disponibile, la replica inizia dal nodo del writer al nodo di replica. Prima di continuare, verificare che l'istanza database sia disponibile utilizzando il comando CLI `[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)`.
Il database globale Aurora esiste, ma ha solo la relativa regione principale con un cluster di database Aurora costituito da un'istanza database di scrittura e una replica Aurora. A questo punto è possibile aggiungere un cluster di database Aurora di sola lettura in una regione diversa per completare il database globale Aurora. A tale scopo, segui la procedura in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
## API RDS
Per creare un database globale Aurora con l'API RDS, esegui l'operazione. [CreateGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html)
# Aggiunta di una Regione AWS a un database globale Amazon Aurora
È possibile utilizzare la procedura seguente per aggiungere un ulteriore cluster secondario a un database globale esistente. È anche possibile creare un database globale da un cluster di database Aurora autonomo utilizzando questa procedura per aggiungere la prima Regione AWS secondaria.
Un database globale Aurora richiede almeno un cluster di database Aurora secondario in una Regione AWS diversa da quella del cluster di database Aurora primario. È possibile collegare fino a 10 cluster di database secondari a un Database globale Aurora. Ripeti la procedura seguente per ogni nuovo cluster di database secondario. Per ogni cluster di database secondario aggiunto al database globale Aurora, ridurre di un'unità il numero di repliche Aurora consentite nel cluster di database primario.
Ad esempio, se il Database globale Aurora dispone di 10 Regioni secondarie, il cluster di database primario può avere solo 5 repliche Aurora (anziché 15). Per ulteriori informazioni, consulta [Requisiti di configurazione di un database globale Amazon Aurora](aurora-global-database.configuration.requirements.md).
Il numero di repliche Aurora (istanze di lettura) nel cluster di database primario determina il numero di cluster database secondari che è possibile aggiungere. Il numero di istanze di lettura nel cluster database primario più il numero di cluster secondari potrebbe essere pari a 15. Ad esempio, se esistono 14 istanze di lettura nel cluster di database primario e un cluster secondario, non è possibile aggiungere un altro cluster secondario al database globale.
**Nota**
Per Aurora MySQL versione 3, quando crei un cluster secondario, assicurati che il valore di `lower_case_table_names` corrisponda al valore nel cluster primario. Questa impostazione è un parametro del database che influisce sul modo in cui il server gestisce la distinzione tra maiuscole e minuscole. Per ulteriori informazioni sui parametri di database, vedi [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md).
Quando crei un cluster secondario, ti consigliamo di utilizzare la stessa versione del motore database per il primario e il secondario. Se necessario, aggiorna il primario in modo che abbia la stessa versione del secondario. Per ulteriori informazioni, consulta [Compatibilità del livello di patch per switchover e failover gestiti tra regioni](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility).
## Console
**Come aggiungere una Regione AWS a un database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione della Console di gestione AWS, scegliere **Databases (Database)**.
1. Scegliere il database globale Aurora che richiede un cluster di database Aurora secondario. Assicurarsi che il cluster di database Aurora primario sia `Available`.
1. In **Azioni**, scegli **Aggiungi Regione AWS**.
![\[Screenshot che mostra il cluster di database con provisioning e il comando “Aggiungi Regione AWS“ selezionato nel menu Azioni.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-5-add-region.png)
1. Nella pagina **Add a region (Aggiungi una regione)**, scegli la Regione AWS secondaria.
Non è possibile scegliere una Regione AWS che dispone già di un cluster di database Aurora secondario per lo stesso database globale Aurora. Inoltre, non può essere la stessa regione del cluster database Aurora primario.
**Nota**
I database globali Babelfish per Aurora PostgreSQL funzionano nelle Regioni secondarie solo se i parametri che controllano le preferenze di Babelfish sono attivati in tali Regioni. Per ulteriori informazioni, consulta [Impostazioni del gruppo di parametri del cluster database per Babelfish](babelfish-configuration.md)
![\[La pagina Aggiungi una regione per un database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-6-add-region.png)
1. Completa i campi rimanenti per il cluster Aurora secondario nella nuova regione AWS. Queste sono le stesse opzioni di configurazione di qualsiasi istanza del cluster database Aurora, ad eccezione della seguente opzione solo per i database globali Aurora basati su Aurora MySQL–:
+ Abilita l'inoltro in scrittura di replica in lettura – Questa impostazione facoltativa consente ai cluster database secondari del database Aurora globale di inoltrare le operazioni di scrittura al cluster primario. Per ulteriori informazioni, consulta [Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora](aurora-global-database-write-forwarding.md).
![\[Schermata che mostra che il cluster secondario ora fa parte del database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-enable-write-forwarding.png)
1. Scegli **Aggiungi Regione AWS**.
Dopo aver aggiunto la regione al database globale Aurora, potrai visualizzarla nell'elenco dei **Database** nella Console di gestione AWS come mostrato nella schermata.
![\[Schermata che mostra che il cluster secondario ora fa parte del database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-complete.png)
## AWS CLI
**Come aggiungere una Regione AWS secondaria a un database globale Aurora**
Per aggiungere un cluster secondario al database globale utilizzando la CLI, è necessario disporre già dell’oggetto container del cluster globale. Se non hai già eseguito il comando `create-global-cluster`, consulta la procedura CLI in [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md).
1. Utilizzare il comando CLI `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)` con il nome (`--global-cluster-identifier`) del database globale Aurora. Per gli altri parametri, effettuare le seguenti operazioni:
1. Per `--region`, scegli una Regione AWS diversa dalla tua regione Aurora principale.
1. Scegli i valori specifici per i parametri `--engine` e `--engine-version`. Questi valori sono gli stessi di quelli del cluster database Aurora primario nel database globale Aurora.
1. Per un cluster crittografato, specificare la Regione AWS principale come `--source-region` per la crittografia.
Nell'esempio seguente viene creato un nuovo cluster di database Aurora e viene collegato a un database globale Aurora come cluster di database Aurora secondario di sola lettura. Nell'ultimo passaggio, viene aggiunta un'istanza database Aurora al nuovo cluster di database Aurora.
Per Linux, macOS o Unix:
```
aws rds --region secondary_region \
create-db-cluster \
--db-cluster-identifier secondary_cluster_id \
--global-cluster-identifier global_database_id \
--engine aurora-mysql | aurora-postgresql \
--engine-version version
aws rds --region secondary_region \
create-db-instance \
--db-instance-class instance_class \
--db-cluster-identifier secondary_cluster_id \
--db-instance-identifier db_instance_id \
--engine aurora-mysql | aurora-postgresql
```
Per Windows:
```
aws rds --region secondary_region ^
create-db-cluster ^
--db-cluster-identifier secondary_cluster_id ^
--global-cluster-identifier global_database_id_id ^
--engine aurora-mysql | aurora-postgresql ^
--engine-version version
aws rds --region secondary_region ^
create-db-instance ^
--db-instance-class instance_class ^
--db-cluster-identifier secondary_cluster_id ^
--db-instance-identifier db_instance_id ^
--engine aurora-mysql | aurora-postgresql
```
## API RDS
Per aggiungere una nuova Regione AWS a un database globale Aurora con l'API RDS, esegui l'operazione [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Specificare l'identificatore del database globale esistente utilizzando il parametro `GlobalClusterIdentifier`.
# Creazione di un cluster database Aurora headless in una regione secondaria
Sebbene un database globale Aurora richieda almeno un cluster di database Aurora secondario in una Regione AWS diversa da quella primaria, è possibile utilizzare una configurazione *headless* per il cluster secondario. Un cluster database Aurora secondario headless è un cluster senza un'istanza database. Questo tipo di configurazione può ridurre le spese per un database globale Aurora. In un cluster database Aurora, il calcolo e l’archiviazione vengono disaccoppiati. Senza l'istanza database, non viene addebitato alcun costo per il calcolo, solo per lo storage. Se è configurato correttamente, il volume di archiviazione di un secondario headless viene mantenuto sincronizzato con il cluster database Aurora primario.
Puoi aggiungere il cluster secondario come si fa normalmente durante la creazione di un database globale Aurora. Se stai creando tutti i cluster nel database globale, segui la procedura riportata in [Creazione di un database globale Amazon Aurora](aurora-global-database-creating.md). Se disponi già di un cluster di database da utilizzare come cluster primario, segui la procedura riportata in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
Dopo che il cluster di database Aurora primario inizia la replica nel secondario, è possibile eliminare l’istanza database Aurora di sola lettura dal cluster di database Aurora secondario. Questo cluster secondario è ora considerato “headless” perché non dispone più dell'istanza DB. Anche in assenza di istanze database Aurora, Aurora mantiene la sincronizzazione tra il volume di archiviazione e il cluster di database Aurora primario.
**avvertimento**
Con Aurora PostgreSQL, per creare un cluster headless in una Regione AWS secondaria, utilizza la AWS CLI o l’API RDS per aggiungere la Regione AWS secondaria. Salta il passaggio per creare l'istanza DB di lettura per il cluster secondario. Attualmente, la creazione di un cluster headless non è supportata nella console RDS. Per l'utilizzo delle procedure CLI e API, consulta [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
Se il database globale utilizza una versione del motore Aurora PostgreSQL inferiore a 13.4, 12.8 o 11.13, la creazione di un’istanza database di lettura in una Regione secondaria e la successiva eliminazione potrebbero causare un problema di vacuum di Aurora PostgreSQL nell’istanza database di scrittura della Regione primaria. Se si verifica questo problema, riavviare l'istanza DB di scrittura della regione principale dopo aver eliminato l'istanza DB di lettura della regione secondaria.
**Per aggiungere un cluster database Aurora secondario headless al database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione della Console di gestione AWS, scegliere **Databases (Database)**.
1. Scegliere il database globale Aurora che richiede un cluster di database Aurora secondario. Assicurarsi che il cluster di database Aurora primario sia `Available`.
1. In **Azioni**, scegli **Aggiungi Regione AWS**.
1. Nella pagina **Add a region (Aggiungi una regione)**, scegli la Regione AWS secondaria.
Non è possibile scegliere una Regione AWS che dispone già di un cluster di database Aurora secondario per lo stesso database globale Aurora. Inoltre, non può essere la stessa regione del cluster database Aurora primario.
1. Completa i campi rimanenti per il cluster Aurora secondario nella nuova Regione AWS. Queste sono le stesse opzioni di configurazione di qualsiasi istanza del cluster database Aurora.
Per un database globale Aurora basato su Aurora MySQL–, ignora l'opzione **Abilita inoltro in scrittura della replica in lettura**. Questa opzione non ha alcuna funzione dopo aver eliminato l'istanza del lettore.
1. Scegli **Aggiungi Regione AWS**. Dopo aver aggiunto la regione al database globale Aurora, potrai visualizzarla nell'elenco dei **Database** nella Console di gestione AWS come mostrato nella schermata.
![\[Schermata che mostra il cluster secondario con la relativa istanza del lettore che fa parte del database globale Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-headless-stage-1.png)
1. Prima di continuare, controlla lo stato del cluster database Aurora secondario e la relativa istanza di lettura tramite la Console di gestione AWS o la AWS CLI. Ad esempio:
```
$ aws rds describe-db-clusters --db-cluster-identifier secondary-cluster-id --query '*[].[Status]' --output text
```
Il passaggio dello stato di un cluster database Aurora secondario appena aggiunto da `creating` a `available` può richiedere alcuni minuti. Quando il cluster database Aurora è disponibile, è possibile eliminare l'istanza di lettura.
1. Seleziona l'istanza di lettura nel cluster database Aurora secondario, quindi scegli **Elimina**.
![\[Schermata che mostra l'istanza di lettura selezionata e pronta per l'eliminazione.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-headless-stage-2.png)
Dopo aver eliminato l'istanza di lettura, il cluster secondario rimane parte del database globale Aurora. Non ha alcuna istanza associata, come illustrato di seguito.
![\[Schermata che mostra il cluster database secondario headless.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-headless-secondary.png)
Puoi utilizzare questo cluster di database Aurora secondario headless per [ripristinare manualmente il database globale Amazon Aurora da un'interruzione non pianificata nella Regione AWS principale](aurora-global-database-disaster-recovery.md#aurora-global-database-failover) se si verifica un'interruzione del servizio.
# Creazione di un database globale Amazon Aurora da uno snapshot Amazon Aurora o Amazon RDS
È possibile ripristinare uno snapshot di un cluster di database Aurora o di un'istanza database Amazon RDS da utilizzare come punto di partenza per il database globale Aurora. È possibile ripristinare uno snapshot e al contempo creare un nuovo cluster di database Aurora con provisioning. È quindi possibile aggiungere al cluster di database ripristinato un'altra Regione AWS trasformandolo in un database globale Aurora. Qualsiasi cluster di database Aurora creato utilizzando uno snapshot in questo modo diventa il cluster primario del database globale Aurora.
Lo snapshot utilizzato può essere preso da un cluster di database Aurora `provisioned` o `serverless`.
Durante il processo di ripristino, scegliere lo stesso tipo di motore di database dello snapshot. Ad esempio, si assuma di voler ripristinare uno snapshot creato da un cluster database Aurora Serverless che esegue Aurora PostgreSQL. In questo caso, si crea un cluster database Aurora PostgreSQL utilizzando lo stesso motore database Aurora e la stessa versione.
Quando si aggiunge una Regione AWS, il cluster database ripristinato assume il ruolo di cluster primario per il database globale Aurora. Tutti i dati contenuti in questo cluster primario vengono replicati in tutti i cluster secondari aggiunti al database globale Aurora.
![\[Screenshot che mostra la pagina di ripristino snapshot per un Aurora Global Database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-restore-snapshot-01.png)
# Gestione di un database globale Amazon Aurora
È possibile eseguire la maggior parte delle operazioni di gestione sui singoli cluster che costituiscono un database globale Aurora. Quando selezioni **Raggruppa risorse correlate** nella pagina **Database** della console, i cluster primario e secondario vengono visualizzati come raggruppati nel database globale associato. Per trovare le Regioni AWS in cui sono in esecuzione i cluster di database di un database globale, il motore database Aurora e la versione e il relativo identificativo, utilizza la scheda **Configurazione**.
Il processo di failover del database tra regioni è disponibile solo per i database globali Aurora e non per un singolo cluster database Aurora. Per ulteriori informazioni, consulta [Utilizzo dello switchover o failover in un Database globale Amazon Aurora](aurora-global-database-disaster-recovery.md).
Per ripristinare un database globale Aurora da un'interruzione non pianificata nella relativa regione principale, consulta [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
**Topics**
+ [Modifica di un database globale Amazon Aurora](aurora-global-database-modifying.md)
+ [Modifica dei parametri per un database globale Aurora](aurora-global-database-modifying.parameters.md)
+ [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md)
+ [Eliminazione di un database globale Amazon Aurora](aurora-global-database-deleting.md)
+ [Applicazione di tag alle risorse Database globale Amazon Aurora](aurora-global-database-tagging.md)
# Modifica di un database globale Amazon Aurora
La pagina **Database** nella pagina Console di gestione AWS elenca tutti i database globali Aurora, mostrando il cluster primario e i cluster secondari per ciascuno di essi. Il database globale Aurora dispone di impostazioni di configurazione proprie. In particolare, è stato Regioni AWS associato ai suoi cluster primari e secondari, come mostrato nella schermata seguente.
![\[Schermata che mostra un database globale Aurora selezionato e le impostazioni di configurazione associate nella Console di gestione AWS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-global-database-configuration.png)
Quando si apportano modifiche al database globale Aurora, si ha la possibilità di annullare le modifiche, come mostrato nella schermata seguente.
![\[Screenshot che mostra la pagina di modifica delle impostazioni per un Aurora Global Database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-modify-global-01.png)
Quando si sceglie **Continue (Continua)**, si confermano le modifiche.
# Modifica dei parametri per un database globale Aurora
È possibile configurare i gruppi di parametri del cluster di database Aurora in modo indipendente per ogni cluster Aurora all'interno del database globale Aurora. La maggior parte dei parametri funzionano come per altri tipi di cluster Aurora: Si consiglia di mantenere le impostazioni coerenti tra tutti i cluster di un database globale. In questo modo è possibile evitare modifiche impreviste del comportamento se si promuove un cluster secondario come primario.
Ad esempio, utilizzare le stesse impostazioni per fusi orari e set di caratteri per evitare comportamenti incoerenti se un cluster diverso diventa un cluster primario.
Le impostazioni di configurazione `aurora_enable_repl_bin_log_filtering` e `aurora_enable_replica_log_compression` non hanno effetto.
# Rimozione di un cluster da un database globale Amazon Aurora
È possibile rimuovere i cluster di database Aurora dal database globale Aurora per diversi motivi. Ad esempio, è possibile rimuovere un cluster di database Aurora da un database globale Aurora se il cluster primario viene danneggiato o isolato. Diventa quindi un cluster database Aurora con provisioning autonomo che potrebbe essere utilizzato per creare un nuovo database globale Aurora. Per ulteriori informazioni, consulta [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
È anche possibile rimuovere cluster di database Aurora se si desidera eliminare un database globale Aurora che non è più necessario. Non è possibile eliminare il database globale Aurora fino a quando non si rimuove (scollega) tutti i cluster database Aurora associati, lasciando il primario per ultimo. Per ulteriori informazioni, consulta [Eliminazione di un database globale Amazon Aurora](aurora-global-database-deleting.md).
Quando un cluster database Aurora viene scollegato dal database globale Aurora, non è più sincronizzato con il primario. Diventa un cluster database Aurora con provisioning autonomo con funzionalità di lettura/scrittura complete.
È possibile rimuovere i cluster database Aurora dal database globale Aurora utilizzando la Console di gestione AWS, la AWS CLI o l'API RDS.
## Console
**Per rimuovere un cluster Aurora da un database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli il cluster nella pagina **Database** .
1. Per **Operazioni**, scegli **Rimuovi da globale**.
![\[Schermata che mostra il cluster database Aurora selezionato (secondario) e l'operazione "Rimuovi da globale".\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-01.png)
Viene visualizzato un prompt per confermare che si desidera scollegare il cluster secondario dal database globale Aurora.
![\[Screenshot che mostra la richiesta di conferma di rimozione di un cluster secondario da un Aurora Global Database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-02.png)
1. Scegli **Rimuovi e promuovi** per rimuovere il cluster dal database globale.
Il cluster di database Aurora non è più utilizzato come secondario nel database globale Aurora e non viene più sincronizzato con il cluster di database primario. Si tratta di un cluster di database Aurora autonomo con funzionalità di lettura/scrittura complete.
![\[Screenshot che mostra la richiesta di conferma di rimozione di un cluster secondario da un Aurora Global Database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-03.png)
Dopo aver rimosso o eliminato tutti i cluster secondari, è possibile rimuovere il cluster primario nello stesso modo. Non è possibile scollegare (rimuovere) il cluster di database Aurora primario da un database globale Aurora fino a quando non si rimuovono tutti i cluster secondari.
Il database globale Aurora potrebbe rimanere nell'elenco **Database**, con 0 regioni e zone disponibilità. Laddove si desidera smettere di utilizzare questo database globale Aurora, è possibile eliminarlo. Per ulteriori informazioni, consulta [Eliminazione di un database globale Amazon Aurora](aurora-global-database-deleting.md).
## AWS CLI
Per rimuovere un cluster Aurora da un database globale Aurora, esegui il comando CLI [remove-from-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/remove-from-global-cluster.html) con i seguenti parametri:
+ `--global-cluster-identifier` – Il nome (identificatore) del database globale Aurora.
+ `--db-cluster-identifier` – Il nome di ogni cluster di database Aurora da rimuovere dal database globale Aurora. Prima di rimuovere il cluster primario, rimuovere tutti i cluster di database Aurora secondari.
Negli esempi di seguito, da un database globale Aurora viene prima rimosso un cluster secondario e poi il cluster primario.
Per Linux, macOS o Unix:
```
aws rds --region secondary_region \
remove-from-global-cluster \
--db-cluster-identifier secondary_cluster_ARN \
--global-cluster-identifier global_database_id
aws rds --region primary_region \
remove-from-global-cluster \
--db-cluster-identifier primary_cluster_ARN \
--global-cluster-identifier global_database_id
```
Ripeti il comando `remove-from-global-cluster --db-cluster-identifier secondary_cluster_ARN ` per ogni Regione AWS secondaria del database globale Aurora.
Per Windows:
```
aws rds --region secondary_region ^
remove-from-global-cluster ^
--db-cluster-identifier secondary_cluster_ARN ^
--global-cluster-identifier global_database_id
aws rds --region primary_region ^
remove-from-global-cluster ^
--db-cluster-identifier primary_cluster_ARN ^
--global-cluster-identifier global_database_id
```
Ripeti il comando `remove-from-global-cluster --db-cluster-identifier secondary_cluster_ARN` per ogni Regione AWS secondaria del database globale Aurora.
## API RDS
Per rimuovere un cluster Aurora da un database globale Aurora con l'API RDS, esegui l'operazione [RemoveFromGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveFromGlobalCluster.html).
# Eliminazione di un database globale Amazon Aurora
Poiché un database globale Aurora contiene in genere dati critici per l'azienda, non è possibile eliminare il database globale e i cluster associati in un singolo passaggio. Per eliminare un database globale Aurora, completa le seguenti operazioni:
+ Rimuovere tutti i cluster di database secondari dal database globale Aurora. Ogni cluster diventa un cluster di database Aurora autonomo. Per scoprire come, consulta [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md).
+ Da ogni cluster di database Aurora autonomo, eliminare tutte le repliche Aurora.
+ Rimuovere il cluster di database primario dal database globale Aurora. Questo diventa un cluster di database Aurora autonomo.
+ Dal cluster di database primario Aurora, per prima cosa eliminare tutte le repliche Aurora, quindi eliminare l'istanza del database di scrittura.
L'eliminazione dell'istanza di scrittura dal nuovo cluster di database Aurora autonomo generalmente rimuove anche il cluster di database Aurora e il database globale Aurora.
Per ulteriori informazioni generali, consulta [Eliminazione di un'istanza database da un cluster database Aurora](USER_DeleteCluster.md#USER_DeleteInstance).
Per eliminare un database globale Aurora, è possibile utilizzare la Console di gestione AWS, la AWS CLI o l'API RDS.
## Console
**Per eliminare un database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database** e trova il database globale Aurora che desideri eliminare nell'elenco.
1. Confermare che tutti gli altri cluster vengono rimossi dal database globale Aurora. Il database globale Aurora dovrebbe avere 0 regioni e zone di disponibilità e una dimensione pari a 0 cluster.
Se il database globale Aurora contiene cluster di database Aurora, non è possibile eliminarlo. Se necessario, scollegare i cluster di database Aurora primario e secondario dal database globale Aurora. Per ulteriori informazioni, consulta [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md).
1. Scegli il database globale Aurora nell'elenco, quindi scegli **Elimina** nel menu **Operazioni**.
![\[Un database globale Aurora basato su Aurora MySQL 5.6.10a rimane nella Console di gestione AWS finché non lo si elimina, anche se non dispone di alcun cluster database Aurora associato.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-ams5610a-delete-empty-cluster.png)
## AWS CLI
Per eliminare un database globale Aurora, esegui il comando della CLI [delete-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-global-cluster.html) con il nome della Regione AWS e l'identificatore del database globale Aurora, come illustrato nell'esempio seguente.
Per Linux, macOS o Unix:
```
aws rds --region primary_region delete-global-cluster \
--global-cluster-identifier global_database_id
```
Per Windows:
```
aws rds --region primary_region delete-global-cluster ^
--global-cluster-identifier global_database_id
```
## API RDS
Per eliminare un cluster che fa parte di un database globale Aurora, esegui l'operazione API [DeleteGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html).
# Applicazione di tag alle risorse Database globale Amazon Aurora
Con la funzionalità Database globale Aurora, è possibile applicare tag RDS a risorse a diversi livelli all’interno di un database globale. Se non conosci il modo in cui i tag vengono utilizzati con AWS o le risorse Aurora, consulta [Etichettatura delle risorse Amazon Aurora e Amazon RDS](USER_Tagging.md) prima di applicare i tag all’interno del database globale.
**Nota**
Poiché AWS elabora i dati dei tag come parte dei suoi meccanismi di rendicontazione dei costi, non includete dati sensibili o informazioni di identificazione personale (PII) nei nomi o nei valori dei tag.
È possibile applicare tag ai seguenti tipi di risorse in un database globale:
+ L’oggetto container per l’intero database globale. Questa risorsa è nota come cluster globale.
Dopo aver creato il cluster globale eseguendo un’operazione **Aggiungi AWS Regione** nella console, puoi aggiungere tag utilizzando la pagina dei dettagli per il cluster globale. Nella scheda **Tag** all’interno della pagina dei dettagli del cluster globale, puoi aggiungere, rimuovere o modificare i tag e i relativi valori associati scegliendo **Gestisci tag**.
Con AWS CLI e l’API RDS, puoi aggiungere tag al cluster globale contemporaneamente alla sua creazione. È inoltre possibile aggiungere, rimuovere o modificare tag per un cluster globale esistente.
+ Il cluster primario. Qui si utilizzano le stesse procedure per lavorare con i tag utilizzate per i cluster Aurora autonomi. È possibile configurare i tag prima di trasformare il cluster Aurora originale in un database globale. È possibile anche aggiungere, rimuovere o modificare i tag e i relativi valori associati scegliendo **Gestisci tag** nella scheda **Tag** all’interno della pagina dei dettagli del cluster di database
+ Qualsiasi cluster secondario. Qui si utilizzano le stesse procedure per lavorare con i tag utilizzate per i cluster Aurora autonomi. È possibile configurare i tag contemporaneamente alla creazione di un cluster Aurora secondario utilizzando l’azione **Aggiungi AWS Regione** nella console. È possibile anche aggiungere, rimuovere o modificare i tag e i relativi valori associati scegliendo **Gestisci tag** nella scheda **Tag** all’interno della pagina dei dettagli del cluster di database
+ Singole istanze database all’interno dei cluster primari o secondari. Qui si utilizzano le stesse procedure per lavorare con i tag utilizzate per le istanze database Aurora o RDS. È possibile configurare i tag contemporaneamente all’aggiunta di una nuova istanza database al cluster Aurora utilizzando l’azione **Aggiungi lettura** nella console. È possibile anche aggiungere, rimuovere o modificare i tag e i relativi valori associati scegliendo **Gestisci tag** nella scheda **Tag** all’interno della pagina dei dettagli dell’istanza database.
Ecco alcuni esempi dei tipi di tag che potresti assegnare all’interno di un database globale:
+ È possibile aggiungere tag al cluster globale per registrare informazioni generali sull’applicazione, ad esempio identificatori anonimi che rappresentano proprietari e contatti all’interno dell’organizzazione. È possibile utilizzare i tag per rappresentare le proprietà dell’applicazione che utilizza il database globale.
+ È possibile aggiungere tag al cluster primario e ai cluster secondari per tenere traccia dei costi dell’applicazione a livello di Regione AWS. Per i dettagli sulla procedura, consulta [Come funziona la AWS fatturazione con i tag in Amazon RDS](USER_Tagging.md#Tagging.Billing).
+ È possibile aggiungere tag a istanze database specifiche con i cluster Aurora per indicarne lo scopo speciale. Ad esempio, all’interno del cluster primario, potresti avere un’istanza di lettura con una priorità di failover bassa che viene utilizzata esclusivamente per la generazione di report. Un tag può distinguere questa istanza database per scopi speciali da altre istanze dedicate all’elevata disponibilità all’interno del cluster primario.
+ È possibile utilizzare i tag a tutti i livelli delle risorse globali del database per controllare l’accesso tramite le policy IAM. Per ulteriori informazioni, consulta [Controllo degli accessi alle risorse AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html#access_tags_control-resources) nella *Guida per l'utente di AWS Identity and Access Management*.
**Suggerimento**
In Console di gestione AWS, aggiungi tag al container del cluster globale come passaggio separato dopo averlo creato. Se desideri evitare intervalli di tempo in cui il cluster globale esiste senza tag di controllo degli accessi, puoi applicare i tag durante l’operazione `CreateGlobalCluster` creando quella risorsa tramite AWS CLI, l’API RDS o un modello CloudFormation.
+ È possibile utilizzare i tag a livello di cluster o per il cluster globale per registrare informazioni sul controllo della qualità e sui test dell’applicazione. Ad esempio, è possibile specificare un tag su un cluster di database per registrare l’ultima volta che è stato eseguito uno switchover a quel cluster. È possibile specificare un tag sul cluster globale per registrare l’ora dell’ultima esercitazione di disaster recovery per l’intera applicazione.
## Esempi AWS CLI di applicazione di tag per database globali
Gli esempi AWS CLI seguenti mostrano come specificare ed esaminare i tag per tutti i tipi di risorse Aurora nel database globale.
È possibile specificare i tag per il container del cluster globale con il comando `create-global-cluster`. Nell’esempio seguente viene creato un cluster globale a cui vengono assegnati due tag. I tag hanno chiavi `tag1` e `tag2`.
```
$ aws rds create-global-cluster --global-cluster-identifier my_global_cluster_id \
--engine aurora-mysql --tags Key=tag1,Value=val1 Key=tag2,Value=val2
```
È possibile elencare i tag nel container del cluster globale con il comando `describe-global-clusters`. Quando si utilizzano i tag, in genere si esegue prima questo comando per recuperare il nome della risorsa Amazon (ARN) del cluster globale. L’ARN viene utilizzato come parametro nei comandi successivi per l’utilizzo dei tag. Il comando seguente mostra le informazioni sui tag nell’attributo `TagList`. Mostra anche l’ARN, utilizzato come parametro negli esempi successivi.
```
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
"GlobalClusterArn": "my_global_cluster_arn",
...
"TagList": [
{
"Value": "val1",
"Key": "tag1"
},
{
"Value": "val2",
"Key": "tag2"
}
]
}
]
}
```
È possibile aggiungere nuovi tag con il comando `add-tags-to-resource`. Con questo comando, si specifica l’ARN del cluster globale anziché il suo identificatore. Aggiungendo un tag con lo stesso nome di un tag esistente viene sovrascritto il valore di quel tag. Se includi spazi o caratteri speciali nei valori dei tag, racchiudi i valori tra virgolette in base al sistema operativo o alla shell dei comandi in uso. L’esempio seguente modifica i tag del cluster globale rispetto all’esempio precedente. Originariamente, il cluster aveva tag con chiavi `tag1` e `tag2`. Al termine del comando, il cluster globale ha un nuovo tag con chiave `tag3` e il tag con chiave `tag1` ha un valore diverso.
```
$ aws rds add-tags-to-resource --resource-name my_global_cluster_arn \
--tags Key=tag1,Value="new value for tag1" Key=tag3,Value="entirely new tag"
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
...
"TagList": [
{
"Value": "new value for tag1",
"Key": "tag1"
},
{
"Value": "val2",
"Key": "tag2"
},
{
"Value": "entirely new tag",
"Key": "tag3"
}
]
}
]
}
```
È possibile eliminare un tag dal cluster globale con il comando `remove-tags-from-resource`. Con questo comando, si specifica solo un set di chiavi di tag, senza alcun valore di tag. L’esempio seguente modifica i tag del cluster globale rispetto all’esempio precedente. Originariamente, il cluster aveva tag con chiavi `tag1`, `tag2` e `tag3`. Al termine del comando, rimane solo il tag con la chiave `tag1`.
```
$ aws rds remove-tags-from-resource --resource-name my_global_cluster_arn --tag-keys tag2 tag3
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
...
"TagList": [
{
"Value": "new value for tag1",
"Key": "tag1"
}
]
}
]
}
```
# Connessione a Database globale Amazon Aurora
Ogni Database globale Aurora è dotato di un endpoint di scrittura che viene aggiornato automaticamente da Aurora per instradare le richieste all’istanza di scrittura corrente del cluster di database primario. Con l’endpoint di scrittura, non è necessario modificare la stringa di connessione dopo aver cambiato la posizione della Regione primaria utilizzando le funzionalità gestite di switchover e failover del Database globale Aurora. Per ulteriori informazioni sull’utilizzo dell’endpoint di scrittura insieme allo switchover e al failover del Database globale Aurora, consulta [Utilizzo dello switchover o failover in un Database globale Amazon Aurora](aurora-global-database-disaster-recovery.md). Per informazioni sulla connessione a un Database globale Aurora con Server proxy per RDS, consulta [Utilizzo del Server proxy per RDS con i database globali Aurora](https://docs.aws.amazon.com/AuroraUserGuide/rds-proxy-gdb.html).
**Topics**
+ [Scelta dell’endpoint che soddisfa le esigenze dell’applicazione](#gdb-endpoint-choosing)
+ [Visualizzazione degli endpoint di un database globale Amazon Aurora](#viewing-endpoints)
+ [Considerazioni sull’utilizzo degli endpoint di scrittura globali](#global-writer-endpoint-considerations)
## Scelta dell’endpoint che soddisfa le esigenze dell’applicazione
La connessione a un Database globale Aurora dipende dalla necessità di leggere o scrivere dal database e dalla Regione AWS a cui indirizzare le richieste. Ecco alcuni casi d’uso tipici:
+ **Instradamento delle richieste all’istanza di scrittura**: connettiti all’endpoint di scrittura Database globale Aurora se devi eseguire istruzioni DML (Data Manipulation Language) e DDL (Data Definition Language) o se ti serve una forte coerenza tra letture e scritture. Tale endpoint instrada le richieste all’istanza di scrittura nel cluster primario del database globale. Questo endpoint viene aggiornato automaticamente per instradare le richieste all’istanza di scrittura, eliminando la necessità di aggiornare l’applicazione ogni volta che si modifica la posizione di scrittura nel cluster globale. Puoi anche utilizzare l’endpoint globale per inviare richieste di lettura/scrittura tra Regioni diverse al tuo endpoint di scrittura.
**Nota**
Se hai configurato il database globale prima che l’endpoint di scrittura del Database globale Aurora fosse disponibile, l’applicazione potrebbe connettersi all’endpoint cluster del cluster primario. In questo caso, è consigliabile modificare le impostazioni di connessione in modo da utilizzare l’endpoint di scrittura globale. In questo modo si evita la necessità di modificare le impostazioni di connessione dopo ogni switchover o failover di Database globale Aurora.
La prima parte del nome dell’endpoint di scrittura è il nome del Database globale Aurora. Pertanto, se il Database globale Aurora viene rinominato, il nome dell’endpoint di scrittura cambia ed è necessario aggiornare tutto il codice che lo utilizza con il nuovo nome.
+ **Scalare le letture più vicino alla Regione dell’applicazione**: per scalare le richieste di sola lettura nella stessa Regione AWS dell’applicazione o in una Regione vicina, connettiti all’endpoint di lettura dei cluster Aurora primari o secondari.
+ **Scalare le letture con scritture occasionali tra Regioni**: per istruzioni DML occasionali, ad esempio per la manutenzione e la pulizia dei dati, connettiti all’endpoint di lettura di un cluster secondario con l’inoltro di scrittura abilitato. Con l’inoltro di scrittura, Aurora inoltra automaticamente le istruzioni di scrittura all’endpoint di scrittura nella Regione primaria del Database globale Aurora. L’inoltro di scrittura offre i seguenti vantaggi:
+ Non sono necessarie operazioni complesse per stabilire la connettività tra i cluster secondari e primari per inviare scritture tra Regioni.
+ Non è necessario dividere le richieste di lettura e scrittura nell’applicazione.
+ Non è necessario sviluppare una logica complessa per gestire la coerenza delle richieste di lettura dopo la scrittura.
Tuttavia, con l’inoltro di scrittura, è necessario aggiornare il codice o la configurazione dell’applicazione per connettersi all’endpoint di lettura della Regione primaria appena promossa dopo avere eseguito un failover o uno switchover tra Regioni. È consigliabile monitorare la latenza delle operazioni eseguite tramite l’inoltro di scrittura per controllare il sovraccarico di elaborazione delle richieste di scrittura. Infine, l’inoltro di scrittura non supporta determinate operazioni di MySQL o PostgreSQL, come l’esecuzione di modifiche DDL (Data Definition Language) o istruzioni `SELECT FOR UPDATE`.
Per ulteriori informazioni sull’utilizzo dell’inoltro di scrittura tra Regioni AWS, consulta [Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora](aurora-global-database-write-forwarding.md).
Per dettagli sui diversi tipi di endpoint Aurora, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
## Visualizzazione degli endpoint di un database globale Amazon Aurora
Quando nella console è presente un Database globale Aurora, è possibile visualizzare tutti gli endpoint generici associati a tutti i relativi cluster. La figura seguente mostra un esempio dei tipi di endpoint che vengono mostrati quando si visualizzano i dettagli del cluster di database primario:
+ Endpoint di scrittura globale: il singolo endpoint di lettura/scrittura che punta sempre all’istanza database di scrittura corrente per il cluster di database globale.
+ Endpoint di scrittura: l’endpoint di connessione per le richieste di lettura/scrittura al cluster di database primario nel cluster di database globale.
+ Endpoint di lettura: l’endpoint di connessione per le richieste di sola lettura a un cluster di database primario o secondario nel cluster di database globale. Per ridurre al minimo la latenza, scegli qualsiasi endpoint di lettura che si trova nella tua Regione AWS o nella Regione AWS più vicina.
![\[Nella console RDS, la scheda Connettività e sicurezza per un Database globale Aurora mostra l’endpoint di scrittura globale.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-primary-cluster-connectivity-2.png)
### Console
**Per visualizzare gli endpoint di un database globale**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegliere **Databases (Database)**.
1. Nell’elenco scegli il database globale o il cluster di database primario o secondario di cui vuoi visualizzare gli endpoint.
1. Scegli la scheda **Connettività e sicurezza** per visualizzare i dettagli dell’endpoint. Gli endpoint visualizzati dipendono dal tipo di cluster selezionato, come indicato di seguito:
+ Database globale: l’endpoint di scrittura globale.
+ Cluster di database primario: l’endpoint di scrittura globale e l’endpoint del cluster e l’endpoint di lettura per il cluster primario.
+ Cluster di database secondario: l’endpoint del cluster e l’endpoint di lettura per il cluster secondario. In un cluster secondario, lo stato dell’endpoint del cluster è **inattivo** perché non gestisce le richieste di scrittura. È comunque possibile connettersi all’endpoint del cluster, ma solo per le query di lettura.
### AWS CLI
Per visualizzare l’endpoint di scrittura del cluster globale, usa il comando AWS CLI [describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html), come nell’esempio seguente.
```
aws rds describe-global-clusters --region aws_region
{
"GlobalClusters": [
{
"GlobalClusterIdentifier": "global_cluster_id",
"GlobalClusterResourceId": "cluster-unique_string",
"GlobalClusterArn": "arn:aws:rds::123456789012:global-cluster:global_cluster_id",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2",
"GlobalClusterMembers": [
...
],
"Endpoint": "global_cluster_id.global-unique_string.global.rds.amazonaws.com"
}
]
}
```
Per visualizzare gli endpoint del cluster e di lettura per i cluster di database che fanno parte del cluster globale, usa il comando AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html), come nell’esempio seguente. I valori restituiti per `Endpoint` e `ReaderEndpoint` sono rispettivamente gli endpoint del cluster e di lettura.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier db_cluster_id
{
"DBClusters": [
{
"AllocatedStorage": 1,
"AvailabilityZones": [
"az_1",
"az_2",
"az_3"
],
"BackupRetentionPeriod": 1,
"DBClusterIdentifier": "db_cluster_id",
"DBClusterParameterGroup": "default.aurora-mysql5.7",
"DBSubnetGroup": "default",
"Status": "available",
"EarliestRestorableTime": "2023-08-01T18:21:11.301Z",
"Endpoint": "db_cluster_id.cluster-unique_string.primary_region.rds.amazonaws.com",
"ReaderEndpoint": "db_cluster_id.cluster-ro-unique_string.primary_region.rds.amazonaws.com",
"MultiAZ": false,
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2",
"ReadReplicaIdentifiers": [
"arn:aws:rds:secondary_region:123456789012:cluster:db_cluster_id"
],
"DBClusterMembers": [
{
"DBInstanceIdentifier": "db_instance_id",
"IsClusterWriter": true,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
}
],
...
"TagList": [],
"GlobalWriteForwardingRequested": false
}
]
}
```
### API RDS
Per visualizzare l’endpoint di scrittura del cluster globale, utilizza l’operazione [DescribeGlobalClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeGlobalClusters.html) dell’API RDS. Per visualizzare gli endpoint del cluster e di lettura per i cluster di database che fanno parte del cluster globale, utilizza l’operazione [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) dell’API RDS.
## Considerazioni sull’utilizzo degli endpoint di scrittura globali
Per utilizzare gli endpoint di scrittura del Database globale Aurora in modo efficiente, segui queste linee guida e best practice:
+ Per ridurre al minimo le interruzioni dopo un failover o uno switchover tra Regioni, puoi configurare la connettività VPC tra l’elaborazione dell’applicazione e le Regioni AWS primarie e secondarie. Ad esempio, supponiamo di avere applicazioni o sistemi client in esecuzione nello stesso VPC del cluster primario. Se il cluster secondario viene promosso, l’endpoint di scrittura globale cambia automaticamente in modo da puntare a quel cluster. Sebbene l’endpoint di scrittura globale consenta di evitare di modificare le impostazioni di connessione per l’applicazione, le applicazioni non sono in grado di accedere agli indirizzi IP nel VPC della Regione AWS primaria appena promossa finché non si configura la connessione di rete tra i due VPC. Per valutare le diverse opzioni per configurare questa connettività, consulta [Opzioni di connettività da Amazon VPC ad Amazon VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html).
+ L’aggiornamento dell’endpoint di scrittura globale dopo uno switchover o un failover globale del database può richiedere molto tempo a seconda della durata della memorizzazione nella cache DNS (Domain Name Service). Per ulteriori informazioni, consulta [Amazon Aurora MySQL Database Administrator’s Handbook](https://docs.aws.amazon.com/pdfs/whitepapers/latest/amazon-aurora-mysql-db-admin-handbook/amazon-aurora-mysql-db-admin-handbook.pdf). Il Database globale Aurora emette un evento RDS quando rileva la modifica del DNS sull’endpoint di scrittura globale. È possibile utilizzare l’evento per elaborare strategie per garantire che la cache DNS non si estenda oltre il periodo successivo alla generazione dell’evento. Per ulteriori informazioni, consulta [Eventi di cluster di database](USER_Events.Messages.md#USER_Events.Messages.cluster).
+ Il Database globale Aurora replica i dati in modo asincrono. I metodi di failover tra Regioni possono comportare la presenza di dati delle transazioni di scrittura non replicati nella secondaria scelta prima dell’inizio del failover. Sebbene Aurora tenti con il massimo impegno di bloccare le scritture nella Regione AWS primaria originale, il failover può essere soggetto a problemi di split-brain. Le considerazioni per ridurre al minimo la perdita di dati e il rischio di split-brain si applicano anche agli endpoint di scrittura del Database globale Aurora. Per ulteriori informazioni, consulta [Esecuzione di failover gestiti per database globali Aurora](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.managed-unplanned).
# Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora
È possibile ridurre il numero di endpoint che è necessario gestire per le applicazioni in esecuzione nel database globale Aurora utilizzando l' *inoltro in scrittura*. Quando la funzionalità di inoltro di scrittura è abilitata, i cluster secondari di un database globale Aurora inoltrano le istruzioni SQL che eseguono operazioni di scrittura al cluster primario. Il cluster primario aggiorna l'origine e quindi propaga le modifiche risultanti a tutte le aree secondarie AWS.
La funzione di inoltro di scrittura consente di evitare di implementare il proprio meccanismo per inviare operazioni di scrittura da una regione AWS secondaria alla regione principale. Aurora gestisce la configurazione di rete tra regioni. Aurora trasmette anche tutte le sessioni necessarie e il contesto transazionale per ogni dichiarazione. I dati vengono sempre modificati prima nel cluster primario e quindi replicati nuovamente nei cluster secondari nel database globale Aurora. In questo modo, il cluster primario è sempre la fonte di attendibilità con la copia più aggiornata di tutti i dati.
**Topics**
+ [Utilizzo dell'inoltro di scrittura in un database globale Aurora MySQL](aurora-global-database-write-forwarding-ams.md)
+ [Utilizzo dell'inoltro di scrittura in un database globale Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md)
# Utilizzo dell'inoltro di scrittura in un database globale Aurora MySQL
**Topics**
+ [Disponibilità di regioni e versioni dell'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-regions-versions-ams)
+ [Abilitazione dell'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-enabling-ams)
+ [Verifica se un cluster secondario ha abilitato l'inoltro di scrittura](#aurora-global-database-write-forwarding-describing-ams)
+ [Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-compatibility-ams)
+ [Isolamento e coerenza per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams)
+ [Esecuzione di istruzioni a più parti con inoltro scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-multipart-ams)
+ [Transazioni con inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-txns-ams)
+ [Parametri di configurazione per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-params-ams)
+ [Parametri Amazon CloudWatch per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-cloudwatch-ams)
+ [Variabili di stato di Aurora MySQL per l’inoltro di scrittura](#aurora-global-database-write-forwarding-status-ams)
## Disponibilità di regioni e versioni dell'inoltro di scrittura in Aurora MySQL
L'inoltro della scrittura è supportato con Aurora MySQL 2.08.1 e versioni successive in ogni regione in cui sono disponibili database globali basati su Aurora MySQL.
Per ulteriori informazioni sulla disponibilità di versioni e regioni dei database globali Aurora MySQL consulta [Database globali Aurora con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.amy).
## Abilitazione dell'inoltro di scrittura in Aurora MySQL
Per impostazione predefinita, l'inoltro di scrittura non è abilitato quando si aggiunge un cluster secondario a un database globale Aurora.
Per abilitare l'inoltro di scrittura mediante Console di gestione AWS, seleziona la casella di controllo **Attiva l'inoltro di scrittura globale** in **Inoltro di scrittura di repliche di lettura** quando aggiungi una regione per un database globale. Per un cluster secondario esistente, modifica il cluster in **Attiva l'inoltro di scrittura globale**. Per disattivare l'inoltro di scrittura, deseleziona la casella di controllo **Attiva l'inoltro di scrittura globale** durante l'aggiunta della regione o la modifica del cluster secondario.
Per abilitare l'inoltro di scrittura utilizzando l'AWS CLI, utilizzare l'opzione `--enable-global-write-forwarding`. Questa opzione funziona quando si crea un nuovo cluster secondario utilizzando il comando `create-db-cluster`. Funziona anche quando si modifica un cluster secondario esistente utilizzando il comando `modify-db-cluster`. Richiede che il database globale utilizzi una versione Aurora che supporti l'inoltro di scrittura. È possibile disattivare l'inoltro di scrittura utilizzando l'opzione `--no-enable-global-write-forwarding` con questi stessi comandi CLI.
Per abilitare l'inoltro di scrittura utilizzando l'API Amazon RDS, impostare il parametro `EnableGlobalWriteForwarding` su `true`. Questo parametro funziona quando si crea un nuovo cluster secondario utilizzando l'operazione `CreateDBCluster`. Funziona anche quando si modifica un cluster secondario esistente utilizzando l'operazione `ModifyDBCluster`. Richiede che il database globale utilizzi una versione Aurora che supporti l'inoltro di scrittura. È possibile disattivare l'inoltro di scrittura impostando il parametro `EnableGlobalWriteForwarding` su `false`.
**Nota**
Per utilizzare l'inoltro in scrittura in una sessione di database, specifica un'impostazione per il parametro di configurazione `aurora_replica_read_consistency`. Eseguire questa operazione in ogni sessione che utilizza la funzionalità di inoltro di scrittura. Per informazioni su questo parametro, consulta [Isolamento e coerenza per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams).
La funzionalità RDS Proxy non supporta il valore `SESSION` della variabile `aurora_replica_read_consistency`, la cui impostazione può causare un comportamento imprevisto.
Negli esempi seguenti di CLI viene illustrato come impostare un database globale Aurora con l'inoltro di scrittura abilitato o disabilitato. Gli elementi evidenziati rappresentano i comandi e le opzioni che è importanti specificare e mantenere coerenti quando si imposta l'infrastruttura per un Aurora Global Database.
Nell'esempio seguente viene creato un Aurora Global Database, un cluster primario e un cluster secondario con l'inoltro di scrittura abilitato. Sostituire il nome utente, la password e le regioni AWS primarie e secondarie.
```
# Create overall global database.
aws rds create-global-cluster --global-cluster-identifier write-forwarding-test \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
# Create primary cluster, in the same AWS Region as the global database.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-1 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--master-username user_name --master-user-password password \
--region us-east-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
--db-instance-identifier write-forwarding-test-cluster-1-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
--db-instance-identifier write-forwarding-test-cluster-1-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
# Create secondary cluster, in a different AWS Region than the global database,
# with write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-2 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2 \
--enable-global-write-forwarding
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2
```
L'esempio seguente continua dal precedente. Crea un cluster secondario senza l'inoltro di scrittura abilitato, quindi abilita l'inoltro di scrittura. Al termine di questo esempio, tutti i cluster secondari del database globale hanno attivato l'inoltro di scrittura.
```
# Create secondary cluster, in a different AWS Region than the global database,
# without write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-2 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds modify-db-cluster --db-cluster-identifier write-forwarding-test-cluster-2 \
--region us-east-2 \
--enable-global-write-forwarding
```
## Verifica se un cluster secondario ha abilitato l'inoltro di scrittura
Per determinare se è possibile utilizzare l'inoltro di scrittura da un cluster secondario, è possibile verificare se il cluster dispone dell'attributo `"GlobalWriteForwardingStatus": "enabled"`.
Nella Console di gestione AWS, nella scheda **Configurazione** della pagina dei dettagli del cluster, viene visualizzato lo stato **Abilitato** per **Inoltro di scrittura di repliche di lettura globali**.
Per visualizzare lo stato dell'impostazione di inoltro di scrittura globale per tutti i cluster, eseguire il comando AWS CLI seguente.
Un cluster secondario mostra il valore `"enabled"` o `"disabled"` per indicare se l'inoltro di scrittura è attivato o disattivato. Il valore `null` indica che l'inoltro di scrittura non è disponibile per il cluster. Il cluster non fa parte di un database globale oppure è il cluster primario anziché un cluster secondario. Il valore può anche essere `"enabling"` o `"disabling"` se l'inoltro di scrittura è in procinto di essere attivato o disattivato.
**Example**
```
aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
{
"GlobalWriteForwardingStatus": "enabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
},
{
"GlobalWriteForwardingStatus": "disabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
},
{
"GlobalWriteForwardingStatus": null,
"DBClusterIdentifier": "non-global-cluster"
}
]
```
Per trovare tutti i cluster secondari per i quali è abilitato l'inoltro di scrittura globale, eseguire il comando seguente. Questo comando restituisce anche l'endpoint di lettura del cluster. È possibile utilizzare l'endpoint di lettura del cluster secondario quando si utilizza l'inoltro di scrittura dal cluster secondario al primario nel database globale Aurora.
**Example**
```
aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
{
"GlobalWriteForwardingStatus": "enabled",
"ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
}
]
```
## Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura in Aurora MySQL
È possibile utilizzare i seguenti tipi di istruzioni SQL con l'inoltro di scrittura:
+ Istruzioni DML (Data Manipulation Language), ad esempio `INSERT`, `DELETE` e `UPDATE`. Esistono alcune restrizioni sulle proprietà di queste istruzioni che è possibile utilizzare con l'inoltro di scrittura, come descritto di seguito.
+ Istruzioni `SELECT ... LOCK IN SHARE MODE` e `SELECT FOR UPDATE`.
+ Istruzioni `PREPARE` e `EXECUTE`.
Alcune istruzioni non sono consentite o possono produrre risultati non aggiornati quando vengono utilizzate in un database globale con inoltro di scrittura. Pertanto, l'impostazione `EnableGlobalWriteForwarding` è disattivata in modo predefinito per i cluster secondari. Prima di attivarlo, verificare che il codice dell'applicazione non sia interessato da nessuna di queste restrizioni.
Le seguenti restrizioni si applicano alle istruzioni SQL utilizzate con l'inoltro di scrittura. In alcuni casi, è possibile utilizzare le istruzioni su cluster secondari con l'inoltro di scrittura abilitato a livello di cluster. Questo approccio funziona se l'inoltro di scrittura non è attivato all'interno della sessione dal parametro di configurazione `aurora_replica_read_consistency`. Se si tenta di utilizzare un'istruzione quando non è consentito a causa dell'inoltro di scrittura, viene generato un messaggio di errore con il formato seguente.
```
ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.
```
**DDL (Data Definition Language)**
Connettersi al cluster primario per eseguire le istruzioni DDL. Non è possibile eseguirle da istanze database di lettura.
**Aggiornamento di una tabella permanente utilizzando i dati di una tabella temporanea**
È possibile utilizzare tabelle temporanee in cluster secondari con l'inoltro di scrittura abilitato. Tuttavia, non è possibile utilizzare un'istruzione DML per modificare una tabella permanente se l'istruzione fa riferimento a una tabella temporanea. Ad esempio, non è possibile utilizzare un'istruzione `INSERT ... SELECT` che accetta i dati da una tabella temporanea. La tabella temporanea esiste nel cluster secondario e non è disponibile quando l'istruzione viene eseguita nel cluster primario.
**Transazioni XA**
Non è possibile utilizzare le istruzioni seguenti in un cluster secondario quando l'inoltro di scrittura è attivato all'interno della sessione. È possibile utilizzare queste istruzioni su cluster secondari per i quali non è abilitato l'inoltro di scrittura o all'interno di sessioni in cui l'impostazione `aurora_replica_read_consistency` è vuota. Prima di attivare l'inoltro di scrittura all'interno di una sessione, verificare se il codice utilizza queste istruzioni.
```
XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER [CONVERT XID]
```
**Istruzioni LOAD per tabelle permanenti**
Non è possibile utilizzare le istruzioni seguenti in un cluster secondario con l'inoltro di scrittura abilitato.
```
LOAD DATA INFILE 'data.txt' INTO TABLE t1;
LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
```
È possibile caricare i dati in una tabella temporanea in un cluster secondario. Tuttavia, assicurarsi di eseguire tutte le istruzioni `LOAD` che fanno riferimento a tabelle permanenti solo nel cluster primario.
**Istruzioni plugin**
Non è possibile utilizzare le istruzioni seguenti in un cluster secondario con l'inoltro di scrittura abilitato.
```
INSTALL PLUGIN example SONAME 'ha_example.so';
UNINSTALL PLUGIN example;
```
**Istruzioni SAVEPOINT**
Non è possibile utilizzare le istruzioni seguenti in un cluster secondario quando l'inoltro di scrittura è attivato all'interno della sessione. È possibile utilizzare queste istruzioni su cluster secondari per i quali non è abilitato l'inoltro di scrittura o all'interno di sessioni in cui l'impostazione `aurora_replica_read_consistency` è vuota. Controlla se il tuo codice utilizza queste istruzioni prima di attivare l'inoltro di scrittura all'interno di una sessione.
```
SAVEPOINT t1_save;
ROLLBACK TO SAVEPOINT t1_save;
RELEASE SAVEPOINT t1_save;
```
## Isolamento e coerenza per l'inoltro di scrittura in Aurora MySQL
Nelle sessioni che utilizzano l'inoltro di scrittura, è possibile utilizzare solo il livello di isolamento `REPEATABLE READ`. Sebbene sia anche possibile utilizzare il livello di isolamento `READ COMMITTED` con cluster di sola lettura nelle regioni AWS secondarie, tale livello di isolamento non funziona con l'inoltro di scrittura. Per informazioni sui livelli di isolamento `REPEATABLE READ` e `READ COMMITTED`, consulta [Livelli di isolamento di Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md).
È possibile controllare il grado di coerenza di lettura in un cluster secondario. Il livello di coerenza di lettura determina la quantità di attesa di un cluster secondario prima di ogni operazione di lettura per garantire che alcune o tutte le modifiche vengano replicate dal cluster primario. È possibile regolare il livello di coerenza di lettura per garantire che tutte le operazioni di scrittura inoltrate dalla sessione siano visibili nel cluster secondario prima di qualsiasi query successiva. È inoltre possibile utilizzare questa impostazione per garantire che le query sul cluster secondario visualizzino sempre gli aggiornamenti più recenti dal cluster primario. Ciò si verifica anche per quelli inviati da altre sessioni o altri cluster. Per specificare questo tipo di comportamento per l'applicazione, scegliere un valore per il parametro a livello di sessione `aurora_replica_read_consistency`.
**Importante**
Impostare sempre il parametro `aurora_replica_read_consistency` per qualsiasi sessione per la quale si desidera inoltrare le scritture. In caso contrario, Aurora non abilita l'inoltro di scrittura per quella sessione. Questo parametro ha un valore vuoto per impostazione predefinita, quindi scegli un valore specifico quando utilizzi questo parametro. Il parametro `aurora_replica_read_consistency` ha effetto solo sui cluster secondari in cui è abilitato l'inoltro di scrittura.
Per Aurora MySQL versione 2 e versione 3 inferiori alla 3.04, usa `aurora_replica_read_consistency` come variabile di sessione. Per Aurora MySQL versione 3.04 e successive, è possibile usare `aurora_replica_read_consistency` come variabile di sessione o come un parametro del cluster database.
Per il parametro `aurora_replica_read_consistency`, è possibile specificare i valori `EVENTUAL`, `SESSION` e `GLOBAL`.
Aumentando il livello di coerenza, l'applicazione impiega più tempo in attesa della propagazione delle modifiche tra regioni AWS. È possibile scegliere il bilanciamento tra tempi di risposta rapidi e garantire che le modifiche apportate in altre posizioni siano completamente disponibili prima dell'esecuzione delle query.
Con la coerenza di lettura impostata su `EVENTUAL`, le query in una regione AWS secondaria che utilizza l'inoltro di scrittura potrebbero vedere dati leggermente obsoleti a causa del ritardo di replica. I risultati delle operazioni di scrittura nella stessa sessione non sono visibili fino a quando l'operazione di scrittura non viene eseguita nella regione primaria e replicata nella regione corrente. La query non attende la disponibilità dei risultati aggiornati. Pertanto, potrebbe recuperare i dati meno recenti o i dati aggiornati, a seconda della tempistica delle istruzioni e della quantità di ritardo di replica.
Con la coerenza di lettura impostata su `SESSION`, tutte le query in una regione AWS secondaria, che utilizza l'inoltro di scrittura, visualizzano i risultati di tutte le modifiche apportate in tale sessione. Le modifiche sono visibili indipendentemente dal fatto che la transazione sia stata impegnata. Se necessario, la query attende che i risultati delle operazioni di scrittura inoltrate vengano replicati nell'area corrente. Non attende i risultati aggiornati delle operazioni di scrittura eseguite in altre regioni o in altre sessioni all'interno dell'area corrente.
Con la coerenza di lettura impostata su `GLOBAL`, una sessione in una regione AWS secondaria vede le modifiche apportate da quella sessione. Vede inoltre tutte le modifiche impegnate sia dalla regione AWS primaria che da altre regioni AWS secondarie. Ogni query potrebbe attendere un periodo che varia a seconda della quantità di ritardo della sessione. La query procede quando il cluster secondario è aggiornato con tutti i dati di commit dal cluster primario, a partire dal momento in cui la query è iniziata.
Per ulteriori informazioni su tutti i parametri coinvolti nell'inoltro di scrittura, consulta [Parametri di configurazione per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-params-ams).
### Esempi di utilizzo dell'inoltro di scrittura
Questi esempi utilizzano `aurora_replica_read_consistency` come una variabile di sessione. Per Aurora MySQL versione 3.04 e successive, è possibile usare `aurora_replica_read_consistency` come variabile di sessione o come un parametro del cluster database.
Nell'esempio seguente, il cluster primario si trova nella regione US East (N. Virginia). Il cluster secondario si trova nella regione Stati Uniti orientali (Ohio). L'esempio mostra gli effetti delle istruzioni `INSERT` in esecuzione seguite da istruzioni `SELECT`. A seconda del valore dell'impostazione `aurora_replica_read_consistency`, i risultati potrebbero differire a seconda della tempistica delle istruzioni. Per ottenere una maggiore coerenza, è possibile attendere brevemente prima di rilasciare l’istruzione `SELECT`. Oppure Aurora può attendere automaticamente il completamento della replica dei risultati prima di procedere con `SELECT`.
In questo esempio, è disponibile un'impostazione di coerenza di lettura di `eventual`. L'esecuzione di una istruzione `INSERT` immediatamente seguita da una istruzione `SELECT` restituisce ancora il valore di `COUNT(*)`. Questo valore riflette il numero di righe prima dell'inserimento della nuova riga. Se poco dopo si esegue nuovamente `SELECT`, viene restituito il conteggio delle righe aggiornato. Le istruzioni `SELECT` non attendono.
```
mysql> set aurora_replica_read_consistency = 'eventual';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.00 sec)
mysql> insert into t1 values (6); select count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 6 |
+----------+
1 row in set (0.00 sec)
```
Con un'impostazione di coerenza di lettura di `session`, un'istruzione `SELECT` immediatamente dopo un `INSERT` attende fino a quando le modifiche dall'istruzione `INSERT` diventano visibili. Le istruzioni `SELECT` successive non attendono.
```
mysql> set aurora_replica_read_consistency = 'session';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 6 |
+----------+
1 row in set (0.01 sec)
mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1;
Query OK, 1 row affected (0.08 sec)
+----------+
| count(*) |
+----------+
| 7 |
+----------+
1 row in set (0.37 sec)
+----------+
| count(*) |
+----------+
| 7 |
+----------+
1 row in set (0.00 sec)
```
Con l'impostazione di coerenza di lettura ancora impostata su `session`, l'introduzione di una breve attesa dopo l'esecuzione di un'istruzione `INSERT` rende disponibile il conteggio delle righe aggiornate dal momento dell'esecuzione dell'istruzione `SELECT` successiva.
```
mysql> insert into t1 values (6); select sleep(2); select count(*) from t1;
Query OK, 1 row affected (0.07 sec)
+----------+
| sleep(2) |
+----------+
| 0 |
+----------+
1 row in set (2.01 sec)
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.00 sec)
```
Con un'impostazione di coerenza di lettura di `global`, ogni istruzione `SELECT` attende di assicurarsi che tutte le modifiche ai dati a partire dall'ora di inizio dell'istruzione siano visibili prima di eseguire la query. La quantità di attesa per ogni istruzione `SELECT` varia a seconda della quantità di ritardo di replica tra i cluster primario e secondario.
```
mysql> set aurora_replica_read_consistency = 'global';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.75 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.37 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.66 sec)
```
## Esecuzione di istruzioni a più parti con inoltro scrittura in Aurora MySQL
Un'istruzione DML può essere costituita da più parti, ad esempio un'istruzione `INSERT ... SELECT` o `DELETE ... WHERE`. In questo caso, l'intera istruzione viene inoltrata al cluster primario ed eseguita lì.
## Transazioni con inoltro di scrittura in Aurora MySQL
Se la transazione viene inoltrata al cluster primario dipende dalla modalità di accesso della transazione. È possibile specificare la modalità di accesso per la transazione utilizzando l'istruzione `SET TRANSACTION` o `START TRANSACTION`. È anche possibile specificare la modalità di accesso alle transazioni modificando il valore della variabile di sessione [transaction\$1read\$1only](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_transaction_read_only). È possibile modificare questo valore di sessione solo quando si è connessi a un cluster database in cui l'inoltro di scrittura è abilitato.
Se una transazione di lunga durata non emette alcuna dichiarazione per un periodo di tempo considerevole, potrebbe superare il periodo di timeout inattivo. Questo periodo ha un valore predefinito di un minuto. Puoi aumentarlo fino a un giorno. Una transazione che supera il timeout di inattività viene annullata dal cluster primario. L'istruzione successiva inviata riceve un errore di timeout. Quindi Aurora esegue il rollback della transazione.
Questo tipo di errore può verificarsi in altri casi in cui l'inoltro di scrittura non diventa disponibile. Ad esempio, Aurora annulla tutte le transazioni che utilizzano l'inoltro di scrittura se si riavvia il cluster primario o se si disattiva l'impostazione di configurazione dell'inoltro di scrittura.
## Parametri di configurazione per l'inoltro di scrittura in Aurora MySQL
I gruppi di parametri del cluster Aurora contengono delle impostazioni per la funzionalità di inoltro di scrittura. Poiché si tratta di parametri cluster, tutte le istanze database in ogni cluster hanno gli stessi valori per queste variabili. I dettagli su questi parametri sono riepilogati nella tabella seguente, con note di utilizzo dopo la tabella.
| Nome | Ambito | Tipo | Valore predefinito | Valori validi |
| --- | --- | --- | --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout (Aurora MySQL versione 2) | Globale | unsigned integer | 60 | 1–86.400 |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct (Aurora MySQL versione 2) | Globale | intero lungo senza segno | 10 | 0–90 |
| aurora\$1fwd\$1writer\$1idle\$1timeout (Aurora MySQL version 3) | Globale | unsigned integer | 60 | 1–86.400 |
| aurora\$1fwd\$1writer\$1max\$1connections\$1pct (Aurora MySQL version 3) | Globale | intero lungo senza segno | 10 | 0–90 |
| aurora\$1replica\$1read\$1consistency | Sessione per versione 2 e versione 3 inferiori alla 3.04, Global per versione 3.04 e successive | Enum | '' (null) | EVENTUAL, SESSION, GLOBAL |
Per controllare le richieste di scrittura in ingresso da cluster secondari, utilizza le seguenti impostazioni nel cluster primario:
+ `aurora_fwd_master_idle_timeout`, `aurora_fwd_writer_idle_timeout`: il numero di secondi in cui il cluster primario attende l'attività su una connessione inoltrata da un cluster secondario prima di chiuderla. Se la sessione rimane inattiva oltre questo periodo, la sessione viene annullata da Aurora.
+ `aurora_fwd_master_max_connections_pct`, `aurora_fwd_writer_max_connections_pct`: il limite superiore delle connessioni al database che può essere utilizzato su un'istanza database writer per gestire le query inoltrate dai lettori. Viene espresso come percentuale dell'impostazione `max_connections` per l'istanza database writer nel cluster primario. Ad esempio, se `max_connections` è 800 e `aurora_fwd_master_max_connections_pct` o `aurora_fwd_writer_max_connections_pct` è 10, allora lo scrittore consente un massimo di 80 sessioni inoltrate simultanee. Queste connessioni provengono dallo stesso pool di connessioni gestito dall'impostazione `max_connections`.
Questa impostazione si applica solo al cluster primario, quando uno o più cluster secondari hanno abilitato l'inoltro di scrittura. Se si riduce il valore, le connessioni esistenti non vengono influenzate. Aurora tiene in considerazione il nuovo valore dell’impostazione quando si prova a creare una nuova connessione da un cluster secondario. Il valore predefinito è 10, che rappresenta il 10% del valore `max_connections`. Se si abilita l'inoltro di query su uno qualsiasi dei cluster secondari, questa impostazione deve avere un valore diverso da zero affinché le operazioni di scrittura dai cluster secondari abbiano esito positivo. Se il valore è zero, le operazioni di scrittura ricevono il codice di errore `ER_CON_COUNT_ERROR` con il messaggio `Not enough connections on writer to handle your request`.
Il `aurora_replica_read_consistency` parametro consente l’inoltro di scrittura. Lo si utilizza in ogni sessione. È possibile specificare `EVENTUAL`, `SESSION` o `GLOBAL` per il livello di coerenza di lettura. Per ulteriori informazioni sui livelli di coerenza, consulta [Isolamento e coerenza per l'inoltro di scrittura in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams). A questo parametro si applicano le seguenti regole:
+ Il valore predefinito è " (empty).
+ L'inoltro di scrittura è disponibile in una sessione solo se `aurora_replica_read_consistency` è impostato su `EVENTUAL` o `SESSION` o `GLOBAL`. Questo parametro è rilevante solo nelle istanze di lettura di cluster secondari che hanno l'inoltro di scrittura abilitato e che si trovano in un Aurora Global Database.
+ Non è possibile impostarlo come variabile (quando vuoto) o unset (se già impostato) all'interno di una transazione multiistruzione. Tuttavia, è possibile modificarlo da un valore valido (`EVENTUAL``SESSION`, o `GLOBAL`) a un altro valore valido (`EVENTUAL``SESSION`, o `GLOBAL`) durante tale transazione.
+ La variabile non può essere `SET` quando l'inoltro di scrittura non è abilitato nel cluster secondario.
## Parametri Amazon CloudWatch per l'inoltro di scrittura in Aurora MySQL
I parametri Amazon CloudWatch seguenti si applicano al cluster primario quando si utilizza l'inoltro di scrittura su uno o più cluster secondari. Questi parametri sono tutti misurati sull'istanza database writer nel cluster primario.
| Parametro CloudWatch | Unità | Descrizione |
| --- | --- | --- |
| `AuroraDMLRejectedMasterFull` | Conteggio | Il numero di query inoltrate che vengono rifiutate perché la sessione è piena sull’istanza database di scrittura. Aurora MySQL versione 2 |
| `AuroraDMLRejectedWriterFull` | Conteggio | Il numero di query inoltrate che vengono rifiutate perché la sessione è piena sull’istanza database di scrittura. Per Aurora MySQL versione 3. |
| `ForwardingMasterDMLLatency` | Millisecondi | Tempo medio per elaborare ogni istruzione DML inoltrata sull'istanza database writer. Non include il tempo impiegato dal cluster secondario per inoltrare la richiesta di scrittura o il tempo necessario per replicare le modifiche al cluster secondario. Aurora MySQL versione 2 |
| `ForwardingMasterDMLThroughput` | Conteggio al secondo | Numero di istruzioni DML inoltrate elaborate ogni secondo da questa istanza database writer. Aurora MySQL versione 2 |
| `ForwardingMasterOpenSessions` | Conteggio | Numero di sessioni inoltrate sull'istanza database writer. Aurora MySQL versione 2 |
| `ForwardingWriterDMLLatency` | Millisecondi | Tempo medio per elaborare ogni istruzione DML inoltrata sull'istanza database writer. Non include il tempo impiegato dal cluster secondario per inoltrare la richiesta di scrittura o il tempo necessario per replicare le modifiche al cluster secondario. Per Aurora MySQL versione 3. |
| `ForwardingWriterDMLThroughput` | Conteggio al secondo | Numero di istruzioni DML inoltrate elaborate ogni secondo da questa istanza database writer.Per Aurora MySQL versione 3. |
| `ForwardingWriterOpenSessions` | Conteggio | Numero di sessioni inoltrate sull'istanza database writer.Per Aurora MySQL versione 3. |
I parametri CloudWatch seguenti si applicano a ciascun cluster secondario. Questi parametri vengono misurati su ogni istanza database del lettore in un cluster secondario con l'inoltro di scrittura abilitato.
| Parametro CloudWatch | Unità | Descrizione |
| --- | --- | --- |
| `ForwardingReplicaDMLLatency` | Millisecondi | Tempo medio di risposta di DML inoltrati sulla replica. |
| `ForwardingReplicaDMLThroughput` | Conteggio al secondo | Numero di istruzioni DML inoltrate elaborate al secondo. |
| `ForwardingReplicaOpenSessions` | Conteggio | Numero di sessioni che utilizzano l'inoltro di scrittura su un'istanza database di lettura. |
| `ForwardingReplicaReadWaitLatency` | Millisecondi | Tempo medio di attesa di un'istruzione `SELECT` su un'istanza del database di scrittura prima di raggiungere il cluster primario. Il grado di attesa dell'istanza database del lettore prima di elaborare una query dipende dall'impostazione `aurora_replica_read_consistency`. |
| `ForwardingReplicaReadWaitThroughput` | Conteggio al secondo | Numero totale di istruzioni SELECT elaborate ogni secondo in tutte le sessioni che inoltrano scritture. |
| `ForwardingReplicaSelectLatency` | Millisecondi | Latenza inoltrata SELECT, media su tutte le istruzioni inoltrate SELECT entro il periodo di monitoraggio. |
| `ForwardingReplicaSelectThroughput` | Conteggio al secondo | Throughput inoltrato medio per secondo SELECT all'interno del periodo di monitoraggio. |
## Variabili di stato di Aurora MySQL per l’inoltro di scrittura
Le variabili di stato Aurora MySQL seguenti si applicano al cluster primario quando si utilizza l’inoltro di scrittura su uno o più cluster secondari. Questi parametri sono tutti misurati sull'istanza database writer nel cluster primario.
| Variabile di stato Aurora MySQL | Unità | Descrizione |
| --- | --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Conteggio | Numero totale di istruzioni DML inoltrate a questa istanza database writer.Aurora MySQL versione 2 |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni DML inoltrate a questa istanza database writer. Aurora MySQL versione 2 |
| Aurora\$1fwd\$1master\$1open\$1sessions | Conteggio | Numero di sessioni inoltrate sull'istanza database writer. Aurora MySQL versione 2 |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Conteggio | Numero totale di istruzioni `SELECT` inoltrate a questa istanza database writer. Aurora MySQL versione 2 |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni `SELECT` inoltrate a questa istanza database writer. Aurora MySQL versione 2 |
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | Conteggio | Numero totale di istruzioni DML inoltrate a questa istanza database writer.Per Aurora MySQL versione 3. |
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni DML inoltrate a questa istanza database writer. |
| Aurora\$1fwd\$1writer\$1open\$1sessions | Conteggio | Numero di sessioni inoltrate sull'istanza database writer.Per Aurora MySQL versione 3. |
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | Conteggio | Numero totale di istruzioni `SELECT` inoltrate a questa istanza database writer.Per Aurora MySQL versione 3. |
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni `SELECT` inoltrate a questa istanza database writer. Per Aurora MySQL versione 3. |
Le variabili di stato Aurora MySQL seguenti si applicano a ciascun cluster secondario. Questi parametri vengono misurati su ogni istanza database del lettore in un cluster secondario con l'inoltro di scrittura abilitato.
| Variabile di stato Aurora MySQL | Unità | Descrizione |
| --- | --- | --- |
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1count | Conteggio | Numero totale di istruzioni DML inoltrate da questa istanza database del lettore. |
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni DML inoltrate da questa istanza database del lettore. |
| Aurora\$1fwd\$1replica\$1errors\$1session\$1limit | Conteggio | Numero di sessioni rifiutate dal cluster primario a causa di una delle seguenti condizioni di errore: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding-ams.html) |
| Aurora\$1fwd\$1replica\$1open\$1sessions | Conteggio | Numero di sessioni che utilizzano l'inoltro di scrittura su un'istanza database di lettura. |
| Aurora\$1fwd\$1replica\$1read\$1wait\$1count | Conteggio | Numero totale di attese di lettura-post-scrittura su questa istanza database del lettore. |
| Aurora\$1fwd\$1replica\$1read\$1wait\$1duration | Microsecondi | Durata totale delle attese a causa dell'impostazione di coerenza di lettura su questa istanza database del lettore. |
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1count | Conteggio | Numero totale di istruzioni SELECT inoltrate dall'istanza database del lettore. |
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1duration | Microsecondi | Durata totale delle istruzioni SELECT inoltrate da questa istanza database del lettore. |
# Utilizzo dell'inoltro di scrittura in un database globale Aurora PostgreSQL
**Topics**
+ [Disponibilità di regioni e versioni dell'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-regions-versions-apg)
+ [Abilitazione dell'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-enabling-apg)
+ [Verifica se un cluster secondario ha abilitato l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-describing-apg)
+ [Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-compatibility-apg)
+ [Isolamento e coerenza per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-isolation-apg)
+ [Modalità di accesso alle transazioni con inoltro scrittura](#aurora-global-database-write-forwarding-txns)
+ [Esecuzione di istruzioni a più parti con inoltro scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-multipart-apg)
+ [Parametri di configurazione per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg)
+ [CloudWatch Parametri Amazon per l'inoltro della scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-cloudwatch-apg)
+ [Eventi di attesa per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-wait-events-apg)
## Disponibilità di regioni e versioni dell'inoltro di scrittura in Aurora PostgreSQL
In Aurora PostgreSQL versione 16 e versioni principali successive, l’inoltro globale di scrittura è supportato in tutte le versioni secondarie. Per versioni precedenti di Aurora PostgreSQL, l’inoltro di scrittura è supportato con la versione 15.4 e versioni secondarie successive e versione 14.9 e versioni secondarie successive. L'inoltro di scrittura è disponibile in tutte le AWS regioni in cui sono disponibili database globali basati su Aurora PostgreSQL.
Per ulteriori informazioni sulla disponibilità di versioni e regioni dei database globali Aurora PostgreSQL consulta [Database globali Aurora con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.apg).
## Abilitazione dell'inoltro di scrittura in Aurora PostgreSQL
Per impostazione predefinita, l'inoltro di scrittura non è abilitato quando si aggiunge un cluster secondario a un Aurora Global Database. È possibile abilitare l'inoltro di scrittura per il cluster di database secondario durante la creazione o in qualsiasi momento dopo averlo creato. Se necessario, puoi disabilitarlo in un secondo momento. L'attivazione o la disabilitazione dell'inoltro di scrittura non causa tempi di inattività o il riavvio.
**Nota**
È possibile utilizzare l'inoltro locale di scrittura per le applicazioni che richiedono operazioni di scrittura occasionali e richiedono read-after-write coerenza, ovvero la capacità di leggere l'ultima scrittura in una transazione.
### Console
Nella console è possibile attivare o disattivare l'inoltro di scrittura quando si crea o si modifica un cluster di database secondario.
#### Abilitazione o disabilitazione dell'inoltro di scrittura durante la creazione di un cluster di database secondario
Quando crei un nuovo cluster di database secondario, abiliti l'inoltro di scrittura selezionando la casella di controllo **Attiva l'inoltro di scrittura globale** in **Abilita inoltro in scrittura della replica in lettura**. Oppure deseleziona la casella di controllo per disabilitarlo. Per creare un cluster di database secondario, segui le istruzioni in [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Lo screenshot seguente mostra la sezione **Abilita inoltro in scrittura della replica in lettura** con la casella di controllo **Attiva l'inoltro di scrittura globale** selezionata.
![\[\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-enable-write-forwarding.png)
#### Abilitazione o disabilitazione dell'inoltro di scrittura durante la modifica di un cluster di database secondario
È possibile modificare un cluster di database secondario nella console per abilitare o disabilitare l'inoltro di scrittura.
**Per abilitare o disabilitare l'inoltro di scrittura per un cluster di database secondario utilizzando la console**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database**.
1. Scegli il cluster di database secondario e scegli **Modifica**.
1. Nella sezione **Abilita inoltro in scrittura della replica in lettura**, seleziona o deseleziona la casella di controllo **Attiva l'inoltro di scrittura globale**.
1. Scegli **Continua**.
1. In **Pianificazione delle modifiche**, scegli **Applica immediatamente**. Se scegli **Applica durante la prossima finestra di manutenzione pianificata**, Aurora ignora questa impostazione e attiva immediatamente l'inoltro di scrittura.
1. Scegliere **Modify cluster (Modifica cluster)**.
### AWS CLI
Per abilitare l'inoltro di scrittura utilizzando AWS CLI, usa l'opzione. `--enable-global-write-forwarding` Questa opzione funziona quando si crea un nuovo cluster secondario utilizzando il comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html). Funziona anche quando si modifica un cluster secondario esistente utilizzando il comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Richiede che il database globale utilizzi una versione Aurora che supporti l'inoltro di scrittura. Puoi disattivare l'inoltro di scrittura mediante l'opzione `--no-enable-global-write-forwarding` con questi stessi comandi CLI.
Le seguenti procedure descrivono come abilitare o disabilitare l'inoltro di scrittura per un cluster di database secondario nel cluster globale utilizzando la AWS CLI.
**Per abilitare o disabilitare l'inoltro di scrittura per un cluster di database secondario esistente**
+ Chiamate il [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI comando e fornite i seguenti valori:
+ `--db-cluster-identifier`: il nome del cluster di database.
+ `--enable-global-write-forwarding` per attivare o `--no-enable-global-write-forwarding` per disattivare.
L'esempio seguente mostra come abilitare l'inoltro di scrittura per un cluster di database `sample-secondary-db-cluster`.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-secondary-db-cluster \
--enable-global-write-forwarding
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-secondary-db-cluster ^
--enable-global-write-forwarding
```
### API RDS
Per abilitare l'inoltro di scrittura utilizzando l'API Amazon RDS, impostare il parametro `EnableGlobalWriteForwarding` su `true`. Questo parametro funziona quando si crea un nuovo cluster secondario utilizzando l'DBClusteroperazione [Create](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Funziona anche quando si modifica un cluster secondario esistente utilizzando l'DBClusteroperazione [Modifica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Richiede che il database globale utilizzi una versione Aurora che supporti l'inoltro di scrittura. È possibile disattivare l'inoltro di scrittura impostando il parametro `EnableGlobalWriteForwarding` su `false`.
## Verifica se un cluster secondario ha abilitato l'inoltro di scrittura in Aurora PostgreSQL
Per determinare se è possibile utilizzare l'inoltro di scrittura da un cluster secondario, è possibile verificare se il cluster dispone dell'attributo `"GlobalWriteForwardingStatus": "enabled"`.
Nella Console di gestione AWS scheda **Configurazione** viene visualizzata la pagina dei dettagli del cluster. `Read replica write forwarding` Per visualizzare lo stato dell'impostazione globale di inoltro della scrittura per tutti i cluster, esegui il comando seguente. AWS CLI
Un cluster secondario mostra il valore `"enabled"` o `"disabled"` per indicare se l'inoltro di scrittura è attivato o disattivato. Il valore `null` indica che l'inoltro di scrittura non è disponibile per il cluster. Il cluster non fa parte di un database globale oppure è il cluster primario anziché un cluster secondario. Il valore può anche essere `"enabling"` o `"disabling"` se l'inoltro di scrittura è in procinto di essere attivato o disattivato.
**Example**
```
aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
{
"GlobalWriteForwardingStatus": "enabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
},
{
"GlobalWriteForwardingStatus": "disabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
},
{
"GlobalWriteForwardingStatus": null,
"DBClusterIdentifier": "non-global-cluster"
}
]
```
Per trovare tutti i cluster secondari per i quali è abilitato l'inoltro di scrittura globale, eseguire il comando seguente. Questo comando restituisce anche l'endpoint di lettura del cluster. È possibile utilizzare l'endpoint di lettura del cluster secondario quando si utilizza l'inoltro di scrittura dal cluster secondario al primario nel database globale Aurora.
**Example**
```
aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
{
"GlobalWriteForwardingStatus": "enabled",
"ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
}
]
```
## Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura in Aurora PostgreSQL
Alcune istruzioni non sono consentite o possono produrre risultati non aggiornati quando vengono utilizzate in un database globale con inoltro di scrittura. Inoltre, le funzioni e le procedure definite dall’utente non sono supportate. Pertanto, l'impostazione `EnableGlobalWriteForwarding` è disattivata in modo predefinito per i cluster secondari. Prima di attivarlo, verificare che il codice dell'applicazione non sia interessato da nessuna di queste restrizioni.
È possibile utilizzare i seguenti tipi di istruzioni SQL con l'inoltro di scrittura:
+ Istruzioni DML (Data Manipulation Language), ad esempio `INSERT`, `DELETE` e `UPDATE`
+ Istruzioni `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }`
+ Istruzioni `PREPARE` e `EXECUTE`.
+ Istruzioni `EXPLAIN` con le istruzioni in questo elenco
I seguenti tipi di istruzioni SQL non sono supportati con l'inoltro di scrittura:
+ Istruzioni DDL (Data Definition Language)
+ `ANALYZE`
+ `CLUSTER`
+ `COPY`
+ Cursori: i cursori non sono supportati, quindi assicurati di chiuderli prima di utilizzare l'inoltro di scrittura.
+ `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL`
+ `LOCK`
+ Istruzioni `SAVEPOINT`
+ `SELECT INTO`
+ `SET CONSTRAINTS`
+ `TRUNCATE`
+ `VACUUM`
## Isolamento e coerenza per l'inoltro di scrittura in Aurora PostgreSQL
Nelle sessioni che utilizzano l'inoltro di scrittura, è possibile utilizzare solo i livelli di isolamento `REPEATABLE READ` e `READ COMMITTED`. Tuttavia, il livello di isolamento `SERIALIZABLE` non è supportato.
È possibile controllare il grado di coerenza di lettura in un cluster secondario. Il livello di coerenza di lettura determina la quantità di attesa di un cluster secondario prima di ogni operazione di lettura per garantire che alcune o tutte le modifiche vengano replicate dal cluster primario. È possibile regolare il livello di coerenza di lettura per garantire che tutte le operazioni di scrittura inoltrate dalla sessione siano visibili nel cluster secondario prima di qualsiasi query successiva. È inoltre possibile utilizzare questa impostazione per garantire che le query sul cluster secondario visualizzino sempre gli aggiornamenti più recenti dal cluster primario. Ciò si verifica anche per quelli inviati da altre sessioni o altri cluster. Per specificare questo tipo di comportamento per l’applicazione, scegli il valore appropriato per il parametro `apg_write_forward.consistency_mode`. Il parametro `apg_write_forward.consistency_mode` ha effetto solo sui cluster secondari in cui è abilitato l'inoltro di scrittura.
**Nota**
Per il parametro `apg_write_forward.consistency_mode`, è possibile specificare i valori `SESSION`, `EVENTUAL`, `GLOBAL` o `OFF`. Per impostazione predefinita, il valore è impostato su `SESSION`. L'impostazione del valore su `OFF` disabilita l'inoltro di scrittura nella sessione.
Aumentando il livello di coerenza, l'applicazione impiega più tempo ad aspettare che le modifiche vengano propagate tra le regioni. AWS È possibile scegliere il bilanciamento tra tempi di risposta rapidi e garantire che le modifiche apportate in altre posizioni siano completamente disponibili prima dell'esecuzione delle query.
Ogni impostazione della modalità di coerenza disponibile, produce un effetto come descritto di seguito:
+ `SESSION`— Tutte le query in una AWS regione secondaria che utilizza l'inoltro di scrittura visualizzano i risultati di tutte le modifiche apportate in quella sessione. Le modifiche sono visibili indipendentemente dal fatto che la transazione sia stata impegnata. Se necessario, la query attende che i risultati delle operazioni di scrittura inoltrate vengano replicati nell'area corrente. Non attende i risultati aggiornati delle operazioni di scrittura eseguite in altre regioni o in altre sessioni all'interno dell'area corrente.
+ `EVENTUAL`— Le query in un' AWS area secondaria che utilizza l'inoltro di scrittura potrebbero visualizzare dati leggermente obsoleti a causa del ritardo di replica. I risultati delle operazioni di scrittura nella stessa sessione non sono visibili fino a quando l'operazione di scrittura non viene eseguita nella regione primaria e replicata nella regione corrente. La query non attende la disponibilità dei risultati aggiornati. Pertanto, potrebbe recuperare i dati meno recenti o i dati aggiornati, a seconda della tempistica delle istruzioni e della quantità di ritardo di replica.
+ `GLOBAL`— In una sessione in un' AWS area secondaria vengono visualizzate le modifiche apportate da quella sessione. Visualizza anche tutte le modifiche impegnate sia dalla AWS regione primaria che da altre AWS regioni secondarie. Ogni query potrebbe attendere un periodo che varia a seconda della quantità di ritardo della sessione. La query procede quando il cluster secondario contiene tutti up-to-date i dati salvati dal cluster primario, a partire dal momento in cui è iniziata la query.
+ `OFF`: l'inoltro di scrittura durante la sessione è disabilitato.
Per ulteriori informazioni su tutti i parametri coinvolti nell'inoltro di scrittura, consulta [Parametri di configurazione per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg).
## Modalità di accesso alle transazioni con inoltro scrittura
Se la modalità di accesso alle transazioni è impostata su sola lettura, l'inoltro di scrittura non viene utilizzato. È possibile impostare la modalità di accesso in lettura e scrittura quando si è connessi a un cluster di database e a una sessione in cui l’inoltro di scrittura è abilitato.
Per ulteriori informazioni sulle modalità di accesso alle transazioni, consultare [SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html).
## Esecuzione di istruzioni a più parti con inoltro scrittura in Aurora PostgreSQL
Un'istruzione DML può essere costituita da più parti, ad esempio un'istruzione `INSERT ... SELECT` o `DELETE ... WHERE`. In questo caso, l'intera istruzione viene inoltrata al cluster primario ed eseguita lì.
## Parametri di configurazione per l'inoltro di scrittura in Aurora PostgreSQL
I gruppi di parametri del cluster Aurora contengono delle impostazioni per la funzionalità di inoltro di scrittura. Poiché si tratta di parametri cluster, tutte le istanze database in ogni cluster hanno gli stessi valori per queste variabili. I dettagli su questi parametri sono riepilogati nella tabella seguente, con note di utilizzo dopo la tabella.
| Nome | Ambito | Tipo | Valore predefinito | Valori validi |
| --- | --- | --- | --- | --- |
| apg\$1write\$1forward.connect\$1timeout | Sessione | secondi | 30 | 0–2147483647 |
| apg\$1write\$1forward.consistency\$1mode | Sessione | enum | Sessione | SESSION, EVENTUAL, GLOBAL, OFF |
| apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Sessione | millisecondi | 86400000 | 0–2147483647 |
| apg\$1write\$1forward.idle\$1session\$1timeout | Sessione | millisecondi | 300000 | 0–2147483647 |
| apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | Globale | int | 25 | 1-100 |
Il parametro `apg_write_forward.max_forwarding_connections_percent` rappresenta il limite superiore degli slot di connessione al database che possono essere utilizzati per gestire le query inoltrate dalle istanze di lettura. Viene espresso come percentuale dell'impostazione `max_connections` per l'istanza database di scrittura nel cluster primario. Ad esempio, se `max_connections` è `800` e `apg_write_forward.max_forwarding_connections_percent` è `10`, allora l'istanza di scrittura consente un massimo di 80 sessioni inoltrate simultanee. Queste connessioni provengono dallo stesso pool di connessioni gestito dall'impostazione `max_connections`. Questa impostazione si applica solo al cluster primario, quando almeno un cluster ha abilitato l'inoltro di scrittura.
Utilizza le seguenti impostazioni sul cluster secondario:
+ `apg_write_forward.consistency_mode`: un parametro a livello di sessione che controlla il grado di coerenza di lettura sul cluster secondario. I valori validi sono `SESSION`, `EVENTUAL`, `GLOBAL` o `OFF`. Per impostazione predefinita, il valore è impostato su `SESSION`. L'impostazione del valore su `OFF` disabilita l'inoltro di scrittura nella sessione. Per ulteriori informazioni sui livelli di coerenza, consulta [Isolamento e coerenza per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-isolation-apg). Questo parametro è rilevante solo nelle istanze di lettura di cluster secondari che hanno l'inoltro di scrittura abilitato e che si trovano in un Aurora Global Database.
+ `apg_write_forward.connect_timeout`: il numero massimo di secondi che il cluster secondario attende per stabilire una connessione al cluster primario prima di rinunciare. Il valore `0` indica un tempo di attesa infinito.
+ `apg_write_forward.idle_in_transaction_session_timeout`: il numero di millisecondi che il cluster primario attende l'attività su una connessione inoltrata da un cluster secondario con una transazione aperta prima di chiuderla. Se la sessione continua ad avere una transazione inattiva oltre questo periodo, Aurora la chiude. Il valore `0` disabilita il timeout.
+ `apg_write_forward.idle_session_timeout`: il numero di millisecondi che il cluster primario attende l'attività su una connessione inoltrata da un cluster secondario prima di chiuderla. Se la sessione rimane inattiva oltre questo periodo, Aurora la chiude. Il valore `0` disabilita il timeout.
## CloudWatch Parametri Amazon per l'inoltro della scrittura in Aurora PostgreSQL
I seguenti CloudWatch parametri Amazon si applicano al cluster primario quando utilizzi l'inoltro di scrittura su uno o più cluster secondari. Questi parametri sono tutti misurati sull'istanza database writer nel cluster primario.
| CloudWatch Parametro | Unità e descrizione |
| --- | --- |
| `AuroraForwardingWriterDMLThroughput` | Conteggio (al secondo) Numero di istruzioni DML inoltrate elaborate ogni secondo da questa istanza database writer. |
| `AuroraForwardingWriterOpenSessions` | Conteggio Numero di sessioni aperte su questa istanza DB di scrittura che elabora le query inoltrate. |
| `AuroraForwardingWriterTotalSessions` | Conteggio Numero totale di sessioni inoltrate sull'istanza database di scrittura. |
Le seguenti CloudWatch metriche si applicano a ciascun cluster secondario. Questi parametri vengono misurati su ogni istanza database del lettore in un cluster secondario con l'inoltro di scrittura abilitato.
| CloudWatch Parametro | Unità e descrizione |
| --- | --- |
| `AuroraForwardingReplicaCommitThroughput` | Conteggio (al secondo) Numero di commit in sessioni inoltrate da questa replica ogni secondo. |
| `AuroraForwardingReplicaDMLLatency` | Millisecondi Tempo di risposta medio in millisecondi di inoltro sulla replica. DMLs |
| `AuroraForwardingReplicaDMLThroughput` | Conteggio (al secondo) Numero di istruzioni DML inoltrate sulla replica elaborate ogni secondo. |
| `AuroraForwardingReplicaErrorSessionsLimit` | Conteggio Numero di sessioni rifiutate dal cluster primario quando viene raggiunto il limite massimo di connessioni o di connessioni create per l'inoltro di scrittura. |
| `AuroraForwardingReplicaOpenSessions` | Conteggio Il numero di sessioni che utilizzano l'inoltro di scrittura su un'istanza di replica. |
| `AuroraForwardingReplicaReadWaitLatency` | Millisecondi Tempo medio di attesa in millisecondi della replica per garantire la coerenza con l'LSN del cluster primario. Il grado di attesa dell'istanza database in lettura dipende dall'impostazione apg\$1write\$1forward.consistency\$1mode. Per ulteriori informazioni su questa impostazione, consulta [Parametri di configurazione per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg). |
## Eventi di attesa per l'inoltro di scrittura in Aurora PostgreSQL
Amazon Aurora genera i seguenti eventi di attesa quando si utilizza l'inoltro di scrittura con Aurora PostgreSQL.
**Topics**
+ [IPC: AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect)
+ [IPC: AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint)
+ [IPC: AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute)
+ [IPC: AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint)
+ [IPC: AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort)
+ [IPC: AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit)
+ [IPC: AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart)
### IPC: AuroraWriteForwardConnect
L'evento `IPC:AuroraWriteForwardConnect` si verifica quando un processo di backend sul cluster di database secondario è in attesa dell'apertura della connessione del cluster di database primario al nodo di scrittura.
**Probabili cause di aumento delle attese**
Questo evento diventa più frequente all'aumentare del numero dei tentativi di connessione dal nodo di lettura di una regione secondaria al nodo di scrittura del cluster di database primario.
**Azioni**
Riduci il numero di connessioni simultanee da un nodo secondario al nodo di scrittura della regione primaria.
### IPC: AuroraWriteForwardConsistencyPoint
L'evento `IPC:AuroraWriteForwardConsistencyPoint` descrive il tempo di attesa di una query generata da un nodo sul cluster di database secondario affinché i risultati delle operazioni di scrittura inoltrate vengano replicati nella regione attuale. Questo evento viene generato solo se il parametro `apg_write_forward.consistency_mode` a livello di sessione è impostato su uno dei seguenti:
+ `SESSION`: le query su un nodo secondario attendono i risultati di tutte le modifiche apportate in quella sessione.
+ `GLOBAL`: le query su un nodo secondario attendono i risultati delle modifiche apportate da quella sessione, oltre a tutte le modifiche richieste dalla regione primaria e dalle altre regioni secondarie del cluster globale.
Per ulteriori informazioni sull'impostazione del parametro `apg_write_forward.consistency_mode`, consulta [Parametri di configurazione per l'inoltro di scrittura in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg).
**Probabili cause di aumento delle attese**
Alcune cause comuni dei tempi di attesa più lunghi sono:
+ Aumento del ritardo di replica, misurato dalla metrica Amazon CloudWatch `ReplicaLag`. Per ulteriori informazioni su questa metrica, consulta [Monitoraggio della replica Aurora PostgreSQL.](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring).
+ Aumento del carico sul nodo di scrittura della regione primaria o sul nodo secondario.
**Azioni**
Modifica la modalità di coerenza in base ai requisiti dell'applicazione.
### IPC: AuroraWriteForwardExecute
L'evento `IPC:AuroraWriteForwardExecute` si verifica quando un processo di backend sul cluster di database secondario è in attesa del completamento di una query inoltrata e di ottenere risultati dal nodo di scrittura del cluster di database primario.
**Probabili cause di aumento delle attese**
Alcune cause comuni dell'aumento dei tempi di attesa sono:
+ Recupero di un numero elevato di righe dal nodo di scrittura primario della regione.
+ L'aumento della latenza di rete tra il nodo secondario e il nodo di scrittura della regione primaria ritarda la ricezione dei dati del nodo di scrittura da parte del nodo secondario.
+ L'aumento del carico sul nodo secondario può ritardare la trasmissione della richiesta di query dal nodo secondario al nodo di scrittura della regione primaria.
+ Un carico maggiore sul nodo di scrittura della regione primaria può ritardare la trasmissione dei dati dal nodo di scrittura al nodo secondario.
**Azioni**
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
+ Ottimizza le query per recuperare solo i dati necessari.
+ Ottimizza le operazioni DML (Data Manipulation Language) per modificare solo i dati necessari.
+ Se il nodo secondario o il nodo di scrittura della regione primaria è limitato dalla CPU o dalla larghezza di banda di rete, valuta la possibilità di modificarlo in un tipo di istanza con maggiore capacità di CPU o maggiore larghezza di banda di rete.
### IPC: AuroraWriteForwardGetGlobalConsistencyPoint
L'evento `IPC:AuroraWriteForwardGetGlobalConsistencyPoint` si verifica quando un processo di backend sul cluster di database secondario che utilizza la modalità di coerenza GLOBAL è in attesa di ottenere il punto di coerenza globale dal nodo di scrittura prima di eseguire una query.
**Probabili cause di aumento delle attese**
Alcune cause comuni dell'aumento dei tempi di attesa sono:
+ L'aumento della latenza di rete tra il nodo secondario e il nodo di scrittura della regione primaria ritarda la ricezione dei dati del nodo di scrittura da parte del nodo secondario.
+ L'aumento del carico sul nodo secondario può ritardare la trasmissione della richiesta di query dal nodo secondario al nodo di scrittura della regione primaria.
+ Un carico maggiore sul nodo di scrittura della regione primaria può ritardare la trasmissione dei dati dal nodo di scrittura al nodo secondario.
**Azioni**
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
+ Modifica la modalità di coerenza in base ai requisiti dell'applicazione.
+ Se il nodo secondario o il nodo di scrittura della regione primaria è limitato dalla CPU o dalla larghezza di banda di rete, valuta la possibilità di modificarlo in un tipo di istanza con maggiore capacità di CPU o maggiore larghezza di banda di rete.
### IPC: AuroraWriteForwardXactAbort
L'evento `IPC:AuroraWriteForwardXactAbort` si verifica quando un processo di backend sul cluster di database secondario è in attesa del risultato di una query di pulizia remota. Le query di pulizia vengono emesse per riportare il processo allo stato ottimale dopo l'interruzione di una transazione di scrittura inoltrata. Amazon Aurora le esegue perché è stato rilevato un errore o perché un utente ha chiamato un comando `ABORT` esplicito o ha annullato una query in esecuzione.
**Probabili cause di aumento delle attese**
Alcune cause comuni dell'aumento dei tempi di attesa sono:
+ L'aumento della latenza di rete tra il nodo secondario e il nodo di scrittura della regione primaria ritarda la ricezione dei dati del nodo di scrittura da parte del nodo secondario.
+ L'aumento del carico sul nodo secondario può ritardare la trasmissione della richiesta di query di pulizia dal nodo secondario al nodo di scrittura della regione primaria.
+ Un carico maggiore sul nodo di scrittura della regione primaria può ritardare la trasmissione dei dati dal nodo di scrittura al nodo secondario.
**Azioni**
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
+ Indaga la causa della transazione interrotta.
+ Se il nodo secondario o il nodo di scrittura della regione primaria è limitato dalla CPU o dalla larghezza di banda di rete, valuta la possibilità di modificarlo in un tipo di istanza con maggiore capacità di CPU o maggiore larghezza di banda di rete.
### IPC: AuroraWriteForwardXactCommit
L'evento `IPC:AuroraWriteForwardXactCommit` si verifica quando un processo di backend sul cluster di database secondario è in attesa del risultato di un comando di transazione di commit inoltrato.
**Probabili cause di aumento delle attese**
Alcune cause comuni dell'aumento dei tempi di attesa sono:
+ L'aumento della latenza di rete tra il nodo secondario e il nodo di scrittura della regione primaria ritarda la ricezione dei dati del nodo di scrittura da parte del nodo secondario.
+ L'aumento del carico sul nodo secondario può ritardare la trasmissione della richiesta di query dal nodo secondario al nodo di scrittura della regione primaria.
+ Un carico maggiore sul nodo di scrittura della regione primaria può ritardare la trasmissione dei dati dal nodo di scrittura al nodo secondario.
**Azioni**
Se il nodo secondario o il nodo di scrittura della regione primaria è limitato dalla CPU o dalla larghezza di banda di rete, valuta la possibilità di modificarlo in un tipo di istanza con maggiore capacità di CPU o maggiore larghezza di banda di rete.
### IPC: AuroraWriteForwardXactStart
L'evento `IPC:AuroraWriteForwardXactStart` si verifica quando un processo di backend sul cluster di database secondario è in attesa del risultato di un comando di avvio della transazione inoltrato.
**Probabili cause di aumento delle attese**
Alcune cause comuni dell'aumento dei tempi di attesa sono:
+ L'aumento della latenza di rete tra il nodo secondario e il nodo di scrittura della regione primaria ritarda la ricezione dei dati del nodo di scrittura da parte del nodo secondario.
+ L'aumento del carico sul nodo secondario può ritardare la trasmissione della richiesta di query dal nodo secondario al nodo di scrittura della regione primaria.
+ Un carico maggiore sul nodo di scrittura della regione primaria può ritardare la trasmissione dei dati dal nodo di scrittura al nodo secondario.
**Azioni**
Se il nodo secondario o il nodo di scrittura della regione primaria è limitato dalla CPU o dalla larghezza di banda di rete, valuta la possibilità di modificarlo in un tipo di istanza con maggiore capacità di CPU o maggiore larghezza di banda di rete.
# Utilizzo dello switchover o failover in un Database globale Amazon Aurora
La funzionalità Database globale Aurora offre una maggiore protezione a livello di continuità aziendale e disaster recovery (BCDR) rispetto alla [disponibilità elevata](Concepts.AuroraHighAvailability.md) standard fornita da un cluster di database Aurora in una singola Regione AWS. Database globale Aurora consente di pianificare un ripristino più rapido in caso di rari eventi non pianificati o di interruzioni complete dei livelli di servizio a livello regionale.
È possibile consultare le seguenti linee guida e procedure per pianificare, testare e implementare la strategia BCDR utilizzando la funzionalità Database globale Aurora.
**Topics**
+ [Pianificazione della continuità aziendale e del disaster recovery](#aurora-global-database-bcdr-planning)
+ [Esecuzione di switchover per database globali Amazon Aurora](#aurora-global-database-disaster-recovery.managed-failover)
+ [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](#aurora-global-database-failover)
+ [Gestione degli RPO per database globali basati su Aurora PostgreSQL–](#aurora-global-database-manage-recovery)
+ [Resilienza tra Regioni per i cluster secondari del database globale](aurora-global-database-secondary-availability.md)
## Pianificazione della continuità aziendale e del disaster recovery
Per pianificare la strategia di continuità aziendale e disaster recovery, è utile comprendere la seguente terminologia di settore e il modo in cui tali termini si applicano alle funzionalità del Database globale Aurora.
Il ripristino di emergenza è in genere determinato dai due obiettivi aziendali seguenti:
+ **Obiettivo del tempo di ripristino (RTO)**: il tempo necessario a un sistema per tornare a uno stato funzionante dopo un guasto o un'interruzione del servizio. In altre parole, l'RTO misura i tempi di inattività. Per Database globale Aurora, l’RTO può essere nell’ordine di minuti.
+ **Obiettivo del punto di ripristino (RPO)**: la quantità di dati che può venire persa (misurata nel tempo) dopo un guasto o un'interruzione del servizio. Questa perdita di dati è in genere dovuta al ritardo della replica asincrona. Per un database globale Aurora, l'RPO viene in genere misurato in secondi. Con un database globale basato su Aurora PostgreSQL–, puoi utilizzare il parametro `rds.global_db_rpo` per impostare e tenere traccia del limite superiore su RPO, ma ciò potrebbe influire sull'elaborazione delle transazioni sul nodo writer del cluster primario. Per ulteriori informazioni, consulta [Gestione degli RPO per database globali basati su Aurora PostgreSQL–](#aurora-global-database-manage-recovery).
L’esecuzione di uno switchover o failover con Database globale Aurora implica la promozione di un cluster di database secondario a cluster di database primario. Il termine "interruzione a livello regionale" viene spesso utilizzato per descrivere una serie di scenari di errore. Lo scenario peggiore potrebbe essere un'interruzione generalizzata causata da un evento catastrofico che interessa un'area geografica particolarmente estesa. Tuttavia, la maggior parte delle interruzioni è molto più localizzata e riguarda solo un piccolo sottoinsieme di servizi cloud o sistemi dei clienti. Valuta l'ambito dell'interruzione nel suo insieme per assicurarti che il failover tra regioni rappresenti la soluzione più appropriata e scegli il metodo di failover più adatto alla situazione. L'utilizzo del failover o dello switchover dipende dallo scenario di interruzione specifico:
+ **Failover**: utilizza questo approccio per il ripristino dopo un'interruzione non pianificata. Con questo approccio, puoi eseguire un failover tra regioni su uno dei cluster database secondari del database globale Aurora. Il valore RPO, espresso in secondi, per questo approccio è in genere diverso da zero. La quantità di dati persi dipende dal ritardo di replica del database globale Aurora tra Regioni AWS al momento del guasto. Per ulteriori informazioni, consulta [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](#aurora-global-database-failover).
+ **Switchover**: questa operazione era precedentemente denominata “failover pianificato gestito”. Usa questo approccio per scenari controllati, ad esempio la manutenzione operativa e altre procedure operative pianificate, in cui tutti i cluster Aurora e gli altri servizi con cui interagiscono sono in stato integro. Poiché questa funzionalità sincronizza i cluster di database secondari con il primario prima di apportare altre modifiche, l’RPO è 0 (nessuna perdita di dati). Per ulteriori informazioni, consulta [Esecuzione di switchover per database globali Amazon Aurora](#aurora-global-database-disaster-recovery.managed-failover).
**Nota**
Se desideri eseguire lo switchover o il failover su un cluster di database Aurora secondario headless, devi prima aggiungervi un’istanza database. Per ulteriori informazioni sui cluster database headless, consulta [Creazione di un cluster database Aurora headless in una regione secondaria](aurora-global-database-attach.console.headless.md).
## Esecuzione di switchover per database globali Amazon Aurora
**Nota**
Gli switchover erano precedentemente denominati **failover pianificati gestiti**.
Utilizzando gli switchover, è possibile modificare regolarmente la Regione del cluster primario. Questo approccio è destinato agli scenari controllati, ad esempio durante la manutenzione operativa e altre procedure operative pianificate.
Esistono tre casi d'uso comuni per l'utilizzo degli switchover.
+ Per i requisiti relativi alla "rotazione regionale" imposti a settori specifici. Ad esempio, le normative sui servizi finanziari potrebbero imporre che i sistemi di livello 0 passino a un'altra regione per diversi mesi per garantire l'esecuzione regolare delle procedure di ripristino di emergenza.
+ Per applicazioni con approccio "follow-the-sun" in più regioni. Ad esempio, un'azienda potrebbe voler fornire scritture con latenza inferiore in diverse regioni in base all'orario di lavoro nei vari fusi orari.
+ Come metodo senza perdita di dati per eseguire il failback alla regione principale originale dopo un failover.
**Nota**
Gli switchover sono progettati per essere utilizzati su un Database globale Aurora in cui tutti i cluster Aurora e gli altri servizi con cui interagiscono sono in stato integro. Per eseguire il ripristino da un'interruzione non pianificata, puoi eseguire la procedura appropriata descritta in [Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata](#aurora-global-database-failover).
È possibile eseguire switchover gestiti tra Regioni con il Database globale Aurora solo se i cluster di database primario e secondario hanno le stesse versioni principale e secondaria del motore. A seconda del motore e delle versioni del motore, può essere necessario che i livelli di patch siano identici oppure possono essere diversi. Per un elenco dei motori e delle versioni dei motori che consentono queste operazioni tra cluster primari e secondari con diversi livelli di patch, consulta [Compatibilità del livello di patch per switchover e failover gestiti tra regioni](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). Prima di iniziare lo switchover, controlla le versioni del motore nel cluster globale per assicurarti che supportino lo switchover gestito tra regioni e, se necessario, aggiornale.
Durante uno switchover, Aurora imposta il cluster nella Regione secondaria scelta come cluster primario. Il meccanismo di switchover mantiene la topologia di replica esistente del database globale: ha ancora lo stesso numero di cluster Aurora nelle stesse Regioni. Prima di avviare il processo di switchover, Aurora attende che tutti i cluster della Regione secondaria di destinazione siano completamente sincronizzati con il cluster della Regione primaria. In seguito, il cluster di database nella Regione primaria diventa di sola lettura. Il cluster secondario scelto promuove uno dei suoi nodi di sola lettura allo stato di scrittura completo, consentendo così al cluster secondario di assumere il ruolo di cluster primario. Poiché tutti i cluster secondari di destinazione sono stati sincronizzati con quello primario all’inizio del processo, il nuovo primario continua le operazioni per il Database globale Aurora senza perdere alcun dato. Il database non è disponibile per un breve periodo, mentre i cluster primario e secondario selezionati assumono i loro nuovi ruoli.
**Nota**
Per gestire gli slot di replica per Aurora PostgreSQL dopo aver eseguito uno switchover, consulta [Gestione degli slot logici per Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots).
Per ottimizzare la disponibilità delle applicazioni, è consigliabile eseguire le seguenti operazioni prima di utilizzare questa funzionalità:
+ Esegui questa operazione durante le ore non di punta o in un altro momento quando le scritture nel cluster DB primario sono minime.
+ Controllare i tempi di ritardo per tutti i cluster di database Aurora secondari nel database globale Aurora. Per tutti i database globali basati su Aurora PostgreSQL e per i database globali basati su Aurora MySQL a partire dalle versioni del motore 3.04.0 e successive o 2.12.0 e successive, usa Amazon CloudWatch per visualizzare la metrica `AuroraGlobalDBRPOLag` per tutti i cluster database secondari. Per le versioni minori precedenti dei database globali basati su Aurora MySQL, puoi invece visualizzare la metrica `AuroraGlobalDBReplicationLag`. Questa metrica indica il ritardo (in millisecondi) della replica tra un cluster secondario e il cluster database primario. Il suo valore è direttamente proporzionale al tempo necessario ad Aurora per completare lo switchover. Di conseguenza, maggiore è il valore del ritardo, maggiore sarà il tempo necessario per lo switchover. Quando esamini queste metriche, procedi dal cluster primario corrente.
Per ulteriori informazioni sulle metriche di CloudWatch per Aurora, consulta [Parametri a livello di cluster per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters).
+ Il cluster di database secondario promosso durante uno switchover potrebbe avere impostazioni di configurazione diverse rispetto al cluster di database primario precedente. È consigliabile mantenere i seguenti tipi di impostazioni di configurazione coerenti tra tutti i cluster nei cluster di Database globale Aurora. Questo consente di ridurre al minimo i problemi con le prestazioni, le incompatibilità dei carichi di lavoro e gli altri comportamenti anomali che seguono uno switchover.
+ **Configura il gruppo di parametri del cluster di database Aurora per il nuovo cluster primario, se necessario**: quando si promuove un cluster di database secondario perché assuma il ruolo di primario, il gruppo di parametri del secondario potrebbe essere configurato in modo diverso rispetto al cluster primario. In tal caso, modifica il gruppo di parametri del cluster di database secondario promosso in modo che sia conforme alle impostazioni del cluster primario. Per scoprire come, consulta [Modifica dei parametri per un database globale Aurora](aurora-global-database-modifying.parameters.md).
+ **Configura gli strumenti e le opzioni di monitoraggio, ad esempio Amazon CloudWatch Events e allarmi** – Configura il cluster di database promosso con la stessa capacità di registrazione, gli allarmi e così via in base alle esigenze del database globale. Come per i gruppi di parametri, la configurazione di queste funzionalità non viene ereditata dal ruolo primario durante il processo di switchover. Alcune metriche CloudWatch, come il ritardo di replica, sono disponibili solo per le regioni secondarie. Pertanto, uno switchover modifica il modo in cui visualizzare tali metriche e impostare i relativi allarmi e potrebbe richiedere modifiche da apportare a qualsiasi dashboard predefinito. Per ulteriori informazioni sui cluster di database Aurora e sul monitoraggio, consulta [Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Configura le integrazioni con altri servizi AWS**: se il database globale Aurora si integra con i servizi AWS, ad esempio Gestione dei segreti AWS, AWS Identity and Access Management, Amazon S3 e AWS Lambda, assicurati di configurare le integrazioni con questi servizi in base alle esigenze. Per ulteriori informazioni sull'integrazione dei database globali Aurora con IAM, Amazon S3 e Lambda, consulta [Utilizzo dei database globali di Amazon Aurora con altri servizi AWS](aurora-global-database-interop.md). Per ulteriori informazioni su Secrets Manager, consulta [Come automatizzare la replica dei segreti in Gestione dei segreti AWS tra Regioni AWS](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/).
Se utilizzi l’endpoint di scrittura del Database globale Aurora, non occorre cambiare le impostazioni di connessione nell’applicazione. Verifica che le modifiche al DNS si siano propagate e che sia possibile connettersi ed eseguire operazioni di scrittura sul nuovo cluster primario. Potrai quindi riprendere la piena operatività dell’applicazione.
Supponiamo che le connessioni alle applicazioni utilizzino l’endpoint cluster del cluster primario precedente, anziché l’endpoint di scrittura globale. In tal caso, assicurati di modificare le impostazioni di connessione dell’applicazione in modo da utilizzare l’endpoint cluster del nuovo cluster primario. Se hai accettato i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo `-ro` dalla stringa endpoint del cluster promosso nell'applicazione. Ad esempio, l'endpoint del cluster secondario `my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` diventa `my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` quando tale cluster viene promosso a primario.
Se utilizzi Server proxy per RDS, assicurati di reindirizzare le operazioni di scrittura dell’applicazione all’endpoint di lettura/scrittura appropriato del proxy associato al nuovo cluster primario. Questo endpoint del proxy può essere l'endpoint predefinito o un endpoint di lettura/scrittura personalizzato. Per ulteriori informazioni, consulta [Come funzionano gli endpoint Server proxy per RDS con i database globali](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
Puoi eseguire lo switchover del Database globale Aurora utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.
### Console
**Esecuzione dello switchover nel database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database** e individua il Database globale Aurora in cui intendi eseguire lo switchover.
1. Scegli **Switchover o failover database globale** nel menu **Operazioni**.
![\[Elenco Database con il menu Operazioni aperto che mostra l’opzione Switchover o failover del database globale.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-1.png)
1. Scegli **Switchover**.
![\[Finestra di dialogo Switchover o failover database globale con l'opzione Failover (consenti perdita di dati) selezionata.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-2.png)
1. In **Nuovo cluster primario**, scegli un cluster attivo in una delle Regioni AWS secondarie da promuovere a nuovo cluster primario.
1. Scegli **Conferma**.
Al termine dello switchover, potrai visualizzare i cluster database Aurora e il relativo stato corrente nell'elenco **Database**, come illustrato nella figura seguente.
![\[Visualizzazione dell'elenco Database con il database globale selezionato. Il cluster secondario selezionato ora risulta avere il ruolo di cluster principale e il vecchio cluster primario ha il ruolo di cluster secondario.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-3.png)
### AWS CLI
**Esecuzione dello switchover nel database globale Aurora**
Utilizza il comando CLI `[switchover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-global-cluster.html)` per eseguire lo switchover per il Database globale Aurora. Questo comando consente di passare i valori per i seguenti parametri.
+ `--region`: specifica la Regione AWS in cui è in esecuzione il cluster di database primario del database globale Aurora.
+ `--global-cluster-identifier` – Specifica il nome del database globale Aurora.
+ `--target-db-cluster-identifier` – Specifica l'Amazon Resource Name (ARN) del cluster di database Aurora che si desidera promuovere come principale per il database globale Aurora.
Per Linux, macOS o Unix:
```
aws rds --region region_of_primary \
switchover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote
```
Per Windows:
```
aws rds --region region_of_primary ^
switchover-global-cluster --global-cluster-identifier global_database_id ^
--target-db-cluster-identifier arn_of_secondary_to_promote
```
### API RDS
Per eseguire lo switchover per il Database globale Aurora, esegui l’operazione API [SwitchoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverGlobalCluster.html).
## Ripristino di un database globale Amazon Aurora da un'interruzione non pianificata
In rare occasioni, per il Database globale Aurora potrebbe verificarsi un’interruzione inaspettata nella Regione AWS primaria. In questo caso, il cluster database Aurora primario e il relativo nodo di scrittura non sono disponibili e la replica tra il cluster database primario e secondari viene interrotta. Per ridurre al minimo i tempi di inattività (RTO) e la perdita di dati (RPO), puoi eseguire un failover tra regioni.
Database globale Aurora offre due metodi di failover da utilizzare in una situazione di disaster recovery:
+ Failover gestito: questo metodo è consigliato in situazioni che prevedono il ripristino di emergenza. Quando si utilizza questo metodo, Aurora aggiunge automaticamente la vecchia regione primaria al database globale come regione secondaria quando diventa nuovamente disponibile. Pertanto, viene mantenuta la topologia originale del cluster globale. Per informazioni su come utilizzare questo metodo, consulta [Esecuzione di failover gestiti per database globali Aurora](#aurora-global-database-failover.managed-unplanned).
+ Failover manuale: questo metodo alternativo può essere utilizzato quando il failover gestito non è un'opzione, ad esempio quando le regioni primarie e secondarie utilizzano versioni del motore non compatibili. Per informazioni su come utilizzare questo metodo, consulta [Esecuzione di failover manuali per i Database globali Aurora](#aurora-global-database-failover.manual-unplanned).
**Importante**
Entrambi i metodi di failover possono comportare la perdita dei dati delle transazioni di scrittura che non sono stati replicati sul dispositivo secondario scelto prima che si verificasse l'evento di failover. Tuttavia, il processo di ripristino che promuove un'istanza database sul cluster database secondario scelto come istanza database di scrittura principale garantisce che i dati si trovino in uno stato transazionale coerente. I failover sono inoltre soggetti a problemi di tipo *split-brain*.
### Esecuzione di failover gestiti per database globali Aurora
Questo approccio è destinato alla continuità aziendale in caso di una reale emergenza a livello regionale o di un'interruzione completa del livello di servizio.
Durante un failover gestito, il cluster secondario nella Regione secondaria scelta diventa il nuovo cluster primario. Il cluster secondario scelto promuove uno dei suoi nodi di sola lettura allo stato di istanza di scrittura completa. Questo passaggio consente al cluster di assumere il ruolo di cluster primario. Il database non sarà disponibile per un breve periodo di tempo mentre il cluster sta assumendo il suo nuovo ruolo. Non appena la precedente Regione primaria è di nuovo integra e disponibile, Aurora la aggiunge automaticamente al cluster globale come Regione secondaria. Pertanto, viene mantenuta la topologia di replica esistente del Database globale Aurora.
**Nota**
Per gestire gli slot di replica per Aurora PostgreSQL dopo aver eseguito un failover, consulta [Gestione degli slot logici per Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots).
**Nota**
È possibile eseguire failover gestiti tra Regioni con il Database globale Aurora solo se i cluster di database primario e secondario hanno le stesse versioni principale e secondaria del motore. A seconda del motore e delle versioni del motore, può essere necessario che i livelli di patch siano identici oppure possono essere diversi. Per un elenco dei motori e delle versioni dei motori che consentono queste operazioni tra cluster primari e secondari con diversi livelli di patch, consulta [Compatibilità del livello di patch per switchover e failover gestiti tra regioni](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). Prima di iniziare il failover, controlla le versioni del motore nel cluster globale per assicurarti che supportino lo switchover gestito tra Regioni e, se necessario, aggiornale. Se le versioni dei motori richiedono livelli di patch identici ma utilizzano livelli di patch diversi, puoi eseguire il failover manualmente tramite la procedura indicata in [Esecuzione di failover manuali per i Database globali Aurora](#aurora-global-database-failover.manual-unplanned).
Il failover gestito non attende la sincronizzazione dei dati tra la Regione secondaria scelta e la Regione primaria corrente. Poiché il Database globale Aurora replica i dati in modo asincrono, è possibile che non tutte le transazioni vengano replicate nella Regione AWS secondaria scelta prima della promozione per accettare funzionalità complete di lettura/scrittura.
Per garantire che i dati siano in uno stato coerente, Aurora crea un nuovo volume di archiviazione per la precedente Regione primaria dopo il ripristino. Prima di creare il nuovo volume di archiviazione nella Regione AWS, Aurora tenta di acquisire uno snapshot del volume di archiviazione precedente nel punto in cui si è verificato l’errore. Questo consente di ripristinare lo snapshot e recuperare i dati mancanti. Se questa operazione ha esito positivo, Aurora inserisce questo snapshot denominato `rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp` nella sezione Snapshot della Console di gestione AWS. È inoltre possibile utilizzare il comando AWS CLI `describe-db-cluster-snapshots` o l’operazione API `DescribeDBClusterSnapshots` per visualizzare i dettagli dello snapshot.
Quando si avvia un failover gestito, Aurora tenta anche di arrestare il traffico di scrittura nel livello di archiviazione Aurora ad alta disponibilità. Questo meccanismo è chiamato “write fencing”. Se il processo ha esito positivo, Aurora emette un evento RDS per indicare che le scritture sono state interrotte. Nell’improbabile eventualità che si verifichino più errori AZ in una Regione, è possibile che il processo di write fencing non abbia esito positivo tempestivamente. In tal caso, Aurora emette un evento RDS che informa l’utente che si è verificato il timeout del processo di interruzione delle scritture. Se il cluster primario precedente è raggiungibile sulla rete, Aurora vi registra questi eventi. In caso contrario, Aurora registra gli eventi sul nuovo cluster primario. Per ulteriori informazioni su questi eventi, consulta [Eventi di cluster di database](USER_Events.Messages.md#USER_Events.Messages.cluster). Poiché il fencing di scritture è un tentativo migliore possibile, è possibile che le scritture vengano momentaneamente accettate nella Regione primaria precedente, causando problemi di tipo split-brain.
È consigliabile completare le seguenti attività prima di eseguire un failover con Database globale Aurora. In questo modo si riduce al minimo l’incidenza di problemi di tipo split-brain o il ripristino di dati non replicati dallo snapshot del cluster primario precedente.
+ Per impedire l’invio di scrittura al cluster primario del Database globale Aurora, metti offline le applicazioni.
+ Assicurati che tutte le applicazioni che si connettono al cluster di database primario utilizzino l’endpoint di scrittura globale. Questo endpoint ha un valore che rimane invariato anche quando una nuova Regione diventa il cluster primario a causa dello switchover o del failover. Aurora implementa misure di protezione aggiuntive per ridurre al minimo la possibilità di perdita di dati per le operazioni di scrittura inviate tramite l’endpoint globale. Per ulteriori informazioni sugli endpoint di scrittura globali, consulta [Connessione a Database globale Amazon Aurora](aurora-global-database-connecting.md).
+ Se utilizzi l’endpoint di scrittura globale e i livelli applicativi o di rete memorizzano nella cache i valori DNS, imposta il time-to-live (TTL) della cache DNS su un valore più basso, ad esempio 5 secondi. In questo modo, l’applicazione registra rapidamente le modifiche DNS con l’endpoint di scrittura globale. Sebbene Aurora tenti di bloccare le scritture nella vecchia Regione primaria, non è garantito che l’azione riesca. La riduzione della durata della cache DNS riduce ulteriormente la probabilità di problemi di tipo split-brain. In alternativa, puoi verificare la presenza dell’evento RDS che ti indica quando Aurora ha osservato le modifiche DNS per l’endpoint di scrittura globale. In questo modo, puoi verificare che l’applicazione abbia registrato anche la modifica DNS prima di riavviare il traffico di scrittura dell’applicazione.
+ Controllare i tempi di ritardo per tutti i cluster di database Aurora secondari nel Database globale Aurora. La scelta della regione secondaria con il minor ritardo di replica può ridurre al minimo la perdita di dati relativamente all'attuale regione primaria in stato di errore.
Per tutte le versioni dei database globali basati su Aurora PostgreSQL e per i database globali basati su Aurora MySQL con versioni del motore 3.04.0 e successive o 2.12.0 e successive, usa Amazon CloudWatch per visualizzare la metrica `AuroraGlobalDBRPOLag` per tutti i cluster di database secondari. Per le versioni minori precedenti dei database globali basati su Aurora MySQL, puoi invece visualizzare la metrica `AuroraGlobalDBReplicationLag`. Questa metrica indica il ritardo (in millisecondi) della replica tra un cluster secondario e il cluster database primario.
Per ulteriori informazioni sulle metriche di CloudWatch per Aurora, consulta [Parametri a livello di cluster per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters).
Durante un failover gestito, il cluster database secondario scelto viene promosso al nuovo ruolo primario. Tuttavia, non eredita le varie opzioni di configurazione del cluster di database primario. Una mancata corrispondenza nella configurazione può causare problemi di prestazioni, incompatibilità dei carichi di lavoro e altri comportamenti anomali. Per evitare tali problemi, è consigliabile risolvere le differenze tra i cluster di database globali Aurora per quanto segue:
+ **Configura il gruppo di parametri del cluster di database Aurora per il nuovo primario, se necessario** – Puoi configurare i gruppi di parametri del cluster di database Aurora in modo indipendente per ogni cluster Aurora del Database globale Aurora. Pertanto, quando si promuove un cluster database secondario perché assuma il ruolo primario, il gruppo di parametri dal cluster secondario potrebbe essere configurato in modo diverso rispetto al cluster primario. In tal caso, modifica il gruppo di parametri del cluster di database secondario promosso in modo che sia conforme alle impostazioni del cluster primario. Per scoprire come, consulta [Modifica dei parametri per un database globale Aurora](aurora-global-database-modifying.parameters.md).
+ **Configura gli strumenti e le opzioni di monitoraggio, ad esempio Amazon CloudWatch Events e allarmi** – Configura il cluster di database promosso con la stessa capacità di registrazione, gli allarmi e così via in base alle esigenze del database globale. Come per i gruppi di parametri, la configurazione di queste funzionalità non viene ereditata dal primario durante il processo di failover. Alcune metriche CloudWatch, come il ritardo di replica, sono disponibili solo per le regioni secondarie. Pertanto, un failover modifica il modo in cui visualizzare tali metriche e impostare i relativi allarmi e potrebbe richiedere modifiche da apportare a qualsiasi dashboard predefinito. Per ulteriori informazioni sul monitoraggio dei cluster di database Aurora, consulta [Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Configura le integrazioni con altri servizi AWS**: se il Database globale Aurora si integra con altri servizi AWS, ad esempio Gestione dei segreti AWS, AWS Identity and Access Management, Amazon S3 e AWS Lambda, è necessario che questi siano configurati per l’accesso da qualsiasi Regione secondaria. Per ulteriori informazioni sull'integrazione dei database globali Aurora con IAM, Amazon S3 e Lambda, consulta [Utilizzo dei database globali di Amazon Aurora con altri servizi AWS](aurora-global-database-interop.md). Per ulteriori informazioni su Secrets Manager, consulta [Come automatizzare la replica dei segreti in Gestione dei segreti AWS tra Regioni AWS](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/).
In genere, il cluster secondario scelto assume il ruolo primario entro pochi minuti. Non appena l’istanza database di scrittura della nuova Regione primaria è disponibile, puoi connettervi le tue applicazioni e riprendere i tuoi carichi di lavoro. Dopo aver promosso il nuovo cluster primario, Aurora ricostruisce automaticamente tutti i cluster secondari regionali aggiuntivi.
Poiché i database globali Aurora utilizzano la replica asincrona, il ritardo di replica in ciascuna regione secondaria può variare. Aurora ricostruisce queste regioni secondarie in modo che abbiano esattamente gli stessi dati point-in-time del nuovo cluster regionale primario. La durata dell'attività di ricostruzione completa può richiedere da alcuni minuti a diverse ore, a seconda delle dimensioni del volume di archiviazione e della distanza tra regioni. Quando i cluster regionali secondari terminano la ricostruzione in base alla nuova regione primaria, diventano disponibili per l'accesso in lettura.
Non appena la nuova istanza di scrittura primaria viene promossa e risulta disponibile, il cluster della nuova regione primaria può gestire le operazioni di lettura e scrittura per il database globale Aurora.
Se utilizzi l’endpoint globale, non occorre cambiare le impostazioni di connessione nell’applicazione. Verifica che le modifiche al DNS si siano propagate e che sia possibile connettersi ed eseguire operazioni di scrittura sul nuovo cluster primario. Potrai quindi riprendere la piena operatività dell’applicazione.
Se non utilizzi l’endpoint globale, assicurati di modificare l’endpoint dell’applicazione in modo che utilizzi l’endpoint del cluster per il cluster di database primario appena promosso. Se hai accettato i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo `-ro` dalla stringa endpoint del cluster promosso nell'applicazione.
Ad esempio, l'endpoint del cluster secondario `my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` diventa `my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` quando tale cluster viene promosso a primario.
Se utilizzi il proxy RDS, assicurati di reindirizzare le operazioni di scrittura dell'applicazione all'endpoint di lettura/scrittura appropriato del proxy associato al nuovo cluster primario. Questo endpoint del proxy può essere l'endpoint predefinito o un endpoint di lettura/scrittura personalizzato. Per ulteriori informazioni, consulta [Come funzionano gli endpoint Server proxy per RDS con i database globali](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
Per ripristinare la topologia originale del cluster database globale, Aurora monitora la disponibilità della vecchia regione primaria. Non appena tale regione è di nuovo integra e disponibile, Aurora la aggiunge automaticamente al cluster globale come regione secondaria. Prima di creare il nuovo volume di archiviazione nella vecchia regione primaria, Aurora tenta di acquisire uno snapshot del vecchio volume di archiviazione nel punto in cui si è verificato l'errore. Ciò consente di usare lo snapshot per recuperare i dati mancanti. Se questa operazione ha esito positivo, Aurora crea uno snapshot denominato `rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp`. Questo snapshot è disponibile nella sezione **Snapshot** di Console di gestione AWS. Questo snapshot è disponibile anche nelle informazioni restituite dall'operazione API [DescribeDBClusterSnapshots](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterSnapshots.html).
**Nota**
Lo snapshot del vecchio volume di archiviazione è uno snapshot del sistema soggetto al periodo di conservazione del backup configurato sul vecchio cluster primario. Per conservare questo snapshot oltre il periodo di conservazione, puoi copiarlo e salvarlo come snapshot manuale. Per ulteriori informazioni sulla copia degli snapshot, inclusi i prezzi, consulta [Copia di uno snapshot del cluster di database](aurora-copy-snapshot.md).
Dopo il ripristino della topologia originale, puoi eseguire il failback del database globale nella regione primaria originale eseguendo un'operazione di switchover nel momento più opportuno per l'azienda e il carico di lavoro. A tale scopo, segui la procedura in [Esecuzione di switchover per database globali Amazon Aurora](#aurora-global-database-disaster-recovery.managed-failover).
Puoi eseguire un failover con il Database globale Aurora utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.
#### Console
**Esecuzione del failover gestito nel database globale Aurora**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database** e individua il Database globale Aurora di cui desideri eseguire il failover.
1. Scegli **Switchover o failover database globale** nel menu **Operazioni**.
![\[Elenco Database con il menu Operazioni aperto che mostra l’opzione Switchover o failover del database globale.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-1.png)
1. Scegli **Failover (consenti perdita di dati)**.
![\[Finestra di dialogo Switchover o failover database globale con l'opzione Failover (consenti perdita di dati) selezionata.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-2.png)
1. In **Nuovo cluster primario**, scegli un cluster attivo in una delle Regioni AWS secondarie da promuovere a nuovo cluster primario.
1. Immetti **confirm**, quindi scegli **Conferma**.
Al termine del failover, potrai visualizzare i cluster di database Aurora e il relativo stato corrente nell’elenco **Database**, come illustrato nella figura seguente.
![\[Visualizzazione dell'elenco Database con il database globale selezionato. Il cluster secondario selezionato ora risulta avere il ruolo di cluster principale e il vecchio cluster primario ha il ruolo di cluster secondario.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-5.png)
#### AWS CLI
**Esecuzione del failover gestito nel database globale Aurora**
Utilizza il comando della CLI `[failover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-global-cluster.html)` per eseguire il failover con il Database globale Aurora. Questo comando consente di passare i valori per i seguenti parametri.
+ `--region`: specifica la Regione AWS in cui è in esecuzione il cluster database secondario che vuoi promuovere a nuovo cluster primario per il database globale Aurora.
+ `--global-cluster-identifier` – Specifica il nome del database globale Aurora.
+ `--target-db-cluster-identifier`: specifica il nome della risorsa Amazon (ARN) del cluster database Aurora che desideri promuovere a nuovo cluster primario per il database globale Aurora.
+ `--allow-data-loss`: imposta in modo esplicito un'operazione di failover anziché un'operazione di switchover. Un'operazione di failover può causare una perdita di dati se i componenti della replica asincrona non hanno completato l'invio di tutti i dati replicati alla regione secondaria.
Per Linux, macOS o Unix:
```
aws rds --region region_of_selected_secondary \
failover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote \
--allow-data-loss
```
Per Windows:
```
aws rds --region region_of_selected_secondary ^
failover-global-cluster --global-cluster-identifier global_database_id ^
--target-db-cluster-identifier arn_of_secondary_to_promote ^
--allow-data-loss
```
#### API RDS
Per eseguire un failover con il Database globale Aurora, esegui l’operazione API [FailoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverGlobalCluster.html).
### Esecuzione di failover manuali per i Database globali Aurora
In alcuni scenari, puoi non essere in grado di utilizzare il processo di failover gestito. Un esempio è quando i cluster database primario e secondari non utilizzano versioni del motore compatibili. In questo caso, puoi usare questa procedura manuale per eseguire un failover nella Regione secondaria di destinazione.
**Suggerimento**
Si consiglia di comprendere questo processo prima di utilizzarlo. Prepara un piano per procedere rapidamente al primo segno di un problema a livello regionale. Puoi essere pronto a identificare la regione secondaria con il minor ritardo di replica utilizzando Amazon CloudWatch con regolarità per monitorare i tempi di ritardo dei cluster secondario. Assicurati di testare il piano per verificare che le procedure siano complete e accurate e che il personale sia addestrato per eseguire un failover in caso di ripristino di emergenza prima che ciò avvenga realmente.
**Per eseguire un failover manuale in un cluster secondario dopo un’interruzione non pianificata nella Regione primaria**
1. Interrompi l'emissione di istruzioni DML e altre operazioni di scrittura sul cluster di database Aurora primario nella Regione AWS con l'interruzione.
1. Identifica un cluster di database Aurora da una Regione AWS secondaria da utilizzare come nuovo cluster di database primario. Se nel database globale Aurora sono presenti due o più Regioni AWS secondarie, scegli il cluster secondario con il ritardo di replica minore.
1. Scollega il cluster di database secondario scelto dal database globale Aurora.
La rimozione di un cluster di database secondario da un database globale Aurora interrompe immediatamente la replica dal primario al secondario e la promuove a cluster di database Aurora con provisioning autonomo con funzionalità di lettura/scrittura complete. Tutti gli altri cluster di database Aurora secondari associati al cluster primario nella regione con interruzione sono ancora disponibili e possono accettare chiamate dall'applicazione. Inoltre consumano risorse. Poiché si sta ricreando il database globale Aurora, rimuovi gli altri cluster di database secondari prima di creare il nuovo database globale Aurora nei passaggi seguenti. In questo modo, si evitano incongruenze di dati tra i cluster di database nel database globale Aurora (problemi di *split-brain*).
Per i passaggi dettagliati per lo scollegamento, consulta [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md).
1. Riconfigura l'applicazione per inviare tutte le operazioni di scrittura a questo cluster di database Aurora ora autonomo utilizzando il nuovo endpoint. Se sono stati accettati i nomi forniti al momento della creazione del database globale Aurora, puoi modificare l'endpoint rimuovendo `-ro` dalla stringa endpoint del cluster nell'applicazione.
Ad esempio, l'endpoint del cluster secondario `my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` diventa `my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com` quando tale cluster viene scollegato dal database globale Aurora.
Questo cluster di database Aurora diventa il cluster primario di un nuovo database globale Aurora quando si inizia ad aggiungere regioni nel passaggio successivo.
Se utilizzi il proxy RDS, assicurati di reindirizzare le operazioni di scrittura dell'applicazione all'endpoint di lettura/scrittura appropriato del proxy associato al nuovo cluster primario. Questo endpoint del proxy può essere l'endpoint predefinito o un endpoint di lettura/scrittura personalizzato. Per ulteriori informazioni, consulta [Come funzionano gli endpoint Server proxy per RDS con i database globali](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
1. Aggiungi una Regione AWS al cluster di database. Quando esegui questa operazione, inizia il processo di replica da primario a secondario. Per i passaggi dettagliati per aggiungere una regione, consulta [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
1. Aggiungi altre Regioni AWS in base alle esigenze per ricreare la topologia necessaria per supportare l'applicazione.
Assicurati che le scritture delle applicazioni vengano inviate al cluster di database Aurora corretto prima, durante e dopo aver apportato queste modifiche. In questo modo, si evitano incongruenze di dati tra i cluster di database nel database globale Aurora (problemi di *split-brain*).
Se hai eseguito la riconfigurazione in risposta a un'interruzione di una Regione AWS, puoi nuovamente rendere la Regione AWS come principale dopo la risoluzione dell'interruzione. A tale scopo, aggiungi la precedente Regione AWS al nuovo database globale e quindi usa il processo di switchover per cambiare il ruolo. Il database globale Aurora deve utilizzare una versione di Aurora PostgreSQL o Aurora MySQL che supporti gli switchover. Per ulteriori informazioni, consulta [Esecuzione di switchover per database globali Amazon Aurora](#aurora-global-database-disaster-recovery.managed-failover).
## Gestione degli RPO per database globali basati su Aurora PostgreSQL–
Con un database globale basato su Aurora PostgreSQL, puoi gestire l'obiettivo del punto di ripristino (RPO) per il database globale Aurora utilizzando il parametro `rds.global_db_rpo`. RPO rappresenta la quantità massima di dati che possono essere persi in caso di interruzione.
Quando si imposta un RPO per il database globale basato su Aurora PostgreSQL–, Aurora controlla il *tempo di ritardo RPO* di tutti i cluster secondari per assicurarsi che almeno un cluster secondario rimanga all'interno della finestra RPO di destinazione. Il tempo di ritardo RPO è un altro parametro basato sul tempo.
L'RPO viene utilizzato quando il database riprende le operazioni in una nuova Regione AWS dopo un failover. Aurora valuta i tempi di ritardo RPO e RPO per eseguire il commit (o il blocco) delle transazioni sulla regione principale come segue:
+ Conferma la transazione se almeno un cluster di database secondario ha un tempo di ritardo RPO inferiore rispetto all'RPO.
+ Blocca la transazione se tutti i cluster di database secondari hanno tempi di ritardo RPO superiori all'RPO. Registra inoltre l'evento nel file di log di PostgreSQL ed emette eventi di “attesa” che mostrano le sessioni bloccate.
In altre parole, se tutti i cluster secondari sono dietro l'RPO di destinazione, Aurora sospende le transazioni sul cluster primario fino al raggiungimento di almeno uno dei cluster secondari. Le transazioni in pausa vengono nuovamente eseguite non appena il tempo di ritardo di almeno un cluster di database secondario diventa inferiore all'RPO. Il risultato è che nessuna transazione può eseguire il commit fino al raggiungimento dell'RPO.
Il parametro `rds.global_db_rpo` è dinamico. Se decidi che non vuoi che tutte le transazioni di scrittura si blocchino fino a quando il ritardo non diminuisce a un livello sufficiente, puoi ripristinarlo rapidamente. In questo caso, Aurora riconosce e implementa la modifica dopo un breve ritardo.
**Importante**
In un database globale con solo due Regioni AWS, è consigliabile mantenere il valore predefinito del parametro `rds.global_db_rpo` nel gruppo di parametri della Regione secondaria. Diversamente, l’esecuzione di un failover a causa della perdita della Regione AWS primaria potrebbe causare la sospensione delle transazioni da parte di Aurora. Attendi invece che Aurora completi la ricostruzione del cluster nella vecchia Regione AWS in cui si è verificato l’errore prima di modificare questo parametro per imporre un RPO massimo.
Se imposti questo parametro come descritto di seguito, puoi monitorare anche le metriche generate. Puoi eseguire questa operazione utilizzando `psql` o un altro strumento per interrogare il cluster di database primario del database globale Aurora e ottenere informazioni dettagliate sulle operazioni del database globale basato su Aurora PostgreSQL–. Per scoprire come, consulta [Monitoraggio dei database globali Aurora basati su PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
**Topics**
+ [Impostazione dell'obiettivo del punto di ripristino](#aurora-global-database-set-rpo)
+ [Visualizzazione dell'obiettivo del punto di ripristino](#aurora-global-database-view-rpo)
+ [Disattivazione dell'obiettivo del punto di ripristino](#aurora-global-database-disable-rpo)
### Impostazione dell'obiettivo del punto di ripristino
Il parametro `rds.global_db_rpo` controlla l'impostazione RPO per un database PostgreSQL. Questo parametro è supportato da Aurora PostgreSQL. I valori validi per `rds.global_db_rpo` vanno da 20 secondi a 2.147.483.647 secondi (68 anni). Scegli un valore realistico per soddisfare le tue esigenze aziendali e il caso d'uso. Ad esempio, puoi consentire fino a 10 minuti per l'RPO, nel qual caso si imposta il valore su 600.
Puoi impostare questo valore per il database globale basato su Aurora PostgreSQL utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.
#### Console
**Per impostare l'RPO**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Sceglie il cluster primario del database Aurora globale e apri la scheda **Configurazione** per trovare il relativo gruppo di parametri del cluster di database. Ad esempio, il gruppo di parametri predefinito per un cluster di database primario che esegue Aurora PostgreSQL 11.7 è `default.aurora-postgresql11`.
I gruppi di parametri non possono essere modificati direttamente. Puoi invece procedere come descritto di seguito:
+ Crea un gruppo di parametri cluster di database personalizzato utilizzando il gruppo di parametri predefinito appropriato come punto di partenza. Ad esempio, crea un gruppo di parametri cluster di database personalizzato basato su `default.aurora-postgresql11`.
+ Nel gruppo di parametri database personalizzato, imposta il valore del parametro **rds.global\$1db\$1rpo** in modo da soddisfare il caso d'uso. I valori validi vanno da 20 secondi fino al valore intero massimo di 2.147.483.647 (68 anni).
+ Applica il gruppo di parametri del cluster di database modificato al cluster di database Aurora.
Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
#### AWS CLI
Per impostare il parametro `rds.global_db_rpo`, utilizza il comando della CLI [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html). Nel comando specifica il nome del gruppo di parametri del cluster primario e i valori per il parametro RPO.
Nell'esempio seguente l'RPO viene impostato su 600 secondi per il gruppo di parametri cluster di database primario denominato `my_custom_global_parameter_group`.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my_custom_global_parameter_group \
--parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"
```
Per Windows:
```
aws rds modify-db-cluster-parameter-group ^
--db-cluster-parameter-group-name my_custom_global_parameter_group ^
--parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"
```
#### API RDS
Per modificare il parametro `rds.global_db_rpo`, utilizzare l'operazione API Amazon RDS [ ModifyDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html).
### Visualizzazione dell'obiettivo del punto di ripristino
L'obiettivo del punto di ripristino (RPO) di un database globale viene memorizzato nel parametro `rds.global_db_rpo`. Puoi connettersi all'endpoint per il cluster secondario che si desidera visualizzare e utilizzare per `psql` eseguire una query sull'istanza per questo valore.
```
db-name=>show rds.global_db_rpo;
```
Se questo parametro non è impostato, la query restituirà quanto segue:
```
rds.global_db_rpo
-------------------
-1
(1 row)
```
Questa risposta successiva proviene da un cluster di database secondario con impostazione RPO di 1 minuto.
```
rds.global_db_rpo
-------------------
60
(1 row)
```
Puoi inoltre utilizzare la CLI per ottenere valori per scoprire se `rds.global_db_rpo` è attivo su uno qualsiasi dei cluster di database Aurora utilizzando l'interfaccia a riga di comando per ottenere i valori di tutti i parametri `user` per il cluster.
Per Linux, macOS o Unix:
```
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-test-apg-global \
--source user
```
Per Windows:
```
aws rds describe-db-cluster-parameters ^
--db-cluster-parameter-group-name lab-test-apg-global *
--source user
```
Il comando restituisce un output simile al seguente per tutti i parametri `user` che non sono parametri del cluster di database `default-engine` o `system`.
```
{
"Parameters": [
{
"ParameterName": "rds.global_db_rpo",
"ParameterValue": "60",
"Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
"Source": "user",
"ApplyType": "dynamic",
"DataType": "integer",
"AllowedValues": "20-2147483647",
"IsModifiable": true,
"ApplyMethod": "immediate",
"SupportedEngineModes": [
"provisioned"
]
}
]
}
```
Per ulteriori informazioni sulla visualizzazione dei parametri del gruppo di parametri del cluster, consulta [Visualizzazione dei valori dei parametri per un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ViewingCluster.md).
### Disattivazione dell'obiettivo del punto di ripristino
Per disabilitare l'RPO, reimpostare il parametro `rds.global_db_rpo`. È possibile reimpostare i parametri utilizzando Console di gestione AWS, AWS CLI o l’API RDS.
#### Console
**Per disabilitare l'RPO**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione scegliere **Parameter groups (Gruppi di parametri)**.
1. Nell'elenco scegliere il gruppo di parametri cluster DB primario.
1. Scegliere **Edit parameters (Modifica parametri)**.
1. Scegliere la casella accanto al parametro **rds.global\$1db\$1rpo**.
1. Scegliere **Reimposta**.
1. Quando la schermata mostra **Reimposta parametri nel gruppo di parametri DB**, scegliere **Reimposta parametri**.
Per ulteriori informazioni su come reimpostare un parametro con la console, vedere [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
#### AWS CLI
Per reimpostare il parametro `rds.global_db_rpo`, utilizzare il comando [reset-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/reset-db-cluster-parameter-group.html).
Per Linux, macOS o Unix:
```
aws rds reset-db-cluster-parameter-group \
--db-cluster-parameter-group-name global_db_cluster_parameter_group \
--parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"
```
Per Windows:
```
aws rds reset-db-cluster-parameter-group ^
--db-cluster-parameter-group-name global_db_cluster_parameter_group ^
--parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"
```
#### API RDS
Per reimpostare il parametro `rds.global_db_rpo`, utilizzare l'operazione Amazon RDS API [ ResetDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ResetDBClusterParameterGroup.html).
# Resilienza tra Regioni per i cluster secondari del database globale
Le versioni 16.6, 15.10, 14.15, 13.18, 12.22 o successive di Aurora PostgreSQL e le versioni 3.09 o successive di Aurora MySQL contengono miglioramenti della disponibilità che consentono alle repliche di lettura regionali secondarie di mantenere la continuità del servizio durante eventi non pianificati come guasti hardware, interruzioni della rete tra Regioni AWS, grandi volumi di trasferimenti di dati tra i cluster e altro.
Sebbene le repliche di lettura rimangano disponibili per le richieste delle applicazioni, il ritardo di replica potrebbe continuare ad aumentare fino alla risoluzione dell’evento non pianificato. È possibile monitorare il ritardo tra i cluster primari e secondari utilizzando la metrica CloudWatch di `AuroraGlobalDBProgressLag`. Per misurare il ritardo end-to-end, incluso qualsiasi ritardo tra il volume del cluster e le istanze database del cluster secondario, aggiungi i valori delle metriche CloudWatch di `AuroraGlobalDBProgressLag` e `AuroraReplicaLag`. Per ulteriori informazioni sulle metriche, consulta [Riferimento per i parametri per Amazon Aurora](metrics-reference.md).
La disponibilità di lettura del database globale per Aurora MySQL e le versioni precedenti di Aurora PostgreSQL potrebbe risentire di tali eventi non pianificati.
Per ulteriori informazioni sulle nuove funzionalità di Aurora PostgreSQL 16.6, 15.10, 14.15, 13.18 e 12.22, consulta [PostgreSQL 16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) nelle *Note di rilascio di Aurora PostgreSQL*.
Per ulteriori informazioni sulle nuove funzionalità di Aurora MySQL versione 3.09 e successive, consulta [Aggiornamenti del motore del database per Amazon Aurora MySQL versione 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) nelle *Note di rilascio di Aurora MySQL*.
# Monitoraggio di un database globale Amazon Aurora
Quando si creano i cluster di database Aurora che costituiscono il database globale Aurora, è possibile scegliere molte opzioni che consentono di monitorare le prestazioni del cluster di database. Queste opzioni includono:
+ Amazon RDS Performance Insights – Supporta lo schema delle prestazioni nel motore di database Aurora sottostante. Per ulteriori informazioni su Performance Insights e database globali Aurora, consulta [Monitoraggio di un database globale Amazon Aurora con Amazon RDS Performance Insights](#aurora-global-database-pi).
+ Monitoraggio avanzato – Genera parametri per l'utilizzo di processi o thread sulla CPU. Per ulteriori informazioni sul monitoraggio avanzato, consulta [Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato](USER_Monitoring.OS.md).
+ Amazon CloudWatch Logs: pubblica tipi di log specifici in Logs. CloudWatch I log degli errori vengono pubblicati per impostazione predefinita, ma è possibile scegliere altri log specifici per il motore di database Aurora.
+ Per i cluster di database Aurora basati su Aurora MySQL è possibile esportare il log di controllo, il log generale e il log delle query lente.
+ Per i cluster database Aurora basati su Aurora PostgreSQL, puoi esportare il log PostgreSQL.
+ Per i database globali basati su Aurora MySQL, è possibile eseguire query su tabelle `information_schema` specifiche per verificare lo stato del database globale Aurora e delle relative istanze. Per scoprire come, consulta [Monitoraggio dei database globali basati su Aurora MySQL](#aurora-global-database-monitoring.mysql).
+ Per i database globali basati su Aurora PostgreSQL, è possibile utilizzare funzioni specifiche per verificare lo stato del database globale Aurora e delle relative istanze. Per scoprire come, consulta [Monitoraggio dei database globali Aurora basati su PostgreSQL](#aurora-global-database-monitoring.postgres).
La seguente schermata mostra alcune delle opzioni disponibili nella scheda Monitoraggio di un cluster di database Aurora primario in un database globale Aurora.
![\[Scheda Monitoraggio: visualizzazione del menu a discesa Monitoraggio CloudWatch, monitoraggio avanzato, elenco dei processi del sistema operativo e opzioni Performance Insights.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-monitoring-options.png)
Per ulteriori informazioni, consulta [Monitoraggio dei parametri in un cluster di database Amazon Aurora](MonitoringAurora.md).
## Monitoraggio di un database globale Amazon Aurora con Amazon RDS Performance Insights
È possibile utilizzare Amazon RDS Performance Insights per i database globali Aurora. È possibile abilitare questa funzionalità singolarmente, per ogni cluster di database Aurora nel database globale Aurora. A tale scopo, scegliere **Enable Performance Insights (Abilita Performance Insights)** nella sezione **Additional configuration (Configurazioni aggiuntive)** della pagina Crea database. In alternativa, una volta operativi, è possibile modificare i cluster di database Aurora per utilizzare questa funzionalità. È possibile abilitare o disattivare Performance Insights per ciascun cluster che fa parte del database globale Aurora.
I report creati da Performance Insights si applicano a ciascun cluster del database globale. Quando aggiungi un nuovo secondario Regione AWS a un database globale Aurora che utilizza già Performance Insights, assicurati di abilitare Performance Insights nel cluster appena aggiunto. Non eredita l'impostazione Performance Insights dal database globale esistente.
È possibile passare da un'istanza DB a un database globale Regioni AWS mentre si visualizza la pagina Performance Insights. Tuttavia, potresti non visualizzare le informazioni sulle prestazioni subito dopo la commutazione Regioni AWS. Sebbene le istanze DB possano avere nomi identici in ognuna Regione AWS, l'URL Performance Insights associato è diverso per ogni istanza DB. Dopo la commutazione Regioni AWS, scegli nuovamente il nome dell'istanza DB nel riquadro di navigazione Performance Insights.
Per le istanze database associate a un database globale, i fattori che influiscono sulle prestazioni potrebbero essere diversi in ciascuna Regione AWS. Ad esempio, le istanze DB di ciascuna istanza Regione AWS potrebbero avere una capacità diversa.
Per ulteriori informazioni sull'utilizzo di Performance Insights, consulta [Monitoraggio del carico DB con Performance Insights su Amazon Aurora](USER_PerfInsights.md).
## Monitoraggio dei database globali Aurora con i flussi di attività di database
Con i flussi di attività del database è possibile monitorare e impostare gli allarmi per l'attività di audit nei cluster database del database globale. Avvia un flusso di attività del database su ciascun cluster database separatamente. Ciascun cluster fornisce i dati di audit al proprio flusso Kinesis all'interno della propria Regione AWS. Per ulteriori informazioni, consulta [Monitoraggio di Amazon Aurora tramite i flussi di attività del database](DBActivityStreams.md).
## Monitoraggio dei database globali basati su Aurora MySQL
Per visualizzare lo stato di un database globale basato su Aurora MySQL, eseguire query delle tabelle [information\$1schema.aurora\$1global\$1db\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.aurora_global_db_status) e [information\$1schema.aurora\$1global\$1db\$1instance\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.aurora_global_db_instance_status).
**Nota**
Le tabelle `information_schema.aurora_global_db_status` e `information_schema.aurora_global_db_instance_status` sono disponibili solo con i database globali Aurora MySQL 3.04.0 e versioni successive.
**Per monitorare un database globale basato su Aurora MySQL**
1. Esegui la connessione all'endpoint del cluster primario del database globale utilizzando un client MySQL. Per ulteriori informazioni su come connettersi, consulta [Connessione a Database globale Amazon Aurora](aurora-global-database-connecting.md).
1. Esegui la query sulla tabella `information_schema.aurora_global_db_status` in un comando mysql per elencare i volumi primari e secondari. Questa query restituisce i tempi di ritardo dei cluster database secondari del database globale, come nell'esempio seguente.
```
mysql> select * from information_schema.aurora_global_db_status;
```
```
AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID
-----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------
us-east-1 | 183537946 | 0 | 0 | 1970-01-01 00:00:00.000000 | 0
us-west-2 | 183537944 | 428 | 0 | 2023-02-18 01:26:41.925000 | 20806982
(2 rows)
```
L'output include una riga per ogni cluster DB del database globale contenente le seguenti colonne:
+ **AWS\$1REGION**— In Regione AWS cui si trova questo cluster DB. Per l'elenco delle tabelle Regioni AWS per motore, vedere[Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ **HIGHEST\$1LSN\$1WRITTEN**: il numero di sequenza di log più alto (LSN) attualmente scritto in questo cluster database.
Un *numero di sequenza di registro (LSN)* è un numero sequenziale univoco che identifica un record nel registro delle transazioni del database. LSNs sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.
+ **DURABILITY\$1LAG\$1IN\$1MILLISECONDS**: la differenza nei valori di timestamp tra il parametro `HIGHEST_LSN_WRITTEN` su un cluster database secondario e il parametro `HIGHEST_LSN_WRITTEN` sul cluster database primario. Questo valore è sempre 0 sul cluster database primario del database globale Aurora.
+ **RPO\$1LAG\$1IN\$1MILLISECONDS**: il ritardo dell'obiettivo del punto di ripristino (RPO). Il ritardo dell'obiettivo del punto di ripristino (RPO) è il tempo necessario per memorizzare il COMMIT delle transazioni utente più recenti dopo la sua memorizzazione nel cluster di database primario del database globale Aurora. Questo valore è sempre 0 sul cluster database primario del database globale Aurora.
In sintesi, questo parametro calcola l'obiettivo del punto di ripristino per ciascun cluster database Aurora MySQL nel database globale Aurora, ovvero quanti dati potrebbero andare perduti in caso di interruzione. Come per il ritardo, l'obiettivo del punto di ripristino (RPO) viene misurato nel tempo.
+ **LAST\$1LAG\$1CALCULATION\$1TIMESTAMP**: il timestamp che specifica l'ultima volta in cui i valori stati calcolati per `DURABILITY_LAG_IN_MILLISECONDS` e `RPO_LAG_IN_MILLISECONDS`. Il valore temporale `1970-01-01 00:00:00+00` indica che questo è il cluster di database primario.
+ **OLDEST\$1READ\$1VIEW\$1TRX\$1ID**: l'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura.
1. Esegui una query sulla tabella `information_schema.aurora_global_db_instance_status` per elencare tutte le istanze database secondarie per il cluster database primario e i cluster database secondari.
```
mysql> select * from information_schema.aurora_global_db_instance_status;
```
```
SERVER_ID | SESSION_ID | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC
---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------
ams-gdb-primary-i2 | MASTER_SESSION_ID | us-east-1 | 183537698 | 0 | 0 | 0 | 0
ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 0
ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 677
ams-gdb-primary-i1 | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1 | 183537697 | 183537698 | 20806930 | 183537691 | 21
(4 rows)
```
L'output include una riga per ogni istanza DB del database globale contenente le colonne seguenti:
+ **SERVER\$1ID**: identificatore del server per l'istanza database.
+ **SESSION\$1ID**: un identificatore univoco per la sessione corrente. Il valore di `MASTER_SESSION_ID` identifica l'istanza database di lettura (primaria).
+ **AWS\$1REGION**— In Regione AWS cui si trova questa istanza DB. Per l'elenco delle tabelle Regioni AWS per motore, vedere[Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ **DURABLE\$1LSN**: l'LSN è stato reso durevole nello storage.
+ **HIGHEST\$1LSN\$1RECEIVED**: l'LSN più alto ricevuto dall'istanza database dall'istanza database di scrittura.
+ **OLDEST\$1READ\$1VIEW\$1TRX\$1ID**: l'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura.
+ **OLDEST\$1READ\$1VIEW\$1LSN**: l'LSN più vecchio utilizzato dall'istanza database per leggere dallo storage.
+ **VISIBILITY\$1LAG\$1IN\$1MSEC**: per le istanze di lettura nel cluster database primario, il ritardo in millisecondi di questa istanza database rispetto all'istanza database di scrittura. Per istanze di lettura in un cluster database secondario, il ritardo in millisecondi di questa istanza database rispetto al volume secondario.
Per vedere come questi valori cambiano nel tempo, considerare il seguente blocco di transazioni in cui un inserimento di tabella richiede un'ora:
```
mysql> BEGIN;
mysql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
mysql> COMMIT;
```
In alcuni casi, potrebbe esserci una disconnessione di rete tra il cluster DB primario e il cluster DB secondario dopo l'istruzione `BEGIN`. In tal caso, il valore **DURABILITY\$1LAG\$1IN\$1MILLISECONDS** del cluster database secondario inizia ad aumentare. Alla fine dell'istruzione `INSERT`, il valore **DURABILITY\$1LAG\$1IN\$1MILLISECONDS** è di 1 ora. Tuttavia, il valore **RPO\$1LAG\$1IN\$1MILLISECONDS** è 0 perché tutti i dati utente confermati tra il cluster database primario e il cluster database secondario sono ancora gli stessi. Al termine dell'istruzione `COMMIT`, il valore **RPO\$1LAG\$1IN\$1MILLISECONDS** aumenta.
## Monitoraggio dei database globali Aurora basati su PostgreSQL
Per visualizzare lo stato di un database globale Aurora basato su PostgreSQL, occorre utilizzare le funzioni `aurora_global_db_status` e `aurora_global_db_instance_status`.
**Nota**
Solo Aurora PostgreSQL supporta le funzioni `aurora_global_db_status` e `aurora_global_db_instance_status`.
**Per monitorare un database globale basato su Aurora PostgreSQL**
1. Connettersi all'endpoint cluster primario del database globale utilizzando un'utilità PostgreSQL come psql. Per ulteriori informazioni su come connettersi, consulta [Connessione a Database globale Amazon Aurora](aurora-global-database-connecting.md).
1. Utilizzare la funzione `aurora_global_db_status` in un comando psql per elencare i volumi primari e secondari. Mostra i tempi di ritardo dei cluster DB secondari del database globale.
```
postgres=> select * from aurora_global_db_status();
```
```
aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243
(2 rows)
```
L'output include una riga per ogni cluster DB del database globale contenente le seguenti colonne:
+ **aws\$1region** — In Regione AWS cui si trova questo cluster DB. Per l'elenco delle tabelle per motore Regioni AWS , vedi. [Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)
+ **highest\$1lsn\$1written** – Il numero di sequenza di log più alto (LSN) attualmente scritto in questo cluster DB.
Un *numero di sequenza di registro (LSN)* è un numero sequenziale univoco che identifica un record nel registro delle transazioni del database. LSNs sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.
+ **durability\$1lag\$1in\$1msec** – La differenza di timestamp tra il numero di sequenza di log più alto scritto su un cluster DB secondario (`highest_lsn_written`) e il `highest_lsn_written` sul cluster DB primario.
+ **rpo\$1lag\$1in\$1msec** – Il ritardo dell'obiettivo del punto di ripristino (RPO). Questo ritardo è la differenza di tempo tra il commit delle transazioni utente più recenti memorizzate in un cluster DB secondario e il commit delle transazioni utente più recenti memorizzate nel cluster DB primario.
+ **last\$1lag\$1calculation\$1time**: il timestamp in cui sono stati calcolati i valori per `durability_lag_in_msec` e `rpo_lag_in_msec`.
+ **feedback\$1epoch** – L'epoca utilizzata da un cluster di database secondario quando genera informazioni di standby a caldo.
*Hot Standby* – Si verifica quando un cluster DB può connettersi e interrogare mentre il server è in modalità di ripristino o standby. Il feedback hot standby è costituito da informazioni sul cluster DB quando è in standby. Per ulteriori informazioni, consulta [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) nella documentazione di PostgreSQL.
+ **feedback\$1xmin** – L'ID minimo della transazione attiva (meno recente) utilizzato da un cluster di database secondario.
1. Utilizzare la funzione `aurora_global_db_instance_status` per elencare tutte le istanze database secondarie sia per il cluster DB primario che per i cluster DB secondari.
```
postgres=> select * from aurora_global_db_instance_status();
```
```
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
--------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------
apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | |
apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10
apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017
(3 rows)
```
L'output include una riga per ogni istanza DB del database globale contenente le colonne seguenti:
+ **server\$1id** – Identificatore del server per l'istanza DB.
+ **session\$1id** – Un identificatore univoco per la sessione corrente.
+ **aws\$1region** — La cartella in cui si trova Regione AWS questa istanza DB. Per l'elenco delle tabelle per motore Regioni AWS , vedi. [Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)
+ **durable\$1lsn** – LSN è stato reso durevole nello storage.
+ **highest\$1lsn\$1rcvd** – L'LSN più alto che l'istanza database ha ricevuto dall'istanza database di scrittura.
+ **feedback\$1epoch** – L'epoca utilizzata dall'istanza DB quando genera informazioni di hot standby.
*Standby a caldo* è quando un'istanza database può connettersi ed eseguire query mentre il server è in modalità di ripristino o standby. Il feedback hot standby consiste in informazioni sull'istanza DB quando è in hot standby. Per ulteriori informazioni, consulta la documentazione di PostgreSQL su [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html).
+ **feedback\$1xmin** – L'ID della transazione attiva minimo (meno recente) utilizzato dall'istanza DB.
+ **oldest\$1read\$1view\$1lsn** – L’LSN più vecchio utilizzato dall'istanza DB per leggere dallo storage.
+ **visibility\$1lag\$1in\$1msec** – Quanto questa istanza DB è in ritardo rispetto all'istanza DB di scrittura.
Per vedere come questi valori cambiano nel tempo, considerare il seguente blocco di transazioni in cui un inserimento di tabella richiede un'ora:
```
psql> BEGIN;
psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
psql> COMMIT;
```
In alcuni casi, potrebbe esserci una disconnessione di rete tra il cluster DB primario e il cluster DB secondario dopo l'istruzione `BEGIN`. In tal caso, il valore `durability_lag_in_msec` del cluster DB secondario inizia ad aumentare. Alla fine dell'istruzione `INSERT`, il valore `durability_lag_in_msec` è 1 ora. Tuttavia, il valore `rpo_lag_in_msec` è 0 perché tutti i dati utente impegnati tra il cluster DB primario e il cluster DB secondario sono ancora gli stessi. Non appena l'istruzione `COMMIT` viene completata, il valore `rpo_lag_in_msec` aumenta.
# Utilizzo Blue/Green delle distribuzioni per Amazon Aurora Global Database
Amazon RDS Blue/Green Deployments offre la possibilità di testare le modifiche al database in modo sicuro. Per il tuo database globale, le blue/green implementazioni ti consentono di eseguire aggiornamenti e operazioni di manutenzione con tempi di inattività minimi. È possibile creare un ambiente di staging completamente gestito (verde) che rispecchi l'intero ambiente di produzione (blu), incluso il cluster principale e tutte le regioni secondarie associate in più regioni. AWS L'ambiente di staging riflette la configurazione di produzione e consente di testare in modo affidabile le modifiche prima di passare al nuovo ambiente. Durante tutto il processo, le blue/green implementazioni mantengono sincronizzati gli ambienti di staging e di produzione. Quando sei pronto a trasformare l'ambiente di staging nel nuovo ambiente di produzione, esegui un passaggio. blue/green Questa operazione trasferisce le aree primarie e tutte le aree secondarie all'ambiente verde, con tempi di inattività in genere inferiori a un minuto. Il servizio rinomina automaticamente i cluster, le istanze e gli endpoint in base all'ambiente di produzione originale, consentendo alle applicazioni di accedere al nuovo ambiente di produzione senza richiedere modifiche alla configurazione e riducendo al minimo il sovraccarico operativo.
**Topics**
+ [Vantaggi dell'utilizzo delle Blue/Green implementazioni con Aurora Global Database](#aurora-blue-green-benefits)
+ [Come funzionano Blue/Green le implementazioni con Aurora Global Database](#aurora-blue-green-howitworks)
## Vantaggi dell'utilizzo delle Blue/Green implementazioni con Aurora Global Database
+ Esegui aggiornamenti di versioni principali, versioni secondarie e di sistema, tra cui patch di database e aggiornamenti del sistema operativo su Aurora Global Databases, mantenendo al contempo tempi di inattività minimi.
+ Crea un ambiente di staging (verde) pronto per la produzione nelle aree primarie e secondarie del database globale per testare e implementare nuove funzionalità del database.
+ Eseguite il passaggio in modo sicuro utilizzando i guardrail di commutazione integrati con tempi di inattività in genere inferiori a un minuto, a seconda del carico di lavoro.
+ Mantiene le funzionalità di disaster recovery durante il processo di switchover, permettendo il failover di Global Database durante lo Blue/Green switchover. Blue/Green
+ Il traffico verrà indirizzato al nuovo ambiente di produzione senza richiedere alcuna modifica all'applicazione.
## Come funzionano Blue/Green le implementazioni con Aurora Global Database
Per i dettagli su come creare, visualizzare, cambiare ed eliminare una Blue/Green distribuzione, consulta. [Utilizzo di Amazon Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md) È possibile utilizzarlo per aggiornamenti di versioni principali o secondarie, miglioramenti delle prestazioni del database tramite aggiornamenti dei parametri e adozione di nuove funzionalità del database, con tempi di inattività minimi.
Di seguito è riportata una rappresentazione dell'aspetto di una blue/green distribuzione per Aurora Global Database con un'area secondaria prima e dopo lo blue/green switchover.
![\[Un esempio di Blue/Green implementazione per Aurora Global Database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/Aurora Global Database_Blue_Green_example.png)
È possibile creare una blue/green distribuzione dalla regione principale del database globale. Seleziona le configurazioni del motore, ad esempio la versione principale o secondaria del motore, il gruppo di parametri DB e il gruppo di parametri del cluster DB per l'ambiente verde. Amazon RDS copia la topologia dell'ambiente blu per l'ambiente verde. Una rappresentazione visiva Console di gestione AWS è quella mostrata di seguito.
![\[Riepilogo di una Blue/Green distribuzione.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auroraglobaldatabase_bluegreen.png)
**Nota**
Il failover globale è supportato durante uno blue/green switchover, ma lo switchover globale non è supportato durante uno switchover. blue/green
Quando si avvia un failover globale durante uno blue/green switchover RDS, la regione di destinazione torna automaticamente all'ambiente blu o torna all'ambiente verde prima che si verifichi il failover globale.
Per informazioni sulla creazione, la visualizzazione, il cambio e l'eliminazione delle distribuzioni, vedere. blue/green [Utilizzo di Amazon Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md) Segui lo stesso flusso di lavoro per Global Databases, con istruzioni specifiche riportate nei passaggi pertinenti.
# Utilizzo dei database globali di Amazon Aurora con altri servizi AWS
Puoi usare i tuoi database globali Aurora con altri AWS servizi, come Amazon S3 e. AWS Lambda Ciò richiede che tutti i cluster di database Aurora nel database globale abbiano gli stessi privilegi, funzioni esterne e così via nelle rispettive Regioni AWS. Poiché un cluster di database Aurora secondario di sola lettura in un database globale Aurora può essere promosso al ruolo primario, è consigliabile impostare i privilegi di scrittura in anticipo su tutti i cluster di database Aurora per tutti i servizi che si intende utilizzare con il database globale Aurora.
Le seguenti procedure riassumono le azioni da intraprendere per ciascuna di esse. Servizio AWS
**Per richiamare AWS Lambda funzioni da un database globale Aurora**
1. Per tutti i cluster Aurora che costituiscono l'Aurora Global Database, esegui le procedure in [Chiamare una funzione Lambda da un cluster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md).
1. Per ogni cluster nel database globale Aurora, imposta l’Amazon Resource Name (nome della risorsa Amazon (ARN)) del nuovo ruolo IAM (IAM).
1. Per consentire agli utenti di database in un database globale Aurora di invocare funzioni Lambda, associa il ruolo creato in [Creazione di un ruolo IAM per consentire ad Amazon Aurora di accedere ai servizi AWS](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) a ogni cluster nel database globale Aurora.
1. Configura ogni cluster nel database globale Aurora per consentire le connessioni in uscita a Lambda. Per istruzioni, consulta [Abilitazione della comunicazione di rete da Amazon Aurora ad altri servizi AWS](AuroraMySQL.Integrating.Authorizing.Network.md).
**Per caricare i dati da Amazon S3**
1. Per tutti i cluster Aurora che costituiscono l'Aurora Global Database, esegui le procedure in [Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md).
1. Per ogni cluster Aurora nel database globale, imposta il parametro del cluster database `aurora_load_from_s3_role` o `aws_default_s3_role` sull'Amazon Resource Name (ARN) del nuovo ruolo IAM. Se un ruolo IAM non è specificato per `aurora_load_from_s3_role`, Aurora utilizza il ruolo IAM specificato in `aws_default_s3_role`.
1. Per consentire agli utenti di database in un Aurora Global Database di accedere ad S3, associa il ruolo creato in [Creazione di un ruolo IAM per consentire ad Amazon Aurora di accedere ai servizi AWS](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) a ogni cluster Aurora nel database globale.
1. Configura ogni cluster nell'Aurora Global Database per consentire le connessioni in uscita a S3. Per istruzioni, consulta [Abilitazione della comunicazione di rete da Amazon Aurora ad altri servizi AWS](AuroraMySQL.Integrating.Authorizing.Network.md).
**Per salvare i dati interrogati in Amazon S3**
1. Per tutti i cluster Aurora che costituiscono il database globale Aurora, esegui le procedure in [Salvataggio dei dati da un cluster DB Amazon Aurora MySQL nei file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md) o [Esportazione di dati da del cluster di database Aurora PostgreSQLRDS per PostgreSQL a Amazon S3](postgresql-s3-export.md).
1. Per ogni cluster Aurora nel database globale, imposta il parametro del cluster database `aurora_select_into_s3_role` o `aws_default_s3_role` sull'Amazon Resource Name (ARN) del nuovo ruolo IAM. Se un ruolo IAM non è specificato per `aurora_select_into_s3_role`, Aurora utilizza il ruolo IAM specificato in `aws_default_s3_role`.
1. Per consentire agli utenti di database in un Aurora Global Database di accedere ad S3, associa il ruolo creato in [Creazione di un ruolo IAM per consentire ad Amazon Aurora di accedere ai servizi AWS](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) a ogni cluster Aurora nel database globale.
1. Configura ogni cluster nell'Aurora Global Database per consentire le connessioni in uscita a S3. Per istruzioni, consulta [Abilitazione della comunicazione di rete da Amazon Aurora ad altri servizi AWS](AuroraMySQL.Integrating.Authorizing.Network.md).
## Utilizzo di Amazon Application Recovery Controller (ARC) con Aurora Global Database
Quando pianifichi la tua strategia di continuità aziendale e disaster recovery, devi orchestrare il ripristino tra gli stack di applicazioni e le relative dipendenze. [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/region-switch.html) si integra con Aurora Global Database per automatizzare questo processo tramite ARC Region Switch, una soluzione centralizzata per il ripristino automatico di applicazioni in più regioni. Region Switch orchestra le fasi di failover tra AWS account e regioni, fornisce dashboard di ripristino in tempo reale e genera report di conformità aggregando i dati tra risorse e account. Scopri di più sull'[utilizzo di Region Switch per Aurora Global](https://docs.aws.amazon.com/r53recovery/latest/dg/aurora-global-database-block.html) Database.
# 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](#aurora-global-database-upgrade.minor.incompatibility).
## 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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB).
**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–](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
Per informazioni su come aggiornare un database globale Aurora MySQL a una versione principale superiore, consulta [Principali aggiornamenti in loco per database globali](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.GlobalDB).
**Nota**
Con un database globale Aurora basato su Aurora MySQL, puoi eseguire un aggiornamento in loco da Aurora MySQL versione 2 alla versione 3 solo se il parametro `lower_case_table_names` è attivato come predefinito e il database globale viene riavviato.
Per eseguire un aggiornamento della versione principale ad Aurora MySQL versione 3 usando `lower_case_table_names`, utilizza la seguente procedura:
Rimuovi tutte le regioni secondarie dal cluster globale. Segui la procedura riportata in [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md).
Esegui l'aggiornamento della versione del motore della regione principale ad Aurora MySQL versione 3. Segui la procedura riportata in [Come eseguire un aggiornamento in loco](AuroraMySQL.Upgrading.Procedure.md).
Aggiungi le regioni secondarie al cluster globale. Segui la procedura riportata in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
Puoi anche utilizzare il metodo di ripristino snapshot. Per ulteriori informazioni, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md).
## Aggiornamenti a versioni secondarie
È possibile aggiornare il database globale Aurora a una versione più recente del motore secondario in tutte le regioni con un'unica operazione gestita e tempi di inattività minimi, eliminando la necessità di aggiornare manualmente ogni cluster singolarmente e riducendo il sovraccarico operativo per la gestione globale dei cluster.
### Informazioni sugli aggiornamenti delle versioni minori del database globale
Puoi aggiornare la versione secondaria del tuo database globale tramite l'API RDS AWS CLI, oppure. Console di gestione AWS Questa singola operazione orchestra l'aggiornamento nel cluster principale e in tutti i cluster secondari (mirror). Se si verificano problemi durante l'aggiornamento, il servizio torna automaticamente alla versione esistente.
**Nota**
Questa funzionalità gestita è attualmente supportata solo per i motori compatibili con Aurora PostgreSQL.
Quando si avvia un aggiornamento di una versione secondaria del database globale utilizzando il `modify-global-cluster` comando, si specifica la versione del motore di destinazione e il servizio coordina l'aggiornamento in tutti i cluster. Questo aggiornamento viene applicato immediatamente.
Per Linux, macOS o Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine-version target_engine_version
```
Per Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine-version target_engine_version
```
### Considerazioni per gli aggiornamenti di versioni minori
Quando pianificate un aggiornamento di versione minore per il vostro database globale, tenete presente quanto segue:
+ La funzionalità gestita si applica solo agli aggiornamenti di versioni minori. Gli aggiornamenti delle versioni delle patch continuano a utilizzare le azioni di manutenzione degli aggiornamenti di sistema esistenti.
+ La funzionalità gestita è supportata solo per i cluster globali Aurora PostgreSQL.
È possibile aggiornare singolarmente ogni cluster nella topologia globale del cluster. Se scegli questo approccio, aggiorna tutti i cluster secondari prima di aggiornare il cluster primario. Durante l'aggiornamento, assicurati che i cluster DB primari e secondari siano aggiornati alla stessa versione secondaria e allo stesso livello di patch. Per aggiornare il livello di patch, applica tutte le azioni di manutenzione in sospeso sul cluster secondario. 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](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor).
### Aggiornamenti di versione minori per il database globale Aurora MySQL
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](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md).
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.\$1, è necessario 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, potrebbe essere necessario eseguire l’aggiornamento dei cluster di database primario e secondari alla stessa versione, incluso il livello di patch. Questo requisito si applica ad Aurora MySQL e ad alcune versioni di Aurora PostgreSQL. Per un elenco di versioni che consentono lo switchover e il failover tra cluster che eseguono livelli di patch diversi, consulta [Compatibilità del livello di patch per switchover e failover gestiti tra regioni](#aurora-global-database-upgrade.minor.incompatibility).
### Compatibilità del livello di patch per switchover e failover gestiti tra regioni
Se il database globale Aurora sta operando una delle seguenti versioni secondarie del motore, puoi eseguire switchover o failover gestiti tra Regioni anche se i livelli di patch dei cluster di database primario e secondari non corrispondono. Per le versioni secondarie del motore precedenti a quelle presenti in questo elenco, i cluster di database primario e secondari devono eseguire la 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 quando pianifichi gli aggiornamenti per il cluster primario, i cluster secondari o entrambi.
**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.
Se le versioni del motore richiedono identici livelli di patch, puoi eseguire il failover manualmente seguendo i passaggi indicati in [Esecuzione di failover manuali per i Database globali Aurora](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.manual-unplanned).
| Motore del database | Versioni secondarie del motore | Note |
| --- | --- | --- |
| Aurora MySQL | Nessuna versione secondaria | Nessuna delle versioni secondarie di Aurora MySQL consente di eseguire switchover o failover gestiti tra Regioni con livelli differenti di patch tra cluster di database primario e secondari. |
| Aurora PostgreSQL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-upgrade.html) | Con le versioni del motore elencate nella colonna precedente, è possibile eseguire switchover o failover gestiti tra Regioni da un cluster di database primario con un livello di patch a un cluster di database secondario con un livello di patch diverso. Con le versioni secondarie precedenti a queste, è possibile eseguire switchover o failover gestiti tra Regioni solo se i livelli di patch dei cluster di database primari e secondari corrispondono. Quando si aggiorna un cluster nel database globale a una delle seguenti versioni di patch, non sarà possibile eseguire switchover o failover tra Regioni finché tutti i cluster di database globale non eseguiranno una di queste versioni di patch o una più recente. Versioni di patch 16.1.6, 16.2.4, 16.3.2 e 16.4.2 Versioni di patch 15.3.8, 15.4.9, 15.5.6, 15.6.4, 15.7.2 e 15.8.2 Versioni di patch 14.8.8, 14.9.9, 14.10.6, 14.11.4, 14.12.2 e 14.13.2 |