Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo dell'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.