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à.
Replica con Amazon Aurora PostgreSQL
Di seguito, puoi trovare informazioni sulla replica con Amazon Aurora PostgreSQL, incluso come monitorare e utilizzare la replica logica.
Argomenti
Utilizzo delle repliche di Aurora
Le repliche Aurora sono endpoint indipendenti in un cluster database Aurora, utilizzati specialmente per operazioni di dimensionamento della lettura e maggiore disponibilità. Un cluster Aurora DB può includere fino a 15 repliche Aurora situate nelle zone di disponibilità della regione del cluster Aurora DB. AWS
Il volume del cluster DB si compone di più copie dei dati per il cluster DB. Tuttavia, i dati nel volume del cluster sono rappresentati come singolo volume logico all'istanza primaria di scrittura e alle repliche di Aurora nel cluster di database. Per ulteriori informazioni sulle repliche di Aurora, consulta Repliche di Aurora.
Le repliche di Aurora funzionano bene per il dimensionamento della lettura perché sono dedicate completamente a operazioni di lettura nel volume del cluster. L’istanza database di scrittura gestisce le operazioni di scrittura. Il volume del cluster è condiviso tra tutte le istanze del cluster di database Aurora PostgreSQL. Di conseguenza, non occorre fare altro per replicare una copia dei dati per ciascuna replica Aurora.
Con Aurora PostgreSQL, quando una replica Aurora viene eliminata, l'endpoint dell'istanza viene rimosso immediatamente e la replica Aurora viene rimossa dall'endpoint di lettura. Se vi sono istruzioni in esecuzione nella replica Aurora da eliminare, si ha un periodo di tolleranza di tre minuti. Le istruzioni esistenti possono finire correttamente durante un periodo di tolleranza. Quando finisce il periodo di tolleranza, la replica Aurora viene chiusa ed eliminata.
I cluster Aurora PostgreSQL DB supportano le repliche Aurora in diverse regioni, utilizzando il database globale Aurora. AWS Per ulteriori informazioni, consulta Utilizzo del database globale Amazon Aurora.
Nota
Con la funzionalità di disponibilità di lettura, se si desidera riavviare le repliche Aurora nel cluster DB, è necessario eseguirla manualmente. Per i cluster database creati prima di questa funzionalità, il riavvio dell'istanza database di scrittura comporta il riavvio automatico delle repliche Aurora. Il riavvio automatico ristabilisce un punto di ingresso che garantisce la coerenza di lettura e scrittura in tutto il cluster di database.
Miglioramento della disponibilità di lettura delle repliche Aurora
Aurora PostgreSQL migliora la disponibilità di lettura nel cluster database soddisfacendo continuamente le richieste di lettura quando l'istanza database di scrittura si riavvia o quando la replica Aurora non è in grado di gestire il traffico di scrittura.
La funzionalità della disponibilità di lettura è disponibile per impostazione predefinita nelle seguenti versioni di Aurora PostgreSQL:
16.1 e tutte le versioni successive
15.2 o versioni successive alla 15
14.7 o versioni successive alla 14
13.10 o versioni successive alla 13
12.14 e versioni successive alla 12
La funzionalità di disponibilità in lettura è supportata dal database globale Aurora nelle seguenti versioni:
16.1 e tutte le versioni successive
15.4 e versioni successive
14.9 e versioni successive
13.12 e versioni successive 13
12.16 e versioni successive 12
Per utilizzare la funzionalità della disponibilità di lettura per un cluster database creato in una di queste versioni prima del lancio, riavviare l'istanza di scrittura del cluster database.
Quando vengono modificati i parametri statici del cluster database Aurora PostgreSQL, è necessario riavviare l'istanza di scrittura per rendere effettive le modifiche apportate ai parametri. Ad esempio, è necessario riavviare l'istanza di scrittura quando si imposta il valore di shared_buffers. Con la funzionalità di disponibilità in lettura di Aurora Replicas, il cluster DB mantiene una maggiore disponibilità, riducendo l'impatto su di essa al riavvio dell'istanza di writer. Le istanze di lettura non si riavviano e continuano a rispondere alle richieste di lettura. Per applicare modifiche statiche ai parametri, riavviare ogni singola istanza di lettura.
Una replica Aurora di un cluster database Aurora PostgreSQL è in grado di ripristinare gli errori di replica, come riavvii dell'istanza di scrittura, failover, replica lenta e problemi di rete, ripristinando rapidamente lo stato del database in memoria dopo la riconnessione all'istanza di scrittura. Questo approccio consente alle istanze delle repliche Aurora di raggiungere la coerenza con gli ultimi aggiornamenti dell'archiviazione mentre il database client è ancora disponibile.
Le transazioni in corso che sono in conflitto con il ripristino della replica potrebbero ricevere un errore, ma il client può provare a rieseguire queste transazioni, dopo che le istanze di lettura hanno raggiunto i livelli di prestazioni dell'istanza di scrittura.
Monitoraggio delle repliche Aurora
È possibile monitorare le repliche Aurora durante il ripristino dopo una disconnessione dell'istanza di scrittura. Utilizzare le metriche riportate di seguito per verificare le informazioni più recenti sull'istanza di lettura e per tenere traccia delle transazioni di sola lettura in corso.
La
aurora_replica_statusfunzione viene aggiornata per restituire la maggior parte delle up-to-date informazioni per l'istanza Reader quando è ancora connessa. Il timestamp dell'ultimo aggiornamento inaurora_replica_statusè sempre vuoto per la riga corrispondente all'istanza database su cui viene eseguita la query. Ciò indica che l'istanza di lettura include i dati più recenti.Quando la replica Aurora si disconnette dall'istanza di scrittura e si riconnette, viene emesso il seguente evento del database:
Read replica has been disconnected from the writer instance and reconnected.Quando una query di sola lettura viene annullata a causa di un conflitto di ripristino, è possibile che nel registro degli errori del database vengano visualizzati uno o più dei seguenti messaggi di errore:
Canceling statement due to conflict with recovery.User query may not have access to page data to replica disconnect.User query might have tried to access a file that no longer exists.When the replica reconnects, you will be able to repeat your command.
Limitazioni
Le seguenti limitazioni si applicano alle repliche Aurora con la funzionalità di disponibilità di lettura:
Le repliche Aurora del cluster DB secondario possono riavviarsi se i dati non possono essere trasmessi in streaming dall'istanza del writer durante il ripristino della replica.
Le repliche Aurora non supportano il ripristino delle repliche online se una replica è già in corso e pertanto questa verrà riavviata.
Le repliche Aurora verranno riavviate quando l'istanza database si avvicina al wraparound dell'ID delle transazioni. Per ulteriori informazioni sul wraparound dell'ID delle transazioni, consulta l'argomento relativo alla risoluzione degli errori di wraparound dell'ID delle transazioni
. È possibile che le repliche Aurora vengano riavviate quando il processo di replica viene bloccato in determinate circostanze.
Monitoraggio della replica Aurora PostgreSQL.
Il dimensionamento di lettura e l'alta disponibilità dipendono da un periodo di ritardo minimo. Puoi monitorare il ritardo di una replica Aurora rispetto all'istanza Writer DB del tuo cluster Aurora PostgreSQL DB monitorando la metrica Amazon. CloudWatch ReplicaLag Poiché le repliche di Aurora eseguono la lettura dallo stesso volume del cluster dell'istanza database di scrittura, il parametro ReplicaLag assume un significato diverso per un cluster di database Aurora PostgreSQL. Il parametro ReplicaLag per una replica Aurora indica il ritardo per la cache di pagina della replica Aurora rispetto a quello dell'istanza database di scrittura.
Per ulteriori informazioni sul monitoraggio delle istanze e dei parametri RDS, consulta. CloudWatch Monitoraggio dei parametri in un cluster di database Amazon Aurora
