Utilizzo dell'inoltro di scrittura in un database globale Aurora My SQL - Amazon Aurora
Disponibilità per regione e versione dell'inoltro di scrittura in Aurora My SQLAttivazione dell'inoltro di scrittura in Aurora My SQLVerifica se un cluster secondario ha l'inoltro di scrittura abilitato in Aurora My SQLApplicazione e SQL compatibilità con l'inoltro di scrittura in Aurora My SQLIsolamento e coerenza per l'inoltro della scrittura in Aurora My SQLEsecuzione di istruzioni multiparte con inoltro di scrittura in Aurora My SQLTransazioni con inoltro di scrittura in Aurora My SQLParametri di configurazione per l'inoltro della scrittura in Aurora My SQL CloudWatch Metriche di Amazon per l'inoltro della scrittura in Aurora My SQL

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 Aurora My SQL

Disponibilità per regione e versione dell'inoltro di scrittura in Aurora My SQL

L'inoltro della scrittura è supportato con Aurora My SQL 2.08.1 e versioni successive, in ogni regione in cui sono disponibili database globali basati su Aurora My. SQL

Per informazioni sulla disponibilità della versione e della regione di Aurora My SQL global database, vedere. Database globali Aurora con Aurora My SQL

Attivazione dell'inoltro di scrittura in Aurora My SQL

Per impostazione predefinita, l'inoltro di scrittura non è abilitato quando si aggiunge un cluster secondario a un Aurora Global Database.

Per abilitare l'inoltro di scrittura utilizzando AWS Management Console, seleziona la casella di controllo Attiva l'inoltro globale di scrittura in Leggi l'inoltro di scrittura della replica 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 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. 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'--no-enable-global-write-forwardingopzione con questi stessi CLI comandi.

Per abilitare l'inoltro di scrittura tramite Amazon RDSAPI, imposta il EnableGlobalWriteForwarding parametro 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 della scrittura in Aurora My SQL.

La funzionalità RDS Proxy non supporta il SESSION valore della variabile. aurora_replica_read_consistency la cui impostazione può causare un comportamento imprevisto.

CLIGli esempi seguenti mostrano come configurare 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. Sostituisci il nome utente, la password e il nome principale e secondario con le tue scelte AWS Regioni. 

# 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 l'inoltro di scrittura abilitato in Aurora My SQL

Per determinare se è possibile utilizzare l'inoltro di scrittura da un cluster secondario, è possibile verificare se il cluster dispone dell'attributo "GlobalWriteForwardingStatus": "enabled".

Nel AWS Management Console, nella scheda Configurazione della pagina dei dettagli del cluster, viene visualizzato lo stato Enabled for Global Read Replica Write Forwarding.

Per visualizzare lo stato dell'impostazione globale di inoltro della scrittura per tutti i cluster, esegui quanto segue AWS CLI comando.

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.

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.

Esempio 
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"
    }
]

Applicazione e SQL compatibilità con l'inoltro di scrittura in Aurora My SQL

È possibile utilizzare i seguenti tipi di SQL istruzioni con l'inoltro di scrittura:

  • Istruzioni Data Manipulation Language (DML), ad esempioINSERT, 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 SQL istruzioni 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'.
Linguaggio di definizione dei dati () DDL

Connect al cluster primario per eseguire DDL le istruzioni. 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'DMListruzione per modificare una tabella permanente se l'istruzione si riferisce 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]
LOADistruzioni 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;
SAVEPOINTdichiarazioni

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 della scrittura in Aurora My SQL

Nelle sessioni che utilizzano l'inoltro di scrittura, è possibile utilizzare solo il livello di isolamento REPEATABLE READ. Tuttavia, è possibile utilizzare il livello di READ COMMITTED isolamento anche con cluster di sola lettura in ambienti secondari AWS Regioni, quel livello di isolamento non funziona con l'inoltro di scrittura. Per informazioni sui livelli di isolamento REPEATABLE READ e READ COMMITTED, consulta Aurora I miei SQL livelli di isolamento.

È 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 My SQL versione 2 e versione 3 precedenti alla 3.04, usala aurora_replica_read_consistency come variabile di sessione. Per Aurora My SQL versione 3.04 e successive, è possibile utilizzarlo aurora_replica_read_consistency come variabile di sessione o come parametro del cluster DB.

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 ad aspettare che le modifiche vengano propagate tra AWS Regioni. È 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 suEVENTUAL, le interrogazioni sono secondarie AWS L'area che utilizza l'inoltro di scrittura potrebbe 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.

Con la coerenza di lettura impostata su, tutte le query vengono eseguite in un formato SESSION secondario AWS L'area che utilizza l'inoltro di scrittura visualizza 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.

Con la coerenza di lettura impostata suGLOBAL, una sessione in una sessione secondaria AWS La regione visualizza le modifiche apportate da quella sessione. Visualizza anche tutte le modifiche apportate da entrambe le principali AWS Regione e altre aree secondarie AWS Regioni. Ogni query potrebbe attendere un periodo che varia a seconda della quantità di ritardo della sessione. La query continua quando il cluster secondario contiene tutti up-to-date i dati salvati dal cluster primario, a partire dal momento in cui è iniziata la query.

Per ulteriori informazioni su tutti i parametri coinvolti nell'inoltro di scrittura, consulta Parametri di configurazione per l'inoltro della scrittura in Aurora My SQL.

Esempi di utilizzo dell'inoltro di scrittura

Questi esempi utilizzano aurora_replica_read_consistency come una variabile di sessione. Per Aurora My SQL versione 3.04 e successive, è possibile utilizzarlo aurora_replica_read_consistency come variabile di sessione o come parametro del cluster DB.

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 multiparte con inoltro di scrittura in Aurora My SQL

Un'DMListruzione può essere composta da più parti, ad esempio un'istruzione o un'INSERT ... SELECTistruzione. DELETE ... WHERE In questo caso, l'intera istruzione viene inoltrata al cluster primario ed eseguita lì.

Transazioni con inoltro di scrittura in Aurora My SQL

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_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 della scrittura in Aurora My SQL

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_fwd_master_idle_timeout(Aurora La mia SQL versione 2) Globale unsigned integer 60 1–86.400
aurora_fwd_master_max_connections_pct(Aurora La mia SQL versione 2) Globale intero lungo senza segno 10 0–90
aurora_fwd_writer_idle_timeout(Aurora La mia SQL versione 3) Globale unsigned integer 60 1–86.400
aurora_fwd_writer_max_connections_pct(Aurora La mia SQL versione 3) Globale intero lungo senza segno 10 0–90
aurora_replica_read_consistency Sessione 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 è un parametro a livello di sessione che abilita 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 della scrittura in Aurora My SQL. A questo parametro si applicano le seguenti regole:

  • Questo è un parametro a livello di sessione. 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 (EVENTUALSESSION, o GLOBAL) a un altro valore valido (EVENTUALSESSION, o GLOBAL) durante tale transazione.

  • La variabile non può essere SET quando l'inoltro di scrittura non è abilitato nel cluster secondario.

  • L'impostazione della variabile di sessione su un cluster primario non ha alcun effetto. Se si tenta di modificare questa variabile in un cluster primario, viene visualizzato un errore.

CloudWatch Metriche di Amazon per l'inoltro della scrittura in Aurora My SQL

Le seguenti CloudWatch metriche di Amazon e le variabili di stato Aurora SQL My 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 metrica Aurora La mia SQL variabile di stato Unità Descrizione

AuroraDMLRejectedMasterFull

 – Conteggio

Il numero di query inoltrate che vengono rifiutate perché la sessione è piena sull'istanza DB di Writer.

Per Aurora La mia SQL versione 2.

AuroraDMLRejectedWriterFull

 – Conteggio

Il numero di query inoltrate che vengono rifiutate perché la sessione è piena sull'istanza DB di Writer.

Per Aurora La mia SQL versione 3.

ForwardingMasterDMLLatency

 – Millisecondi

Tempo medio di elaborazione di ogni DML istruzione inoltrata sull'istanza Writer DB.

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 La mia SQL versione 2.

ForwardingMasterDMLThroughput

 – Conteggio al secondo

Numero di DML istruzioni inoltrate elaborate ogni secondo da questa istanza DB di Writer.

Per Aurora La mia SQL versione 2.

ForwardingMasterOpenSessions

 Aurora_fwd_master_open_sessions Conteggio

Numero di sessioni inoltrate sull'istanza database writer.

Per Aurora La mia SQL versione 2.

–

 Aurora_fwd_master_dml_stmt_count Conteggio

Numero totale di DML istruzioni inoltrate a questa istanza DB di Writer.

Per Aurora La mia SQL versione 2.

–

 Aurora_fwd_master_dml_stmt_duration Microsecondi

Durata totale delle DML dichiarazioni inoltrate a questa istanza DB di Writer.

Per Aurora La mia SQL versione 2.

–

 Aurora_fwd_master_select_stmt_count Conteggio

Numero totale di istruzioni SELECT inoltrate a questa istanza database writer.

Per Aurora La mia SQL versione 2.

–

 Aurora_fwd_master_select_stmt_duration Microsecondi

Durata totale delle istruzioni SELECT inoltrate a questa istanza database writer.

Per Aurora La mia SQL versione 2.

ForwardingWriterDMLLatency

 – Millisecondi

Tempo medio di elaborazione di ogni DML istruzione inoltrata sull'istanza Writer DB.

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 La mia SQL versione 3.

ForwardingWriterDMLThroughput

 – Conteggio al secondo

Numero di DML istruzioni inoltrate elaborate ogni secondo da questa istanza DB di Writer.

Per Aurora La mia SQL versione 3.

ForwardingWriterOpenSessions

 Aurora_fwd_writer_open_sessions Conteggio

Numero di sessioni inoltrate sull'istanza database writer.

Per Aurora La mia SQL versione 3.

–

 Aurora_fwd_writer_dml_stmt_count Conteggio

Numero totale di DML istruzioni inoltrate a questa istanza DB di Writer.

Per Aurora La mia SQL versione 3.

–

 Aurora_fwd_writer_dml_stmt_duration Microsecondi Durata totale delle DML dichiarazioni inoltrate a questa istanza DB di Writer.

–

 Aurora_fwd_writer_select_stmt_count Conteggio

Numero totale di istruzioni SELECT inoltrate a questa istanza database writer.

Per Aurora La mia SQL versione 3.

–

 Aurora_fwd_writer_select_stmt_duration Microsecondi

Durata totale delle istruzioni SELECT inoltrate a questa istanza database writer.

Per Aurora La mia SQL versione 3.

Le seguenti CloudWatch metriche e le variabili di stato Aurora SQL My 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 metrica Aurora La mia SQL variabile di stato Unità Descrizione

ForwardingReplicaDMLLatency

 – Millisecondi Tempo di risposta medio inoltrato DMLs sulla replica.

ForwardingReplicaDMLThroughput

 – Conteggio al secondo Numero di dichiarazioni inoltrate elaborate ogni secondo. DML

ForwardingReplicaOpenSessions

 Aurora_fwd_replica_open_sessions 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 ForwardedSELECTlatenza, media su tutte le inoltrateSELECTdichiarazioni entro il periodo di monitoraggio.

ForwardingReplicaSelectThroughput

 – Conteggio al secondo Velocità di trasmissione effettiva per secondo SELECT inoltrata media all'interno del periodo di monitoraggio.

–

 Aurora_fwd_replica_dml_stmt_count Conteggio Numero totale di DML istruzioni inoltrate da questa istanza DB Reader.

–

 Aurora_fwd_replica_dml_stmt_duration Microsecondi Durata totale di tutte le DML istruzioni inoltrate da questa istanza DB Reader.

–

 Aurora_fwd_replica_errors_session_limit Conteggio

Numero di sessioni rifiutate dal cluster primario a causa di una delle seguenti condizioni di errore:

  • istanza di scrittura piena

  • Troppe istruzioni inoltrate in corso.

–

 Aurora_fwd_replica_read_wait_count Conteggio Numero totale di read-after-write attese su questa istanza DB del lettore.

–

 Aurora_fwd_replica_read_wait_duration Microsecondi Durata totale delle attese a causa dell'impostazione di coerenza di lettura su questa istanza database del lettore.

–

 Aurora_fwd_replica_select_stmt_count Conteggio Numero totale di istruzioni SELECT inoltrate dall'istanza database del lettore.

–

 Aurora_fwd_replica_select_stmt_duration Microsecondi Durata totale delle istruzioni SELECT inoltrate da questa istanza database del lettore.