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 locale in un cluster database Amazon Aurora MySQL
Inoltro di scrittura locale (all'interno del cluster) consente alle applicazioni di eseguire transazioni di lettura/scrittura direttamente su una replica di Aurora. Queste transazioni vengono quindi inoltrate all'istanza database di scrittura in attesa che venga eseguito il commit. Puoi utilizzare l'inoltro di scrittura locale quando le applicazioni richiedono la coerenza lettura dopo scrittura, che è la capacità di leggere l'ultima scrittura in una transazione.
Le repliche di lettura ricevono aggiornamenti in modo asincrono dall'istanza di scrittura. Senza l'inoltro di scrittura, è necessario eseguire la transazione delle eventuali letture che richiedono la coerenza lettura dopo scrittura sull'istanza database di scrittura. Oppure è necessario sviluppare una logica dell'applicazione personalizzata complessa per sfruttare più repliche di lettura per la scalabilità. Le applicazioni devono suddividere completamente tutto il traffico in lettura e in scrittura, mantenendo due gruppi di connessioni al database per inviare il traffico all'endpoint corretto. Questi costi di sviluppo complicano la progettazione dell'applicazione quando le query fanno parte di una singola sessione logica, o transazione, all'interno dell'applicazione. Inoltre, poiché il ritardo di replica può variare tra le repliche di lettura, è difficile ottenere una coerenza di lettura globale tra tutte le istanze nel database.
L'inoltro di scrittura evita la necessità di suddividere tali transazioni o inviarle esclusivamente all'istanza di scrittura, semplificando lo sviluppo dell'applicazione. Questa nuova funzionalità consente di ottenere facilmente il dimensionamento della lettura per carichi di lavoro che devono leggere l'ultima scrittura in una transazione e non sono sensibili alla latenza di scrittura.
L'inoltro di scrittura locale è diverso dall'inoltro di scrittura globale, che inoltra le scritture da un cluster database secondario al cluster database primario in un database globale Aurora. Puoi utilizzare l'inoltro di scrittura locale in un cluster database che fa parte di un database globale Aurora. Per ulteriori informazioni, consulta Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora.
L'inoltro di scrittura locale richiede Aurora MySQL versione 3.04 o successive.
Argomenti
- Abilitazione dell'inoltro di scrittura locale
- Verifica se l'inoltro di scrittura è abilitato un cluster database
- Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura
- Livelli di isolamento per l'inoltro di scrittura
- Coerenza di lettura per l'inoltro di scrittura
- Esecuzione di istruzioni a più parti con inoltro scrittura
- Transazioni con inoltro di scrittura
- Parametri di configurazione per l'inoltro di scrittura
- Parametri di Amazon CloudWatch e variabili di stato di Aurora MySQL per l'inoltro di scrittura
- Identificazione delle transazioni e delle query inoltrate
Abilitazione dell'inoltro di scrittura locale
Per impostazione predefinita, l'inoltro di scrittura locale non è abilitato per i cluster database Aurora MySQL. Abilitare l'inoltro di scrittura locale a livello di cluster, non a livello di istanza.
Importante
Inoltre, è possibile abilitare l'inoltro di scrittura locale per le repliche di lettura tra regioni che utilizzano la registrazione binaria, ma le operazioni di scrittura non vengono inoltrate all'origine Regione AWS. Vengono inoltrate all'istanza database di scrittura del cluster di replica di lettura binlog.
Si consiglia di usare questo metodo solo se si dispone di un caso d'uso per scrivere nella replica di lettura binlog nella Regione AWS secondaria. In caso contrario, si potrebbe verificare uno scenario "split-brain" in cui i set di dati replicati non sono tra loro coerenti.
Si consiglia di utilizzare l'inoltro di scrittura globale con database globali, anziché l'inoltro di scrittura locale su repliche di lettura tra regioni, a meno che non sia assolutamente necessario. Per ulteriori informazioni, consulta Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora.
Usando la AWS Management Console, seleziona la casella di controllo Attiva l'inoltro di scrittura locale in Inoltro di scrittura di repliche di lettura quando si crea o si modifica un cluster database.
Per abilitare l'inoltro di scrittura con la AWS CLI, usa l'opzione --enable-local-write-forwarding
. Questa opzione funziona quando si crea un nuovo cluster database secondario tramite il comando create-db-cluster
. Inoltre, funziona quando si modifica un cluster database esistente tramite il comando modify-db-cluster
. Puoi disattivare l'inoltro di scrittura mediante l'opzione --no-enable-local-write-forwarding
con questi stessi comandi CLI.
Nell'esempio seguente viene creato un cluster DB Aurora MySQL con l'inoltro di scrittura abilitato.
aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \
--enable-local-write-forwarding
\ --engine aurora-mysql \ --engine-version8.0.mysql_aurora.3.04.0
\ --master-username myuser \ --master-user-password mypassword \ --backup-retention 1
Vengono quindi create istanze database di scrittura e lettura in modo da poter utilizzare l'inoltro di scrittura. Per ulteriori informazioni, consulta Creazione di un cluster database Amazon Aurora.
Per abilitare l'inoltro di scrittura utilizzando l'API Amazon RDS, impostare il parametro EnableLocalWriteForwarding
su true
. Questo parametro funziona quando si crea un nuovo cluster database secondario utilizzando l'operazione CreateDBCluster
. Funziona anche quando si modifica un cluster database esistente utilizzando l'operazione ModifyDBCluster
. È possibile disattivare l'inoltro di scrittura impostando il parametro EnableLocalWriteForwarding
su false
.
Abilitazione dell'inoltro di scrittura per le sessioni di database
Il parametro aurora_replica_read_consistency
è un parametro database e un parametro del cluster database che abilita l'inoltro di scrittura. È possibile specificare EVENTUAL
, SESSION
o GLOBAL
per il livello di coerenza di lettura. Per ulteriori informazioni sui livelli di coerenza, consulta Coerenza di lettura per l'inoltro di scrittura.
A questo parametro si applicano le seguenti regole:
-
Il valore predefinito è '' (null).
-
L'inoltro di scrittura è disponibile solo se
aurora_replica_read_consistency
è impostato suEVENTUAL
,SESSION
oGLOBAL
. Questo parametro è rilevante solo nelle istanze di lettura di cluster database secondari con l'inoltro di scrittura abilitato. -
Non è possibile importare questo parametro (quando vuoto) o annullarne l'impostazione (quando già impostato) all'interno di una transazione con più istruzioni. È possibile modificarlo da un valore valido a un altro valore valido durante una transazione di questo tipo, ma questa azione non è consigliata.
Verifica se l'inoltro di scrittura è abilitato un cluster database
Per determinare se è possibile utilizzare l'inoltro di scrittura in un cluster database, verifica che l'attributo LocalWriteForwardingStatus
del cluster sia impostato su enabled
.
In AWS Management Console, nella scheda Configurazione della pagina dei dettagli del cluster, viene visualizzato lo stato Abilitato per Inoltro di scrittura locale di replica di lettura.
Per visualizzare lo stato dell'impostazione di inoltro di scrittura per tutti i cluster, esegui il comando AWS CLI seguente.
aws rds describe-db-clusters \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}' [ { "LocalWriteForwardingStatus": "enabled", "DBClusterIdentifier": "write-forwarding-test-cluster-1" }, { "LocalWriteForwardingStatus": "disabled", "DBClusterIdentifier": "write-forwarding-test-cluster-2" }, { "LocalWriteForwardingStatus": "requested", "DBClusterIdentifier": "test-global-cluster-2" }, { "LocalWriteForwardingStatus": "null", "DBClusterIdentifier": "aurora-mysql-v2-cluster" } ]
Un cluster database può avere i seguenti valori per LocalWriteForwardingStatus
:
-
disabled
: l'inoltro di scrittura è disabilitato. -
disabling
: l'inoltro di scrittura è in fase di disabilitazione. -
enabled
: l'inoltro di scrittura è abilitato. -
enabling
: l'inoltro di scrittura è in fase di abilitazione. -
null
: l'inoltro di scrittura non è disponibile per questo cluster database. -
requested
: l'inoltro di scrittura è stato richiesto, ma non è ancora attivo.
Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura
È possibile utilizzare i seguenti tipi di istruzioni SQL con l'inoltro di scrittura:
-
Istruzioni DML (Data Manipulation Language), ad esempio
INSERT
,DELETE
eUPDATE
. 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
eSELECT FOR UPDATE
. -
Istruzioni
PREPARE
eEXECUTE
.
Alcune istruzioni non sono consentite o possono produrre risultati non aggiornati quando vengono utilizzate in un cluster database con inoltro di scrittura. Pertanto, l'impostazione EnableLocalWriteForwarding
è disabilitata per impostazione predefinita per i cluster database. Prima di abilitarla, 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 database con inoltro di scrittura abilitato. Questo approccio funziona se l'inoltro di scrittura non è abilitato all'interno della sessione dal parametro di configurazione aurora_replica_read_consistency
. Se si prova a utilizzare un'istruzione quando non è consentita a causa dell'inoltro di scrittura, verrà visualizzato un messaggio di errore simile al seguente:
ERROR 1235 (42000): This version of MySQL doesn't yet support '
operation
with write forwarding'.
- DDL (Data Definition Language)
-
Connettersi all'istanza database di scrittura 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 database 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. - Transazioni XA
-
Non è possibile utilizzare le istruzioni seguenti in un cluster database quando l'inoltro di scrittura è abilitato all'interno della sessione. È possibile utilizzare queste istruzioni su cluster database 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 abilitare l'inoltro di scrittura all'interno di una sessione, occorre 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 database con l'inoltro di scrittura abilitato.
LOAD DATA INFILE 'data.txt' INTO TABLE t1; LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
- Istruzioni plugin
-
Non è possibile utilizzare le istruzioni seguenti in un cluster database 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 database quando l'inoltro di scrittura è abilitato all'interno della sessione. È possibile utilizzare queste istruzioni su cluster database in cui l'inoltro di scrittura non è abilitato o all'interno di sessioni in cui l'impostazione
aurora_replica_read_consistency
è vuota. Prima di abilitare l'inoltro di scrittura all'interno di una sessione, occorre verificare se il codice utilizza queste istruzioni.SAVEPOINT t1_save; ROLLBACK TO SAVEPOINT t1_save; RELEASE SAVEPOINT t1_save;
Livelli di isolamento per l'inoltro di scrittura
Nelle sessioni che utilizzano l'inoltro di scrittura, è possibile utilizzare solo il livello di isolamento REPEATABLE READ
. Sebbene sia possibile utilizzare il livello di isolamento READ COMMITTED
anche con repliche di Aurora, questa operazione 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.
Coerenza di lettura per l'inoltro di scrittura
È possibile controllare il grado di coerenza di lettura in un cluster database. Il livello di coerenza di lettura determina il tempo di attesa di un cluster database prima di ogni operazione di lettura per garantire che alcune o tutte le modifiche vengano replicate dall'istanza di scrittura. È possibile regolare il livello di coerenza di lettura per garantire che tutte le operazioni di scrittura inoltrate dalla sessione siano visibili nel cluster database prima di qualsiasi query successiva. Inoltre, è possibile utilizzare questa impostazione per garantire che le query sul cluster database visualizzino sempre gli aggiornamenti più recenti dall'istanza di scrittura. Questa impostazione si applica anche alle query inviate da altre sessioni o da altri cluster. Per specificare questo tipo di comportamento per l'applicazione, scegli un valore per il parametro database aurora_replica_read_consistency
o il parametro cluster database.
Importante
Imposta sempre il parametro database aurora_replica_read_consistency
o il parametro cluster database quando desideri inoltrare le scritture. In caso contrario, Aurora non inoltra le scritture. Questo parametro ha un valore vuoto per impostazione predefinita, quindi scegli un valore specifico quando utilizzi questo parametro. Il parametro aurora_replica_read_consistency
influisce solo sui cluster o sulle istanze database in cui l'inoltro di scrittura è abilitato.
All'aumentare del livello di coerenza, l'applicazione rimane più tempo in attesa della propagazione delle modifiche tra le istanze database. È possibile scegliere il giusto equilibrio tra tempi di risposta rapidi e garanzia che le modifiche apportate in altre istanze database siano completamente disponibili prima dell'esecuzione delle query.
È possibile specificare i valori seguenti per il parametro aurora_replica_read_consistency
:
-
EVENTUAL
: i risultati delle operazioni di scrittura nella stessa sessione non sono visibili finché l'operazione di scrittura non viene eseguita sull'istanza database di scrittura. La query non attende la disponibilità dei risultati aggiornati. Pertanto, potrebbe recuperare i dati più vecchi o i dati aggiornati, a seconda della tempistica delle istruzioni e della quantità di ritardo di replica. Questa è la stessa coerenza dei cluster database Aurora MySQL che non utilizzano l'inoltro di scrittura. -
SESSION
: tutte le query che utilizzano 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. -
GLOBAL
: una sessione visualizza tutte le modifiche confermate in tutte le sessioni e le istanze nel cluster database. Ogni query potrebbe attendere un periodo che varia a seconda della quantità di ritardo della sessione. La query procede quando il cluster database viene aggiornato con tutti i dati confermati dall'istanza di scrittura, a partire dal momento in cui la query è iniziata.
Per informazioni su tutti i parametri di configurazione coinvolti nell'inoltro di scrittura, consulta Parametri di configurazione per l'inoltro di scrittura.
Nota
È anche possibile usare aurora_replica_read_consistency
come una variabile di sessione, ad esempio:
mysql> set aurora_replica_read_consistency = 'session';
Esempi di utilizzo dell'inoltro di scrittura
Negli esempi seguenti vengono illustrati gli effetti del parametro aurora_replica_read_consistency
sull'esecuzione delle istruzioni INSERT
seguite dalle istruzioni SELECT
. I risultati possono variare, a seconda del valore di aurora_replica_read_consistency
e 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
.
Per informazioni sull'impostazione dei parametri database, consulta .
Esempio con aurora_replica_read_consistency
impostato su EVENTUAL
L'esecuzione di un'istruzione INSERT
, immediatamente seguita da un'istruzione SELECT
, restituisce un valore per COUNT(*)
con 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> 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)
Esempio con aurora_replica_read_consistency
impostato su SESSION
Un'istruzione SELECT
subito dopo l'istruzione INSERT
attende fino a quando le modifiche apportate dall'istruzione INSERT
diventano visibili. Le istruzioni SELECT
successive non attendono.
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)
Esempio con aurora_replica_read_consistency
impostato su GLOBAL
Ogni istruzione SELECT
attende che tutte le modifiche ai dati, a partire dall'ora di inizio dell'istruzione, diventino visibili prima di eseguire la query. Il tempo di attesa per ciascuna istruzione SELECT
varia, a seconda dell'entità di ritardo di replica.
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
Un'istruzione DML può essere costituita da più parti, ad esempio un'istruzione INSERT ... SELECT
o un'istruzione DELETE ...
WHERE
. In questo caso, l'intera istruzione viene inoltrata all'istanza database di scrittura ed eseguita lì.
Transazioni con inoltro di scrittura
Se la modalità di accesso alle transazioni è impostata su sola lettura, l'inoltro di scrittura non viene utilizzato. È 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
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. È possibile impostare il parametro aurora_fwd_writer_idle_timeout
per aumentarlo fino a un giorno. Una transazione che supera il timeout di inattività viene annullata dall'istanza di scrittura. 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 le eventuali transazioni che utilizzano l'inoltro di scrittura se si riavvia il cluster database o si disabilita l'inoltro di scrittura.
Quando un'istanza di scrittura in un cluster che utilizza l'inoltro di scrittura locale viene riavviata, le eventuali transazioni e query attive, inoltrate sulle istanze di lettura che utilizzano l'inoltro di scrittura locale vengono chiuse automaticamente. Dopo che l'istanza di scrittura sarà nuovamente disponibile, è possibile riprovare a eseguire queste transazioni.
Parametri di configurazione per l'inoltro di scrittura
I gruppi di parametri database Aurora contengono impostazioni per la funzionalità di inoltro di scrittura. I dettagli su questi parametri sono riepilogati nella tabella seguente, con note di utilizzo dopo la tabella.
Parametro | Ambito | Tipo | Valore predefinito | Valori validi |
---|---|---|---|---|
aurora_fwd_writer_idle_timeout |
Cluster | Intero senza segno | 60 | 1–86.400 |
aurora_fwd_writer_max_connections_pct |
Cluster | Intero lungo senza segno | 10 | 0–90 |
aurora_replica_read_consistency |
Cluster o istanza | Enum | '' (null) | EVENTUAL , SESSION , GLOBAL |
Per controllare le richieste di scrittura in entrata, usare queste impostazioni:
-
aurora_fwd_writer_idle_timeout
: il numero di secondi per cui l'istanza database di scrittura rimane in attesa su una connessione inoltrata da un'istanza di lettura prima di chiuderla. Se la sessione rimane inattiva oltre questo periodo, la sessione viene annullata da Aurora. -
aurora_fwd_writer_max_connections_pct
: il limite superiore delle connessioni al database che può essere utilizzato su un'istanza database di scrittura per gestire le query inoltrate da istanze di lettura. È espresso come una percentuale dell'impostazionemax_connections
per l'istanza di scrittura. Ad esempio, semax_connections
è 800 eaurora_fwd_master_max_connections_pct
oaurora_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'impostazionemax_connections
.Questa impostazione si applica solo all'istanza di scrittura quando l'inoltro di scrittura è abilitato. Se si riduce il valore, le connessioni esistenti non vengono influenzate. Aurora tiene in considerazione il nuovo valore dell'impostazione durante il tentativo di creazione di una nuova connessione da un cluster database. Il valore predefinito è 10, che rappresenta il 10% del valore
max_connections
.
Nota
Poiché aurora_fwd_writer_idle_timeout
e aurora_fwd_writer_max_connections_pct
sono parametri del cluster database, tutte le istanze database in ogni cluster hanno gli stessi valori per questi parametri.
Per ulteriori informazioni su aurora_replica_read_consistency
, consulta Coerenza di lettura per l'inoltro di scrittura.
Per ulteriori informazioni sui gruppi di parametri database, consulta .
Parametri di Amazon CloudWatch e variabili di stato di Aurora MySQL per l'inoltro di scrittura
I parametri Amazon CloudWatch e le variabili di stato Aurora MySQL seguenti si applicano quando si utilizza l'inoltro di scrittura su uno o più cluster database. Questi parametri e variabili di stato vengono tutti misurati sull'istanza database di scrittura.
Parametro CloudWatch | Variabile di stato Aurora MySQL | Unità | Descrizione |
---|---|---|---|
|
– | Millisecondi |
Tempo medio per elaborare ogni istruzione DML inoltrata sull'istanza database writer. Non include il tempo impiegato dal cluster database per inoltrare la richiesta di scrittura o il tempo necessario per replicare le modifiche all'istanza di scrittura. |
|
– | Conteggio al secondo | Numero di istruzioni DML inoltrate elaborate ogni secondo da questa istanza database writer. |
|
Aurora_fwd_writer_open_sessions |
Conteggio | Numero di sessioni inoltrate sull'istanza database writer. |
– |
Aurora_fwd_writer_dml_stmt_count |
Conteggio | Numero totale di istruzioni DML inoltrate a questa istanza database writer. |
– |
Aurora_fwd_writer_dml_stmt_duration |
Microsecondi | Durata totale delle istruzioni DML inoltrate a questa istanza database writer. |
– |
Aurora_fwd_writer_select_stmt_count |
Conteggio | Numero totale di istruzioni SELECT inoltrate a questa istanza database writer. |
– |
Aurora_fwd_writer_select_stmt_duration |
Microsecondi | Durata totale delle istruzioni SELECT inoltrate a questa istanza database writer. |
I seguenti parametri CloudWatch e le variabili di stato Aurora MySQL vengono misurati su ciascuna istanza database di lettura in un cluster database con l'inoltro di scrittura abilitato.
Parametro CloudWatch | Variabile di stato Aurora MySQL | Unità | Descrizione |
---|---|---|---|
|
– | Millisecondi | Tempo medio di risposta di DML inoltrati su replica. |
|
– | Conteggio al secondo | Numero di istruzioni DML inoltrate elaborate al secondo. |
|
Aurora_fwd_replica_open_sessions |
Conteggio | Numero di sessioni che utilizzano l'inoltro di scrittura su un'istanza database di lettura. |
|
– | Millisecondi |
Tempo medio di attesa di un'istruzione Il grado di attesa dell'istanza database del lettore prima di elaborare una query dipende dall'impostazione |
|
– | Conteggio al secondo | Numero totale di istruzioni SELECT elaborate ogni secondo in tutte le sessioni che inoltrano scritture. |
|
– | Millisecondi | Latenza SELECT inoltrata, mediata su tutte le istruzioni SELECT inoltrate all'interno del periodo di monitoraggio. |
|
– | 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 istruzioni DML inoltrate da questa istanza database del lettore. |
– |
Aurora_fwd_replica_dml_stmt_duration |
Microsecondi | Durata totale delle istruzioni DML inoltrate da questa istanza database del lettore. |
– |
Aurora_fwd_replica_errors_session_limit |
Conteggio |
Numero di sessioni rifiutate dal cluster primario a causa di una delle seguenti condizioni di errore:
|
– |
Aurora_fwd_replica_read_wait_count |
Conteggio | Numero totale di attese di lettura-post-scrittura su questa istanza database 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. |
Identificazione delle transazioni e delle query inoltrate
È possibile usare la tabella information_schema.aurora_forwarding_processlist
per identificare le transazioni e le query inoltrate. Per ulteriori informazioni su questa tabella, consultare information_schema.aurora_forwarding_processlist.
L'esempio seguente mostra tutte le connessioni inoltrate su un'istanza database di scrittura.
mysql> select * from information_schema.AURORA_FORWARDING_PROCESSLIST where IS_FORWARDED=1 order by REPLICA_SESSION_ID; +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+ | ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | IS_FORWARDED | REPLICA_SESSION_ID | REPLICA_INSTANCE_IDENTIFIER | REPLICA_CLUSTER_NAME | REPLICA_REGION | +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+---------------------------------------+ | 648 | myuser |
IP_address:port1
| sysbench | Query | 0 | async commit | UPDATE sbtest58 SET k=k+1 WHERE id=4802579 | 1 | 637 | my-db-cluster-instance-2 | my-db-cluster | us-west-2 | | 650 | myuser |IP_address:port2
| sysbench | Query | 0 | async commit | UPDATE sbtest54 SET k=k+1 WHERE id=2503953 | 1 | 639 | my-db-cluster-instance-2 | my-db-cluster | us-west-2 | +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
Nell'istanza database di lettura di inoltro, è possibile visualizzare i thread associati a queste connessioni database di scrittura eseguendoSHOW PROCESSLIST
. Il valori REPLICA_SESSION_ID
sull'istanza di scrittura, 637 e 639, sono identici ai valoriId
sull'istanza di lettura.
mysql> select @@aurora_server_id; +---------------------------------+ | @@aurora_server_id | +---------------------------------+ | my-db-cluster-instance-2 | +---------------------------------+ 1 row in set (0.00 sec) mysql> show processlist; +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ | 637 | myuser |
IP_address:port1
| sysbench | Query | 0 | async commit | UPDATE sbtest12 SET k=k+1 WHERE id=4802579 | | 639 | myuser |IP_address:port2
| sysbench | Query | 0 | async commit | UPDATE sbtest61 SET k=k+1 WHERE id=2503953 | +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ 12 rows in set (0.00 sec)