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 Postgre SQL
Argomenti
- Disponibilità per regione e versione dell'inoltro di scrittura in Aurora Postgre SQL
- Abilitazione dell'inoltro di scrittura in Aurora Postgre SQL
- Verifica se un cluster secondario ha l'inoltro di scrittura abilitato in Aurora Postgree SQL
- Applicazione e SQL compatibilità con l'inoltro di scrittura in Aurora Postgre SQL
- Isolamento e coerenza per l'inoltro della scrittura in Aurora Postgre SQL
- Esecuzione di istruzioni multiparte con inoltro di scrittura in Aurora Postgre SQL
- Parametri di configurazione per l'inoltro della scrittura in Aurora Postgre SQL
- CloudWatch Metriche di Amazon per l'inoltro della scrittura in Aurora Postgre SQL
- Attendi gli eventi per l'inoltro della scrittura in Aurora Postgre SQL
Disponibilità per regione e versione dell'inoltro di scrittura in Aurora Postgre SQL
L'inoltro della scrittura è supportato con la SQL versione 15.4 e successive di Aurora Postgre e con la versione 14.9 e versioni secondarie successive. L'inoltro della scrittura è disponibile in tutte le regioni in cui sono disponibili database globali basati su Aurora Postgre. SQL
Per ulteriori informazioni sulla disponibilità della versione e della regione dei database SQL globali di Aurora Postgre, vedere. Database globali Aurora con Aurora Postgre SQL
Abilitazione dell'inoltro di scrittura in Aurora Postgre SQL
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.
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.
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.
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
Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/
. -
Scegli Database.
-
Scegli il cluster di database secondario e scegli Modifica.
-
Nella sezione Abilita inoltro in scrittura della replica in lettura, seleziona o deseleziona la casella di controllo Attiva l'inoltro di scrittura globale.
-
Scegli Continua.
-
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.
-
Scegliere Modify cluster (Modifica cluster).
Per abilitare l'inoltro di scrittura utilizzando AWS CLI, usa l'--enable-global-write-forwarding
opzione. Questa opzione funziona quando si crea un nuovo cluster secondario utilizzando il create-db-clustercomando. Funziona anche quando si modifica un cluster secondario esistente utilizzando il modify-db-clustercomando. Richiede che il database globale utilizzi una versione Aurora che supporti l'inoltro di scrittura. È possibile disabilitare l'inoltro di scrittura utilizzando l'--no-enable-global-write-forwarding
opzione con questi stessi CLI comandi.
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 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 LinuxmacOS, oUnix:
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
-
Per abilitare l'inoltro di scrittura tramite Amazon RDSAPI, imposta il EnableGlobalWriteForwarding
parametro su. true
Questo parametro funziona quando crei un nuovo cluster secondario utilizzando l'operazione C. reateDBCluster Funziona anche quando si modifica un cluster secondario esistente utilizzando l'odifyDBClusteroperazione M. 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 l'inoltro di scrittura abilitato in Aurora Postgree SQL
Per determinare se è possibile utilizzare l'inoltro di scrittura da un cluster secondario, è possibile verificare se il cluster dispone dell'attributo "GlobalWriteForwardingStatus": "enabled"
.
Nella AWS Management Console, vedi nella scheda Configurazione della Read replica write forwarding
pagina dei dettagli del cluster. 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.
Esempio
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 Postgre SQL
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 SQL istruzioni con l'inoltro della scrittura:
-
Istruzioni Data Manipulation Language (DML), come
INSERT
, eDELETE
UPDATE
-
Istruzioni
SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }
-
Istruzioni
PREPARE
eEXECUTE
. -
Istruzioni
EXPLAIN
con le istruzioni in questo elenco
I seguenti tipi di SQL istruzioni non sono supportati con l'inoltro della scrittura:
-
Istruzioni Data Definition Language () DDL
-
ANALYZE
-
CLUSTER
-
COPY
-
Cursori: i cursori non sono supportati, quindi assicurati di chiuderli prima di utilizzare l'inoltro di scrittura.
-
GRANT
|REVOKE
|REASSIGN OWNED
|SECURITY LABEL
-
LOCK
-
Istruzioni
SAVEPOINT
-
SELECT INTO
-
SET CONSTRAINTS
-
TRUNCATE
-
VACUUM
Isolamento e coerenza per l'inoltro della scrittura in Aurora Postgre SQL
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 a livello di sessione 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.
All'aumentare del 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 della scrittura in Aurora Postgre SQL.
Esecuzione di istruzioni multiparte con inoltro di scrittura in Aurora Postgre SQL
Un'DMListruzione può essere composta da più parti, ad esempio un'istruzione o un'istruzione. INSERT ... SELECT
DELETE ... WHERE
In questo caso, l'intera istruzione viene inoltrata al cluster primario ed eseguita lì.
Parametri di configurazione per l'inoltro della scrittura in Aurora Postgre 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 |
---|---|---|---|---|
apg_write_forward.connect_timeout
|
Sessione | secondi | 30 | 0–2147483647 |
apg_write_forward.consistency_mode |
Sessione | enum | Sessione |
SESSION , EVENTUAL , GLOBAL , OFF
|
apg_write_forward.idle_in_transaction_session_timeout
|
Sessione | millisecondi | 86400000 | 0–2147483647 |
apg_write_forward.idle_session_timeout
|
Sessione | millisecondi | 300000 | 0–2147483647 |
apg_write_forward.max_forwarding_connections_percent
|
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 sonoSESSION
,EVENTUAL
,GLOBAL
oOFF
. Per impostazione predefinita, il valore è impostato suSESSION
. L'impostazione del valore suOFF
disabilita l'inoltro di scrittura nella sessione. Per ulteriori informazioni sui livelli di coerenza, consulta Isolamento e coerenza per l'inoltro della scrittura in Aurora Postgre SQL. 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 valore0
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 valore0
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 valore0
disabilita il timeout.
CloudWatch Metriche di Amazon per l'inoltro della scrittura in Aurora Postgre SQL
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 Metrica | Unità e descrizione |
---|---|
|
Conteggio (al secondo) Numero di DML istruzioni inoltrate elaborate ogni secondo da questa istanza DB di Writer. |
|
Conteggio Numero di sessioni aperte su questa istanza database di scrittura che elabora le query inoltrate. |
|
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 Metrica | Unità e descrizione |
---|---|
|
Conteggio (al secondo) Numero di commit in sessioni inoltrate da questa replica ogni secondo. |
|
Millisecondi Tempo di risposta medio in millisecondi di inoltro sulla replica. DMLs |
|
Conteggio (al secondo) Numero di dichiarazioni DML inoltrate elaborate su questa replica ogni secondo. |
|
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. |
|
Conteggio Il numero di sessioni che utilizzano l'inoltro di scrittura su un'istanza di replica. |
|
Millisecondi Tempo di attesa medio in millisecondi che la replica attende per essere coerente con quello del cluster primario. LSN Il grado di attesa dell'istanza database in lettura dipende dall'impostazione apg_write_forward.consistency_mode . Per ulteriori informazioni su questa impostazione, consulta Parametri di configurazione per l'inoltro della scrittura in Aurora Postgre SQL. |
Attendi gli eventi per l'inoltro della scrittura in Aurora Postgre SQL
Amazon Aurora genera i seguenti eventi di attesa quando utilizzi l'inoltro di scrittura con Aurora Postgre. SQL
Argomenti
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 della scrittura in Aurora Postgre SQL.
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 di Aurora Postgree SQL.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 del linguaggio di manipolazione dei dati (DML) 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 cambiarlo in un tipo di istanza con maggiore CPU capacità o maggiore larghezza di banda di rete.
IPC:AuroraWriteForwardGetGlobalConsistencyPoint
L'IPC:AuroraWriteForwardGetGlobalConsistencyPoint
evento si verifica quando un processo di backend sul cluster DB secondario che utilizza la modalità di GLOBAL consistenza è in attesa di ottenere il punto di coerenza globale dal nodo writer 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 cambiarlo in un tipo di istanza con maggiore CPU capacità 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 cambiarlo in un tipo di istanza con maggiore capacità o maggiore larghezza di banda di rete. CPU
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 cambiarlo in un tipo di istanza con maggiore capacità o maggiore larghezza di banda di rete. CPU
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 cambiarlo in un tipo di istanza con maggiore capacità o maggiore larghezza di banda di rete. CPU