Utilizzo delle repliche di lettura per Amazon RDS for Postgre SQL - Amazon Relational Database Service
Decodifica logica su una replica di letturaLeggi le limitazioni delle repliche con Postgre SQLLeggi la configurazione della replica con Postgre SQLUso di repliche di lettura a cascataCreazione di repliche di lettura a cascata su più regioniCome funziona la replica per diverse versioni di Postgre RDS SQLMonitoraggio e ottimizzazione del processo di replicaRisoluzione dei problemi relativi alla replica di lettura RDS Postgre 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 delle repliche di lettura per Amazon RDS for Postgre SQL

Puoi scalare le letture per le tue istanze Amazon RDS for Postgree SQL DB aggiungendo repliche di lettura alle istanze. Come con altri motori di RDS database Amazon, RDS per Postgre SQL utilizza meccanismi di replica nativi di Postgre SQL per mantenere le repliche di lettura aggiornate con le modifiche sul DB di origine. Per informazioni generali sulle repliche di lettura e AmazonRDS, consultaUso delle repliche di lettura dell'istanza database.

Di seguito, puoi trovare informazioni specifiche sull'utilizzo delle repliche di lettura con RDS for Postgre. SQL

Decodifica logica su una replica di lettura

RDSper Postgree SQL supporta la replica logica dagli standby con Postgree 16.1. SQL Ciò consente di creare una decodifica logica da uno standby di sola lettura che riduce il carico sull'istanza DB principale. È possibile ottenere una maggiore disponibilità per le applicazioni che devono sincronizzare i dati su più sistemi. Questa funzionalità migliora le prestazioni del data warehouse e dell'analisi dei dati.

Inoltre, gli slot di replica su un determinato standby mantengono la promozione di tale standby a principale. Ciò significa che, in caso di failover di un'istanza DB primaria o di promozione di un'istanza di standby come nuova istanza principale, gli slot di replica persisteranno e i precedenti abbonati in standby non ne risentiranno.

Per creare una decodifica logica su una replica di lettura

  1. Attiva la replica logica: per creare la decodifica logica in standby, è necessario attivare la replica logica sull'istanza DB di origine e sulla relativa replica fisica. Per ulteriori informazioni, consulta Leggi la configurazione della replica con Postgre SQL.

    • Per attivare la replica logica per un'istanza SQL DB di Postgre appena creataRDS: crea un nuovo gruppo di parametri DB personalizzato e imposta il parametro statico su. rds.logical_replication 1 Quindi, associa questo gruppo di parametri DB all'istanza DB di origine e alla sua replica fisica di lettura. Per ulteriori informazioni, consulta Associazione di un gruppo di parametri DB a un'istanza DB in Amazon RDS .

    • Per attivare la replica logica per un'istanza SQL DB esistente RDS di Postgre: modifica il gruppo di parametri DB personalizzati dell'istanza DB di origine e la relativa replica di lettura fisica su cui impostare il parametro statico. rds.logical_replication 1 Per ulteriori informazioni, consulta Modifica dei parametri in un gruppo di parametri DB in Amazon RDS .

    Nota

    È necessario riavviare l'istanza DB per applicare queste modifiche ai parametri.

    È possibile utilizzare la seguente query per verificare i valori per wal_level e rds.logical_replication sull'istanza DB di origine e la relativa replica fisica di lettura.

    Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
            
 name                    | setting 
-------------------------+---------
 rds.logical_replication | on
 wal_level               | logical
(2 rows)

  2. Crea una tabella nel database di origine: connettiti al database nell'istanza DB di origine. Per ulteriori informazioni, consulta Connessione a un'istanza DB che esegue il motore di database Postgre SQL.

    Utilizzate le seguenti query per creare una tabella nel database di origine e inserire valori: 

    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
    Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000

  3. Crea una pubblicazione per la tabella di origine: utilizza la seguente query per creare una pubblicazione per la tabella sull'istanza DB di origine.

    Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION

    Utilizza una SELECT query per verificare i dettagli della pubblicazione creata sia sull'istanza DB di origine che sull'istanza fisica di replica di lettura.

    Postgres=>SELECT * from pg_publication;
             
oid    | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
 16429 | testpub |    16413 | f            | t         | t         | t         | t           | f
(1 row)

  4. Crea una sottoscrizione da un'istanza di replica logica: creane un'altra istanza RDS per Postgre SQL DB come istanza di replica logica. Assicurati che VPC sia configurata correttamente per garantire che questa istanza di replica logica possa accedere all'istanza di replica fisica di lettura. Per ulteriori informazioni, consulta Amazon VPC e Amazon RDS Amazon. Se l'istanza DB di origine è inattiva, potrebbero verificarsi problemi di connettività e l'istanza primaria non invia i dati in standby.

    Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port 
                dbname=source_db_name user=user password=password PUBLICATION testpub;
NOTICE:  created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE

    Utilizza una SELECT query per verificare i dettagli dell'abbonamento sull'istanza di replica logica.

    Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
            
oid    | subname | subenabled | subslotname | subpublications 
-------+---------+------------+-------------+-----------------
 16429 | testsub | t          | testsub     | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
 count 
-------
 10000
(1 row)

  5. Controlla lo stato dello slot di replica logica: puoi vedere solo lo slot di replica fisica sull'istanza DB di origine.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name                                    | slot_type | confirmed_flush_lsn 
---------------------------------------------+-----------+---------------------
 rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical  | 
(1 row)

    Tuttavia, sull'istanza di replica di lettura, è possibile vedere lo slot di replica logica e il confirmed_flush_lsn valore cambia man mano che l'applicazione utilizza attivamente le modifiche logiche.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/500002F0
(1 row)
    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/5413F5C0
(1 row)

Leggi le limitazioni della replica con Postgre SQL

Le seguenti sono le limitazioni per le repliche di lettura di SQL Postgre:

Nota

Una replica di lettura RDS per un'istanza DB Postgre SQL Multi-AZ e Single-AZ che esegue Postgre SQL versione 12 e precedenti, si riavvia automaticamente per applicare la rotazione della password durante la finestra di manutenzione da 60 a 90 giorni. Se la connessione dalla replica alla sorgente si interrompe prima del riavvio pianificato, l'istanza verrà comunque riavviata per la ripresa della replica.

  • Le repliche di lettura Postgree sono di sola lettura. SQL Sebbene una replica di lettura non sia un'istanza DB scrivibile, puoi promuoverla in modo che diventi un'istanza database autonoma per Postgre. RDS SQL Tuttavia, il processo non è reversibile.

  • Non puoi creare una replica di lettura da un'altra replica di lettura se l'istanza SQL DB RDS per Postgre esegue una versione di Postgre precedente alla 14.1. SQL RDSfor Postgre SQL supporta repliche di lettura a cascata solo per la versione 14.1 e successive di Postgre. RDS SQL Per ulteriori informazioni, consulta Utilizzo di repliche di lettura a cascata con for Postgree RDS SQL.

  • Se promuovi una replica di lettura di Postgre, questa diventa un'istanza DB scrivibile. SQL Smette di ricevere file write-ahead log (WAL) da un'istanza DB di origine e non è più un'istanza di sola lettura. È possibile creare nuove repliche di lettura dall'istanza DB promossa come si fa per qualsiasi RDS istanza DB di Postgre. SQL Per ulteriori informazioni, consulta Promozione di una replica di lettura a istanza database standalone.

  • Se promuovi una replica di SQL lettura Postgre dall'interno di una catena di replica (una serie di repliche di lettura a cascata), tutte le repliche di lettura a valle esistenti continuano a ricevere automaticamente i file dall'istanza promossa. WAL Per ulteriori informazioni, consulta Utilizzo di repliche di lettura a cascata con for Postgree RDS SQL.

  • Se non è in esecuzione alcuna transazione utente sull'istanza DB di origine, la replica di SQL lettura Postgre associata riporta un ritardo di replica fino a cinque minuti. Il ritardo di replica viene calcolato come currentTime - lastCommitedTransactionTimestamp segue: ciò significa che quando non viene elaborata alcuna transazione, il valore del ritardo di replica aumenta per un periodo di tempo fino a quando il segmento write-ahead log () cambia. WAL RDSPer impostazione predefinita, Postgre SQL cambia WAL segmento ogni 5 minuti, il che si traduce in un record di transazioni e in una diminuzione del ritardo riportato.

  • Non puoi attivare i backup automatici per le repliche di SQL lettura di Postgre per le versioni di Postgre precedenti alla 14.1. RDS SQL I backup automatici per le repliche di lettura sono supportati solo per Postgre 14.1 e versioni successive. RDS SQL RDSPer Postgre SQL 13 e versioni precedenti, crea un'istantanea da una replica di lettura se desideri farne un backup.

  • P oint-in-time recovery (PITR) non è supportato per le repliche di lettura. È possibile utilizzarlo solo PITR con un'istanza primaria (writer), non con una replica di lettura. Per ulteriori informazioni, consulta Ripristino a un'ora specifica per un'istanza database.

Leggi la configurazione della replica con Postgre SQL

RDSper Postgre SQL utilizza la replica in streaming SQL nativa di Postgre per creare una copia di sola lettura di un'istanza DB di origine. Questa istanza database di replica di lettura è una replica fisica creata in modo asincrono dell'istanza database di origine. Viene creato da una connessione speciale che trasmette i dati write ahead log (WAL) dall'istanza DB di origine alla replica di lettura. Per ulteriori informazioni, consulta Streaming Replication nella documentazione di Postgre. SQL

Postgre trasmette in modo SQL asincrono le modifiche al database su questa connessione sicura man mano che vengono apportate sull'istanza DB di origine. È possibile crittografare le comunicazioni dalle applicazioni client all'istanza database di origine o a qualsiasi replica di lettura impostando il parametro ssl su 1. Per ulteriori informazioni, consulta Utilizzo SSL con un'istanza DB Postgres SQL.

Postgre SQL utilizza un ruolo di replica per eseguire la replica in streaming. Il ruolo presenta dei privilegi ma non può essere utilizzato per modificare i dati. Postgre SQL utilizza un unico processo per gestire la replica.

È possibile creare una replica di SQL lettura di Postgre senza influire sulle operazioni o sugli utenti dell'istanza DB di origine. Amazon RDS imposta i parametri e le autorizzazioni necessari per te, sull'istanza DB di origine e sulla replica di lettura, senza influire sul servizio. Viene acquisito uno snapshot dell'istanza database di origine e tale snapshot viene utilizzato per creare la replica di lettura. Se si elimina la replica di lettura in un secondo momento, non si verificherà alcuna interruzione.

È possibile creare fino a 15 repliche di lettura da un'istanza database di origine nella stessa regione. A partire da Postgre SQL 14.1, puoi anche creare fino a tre livelli di replica di lettura in una catena (a cascata) da un'istanza DB di origine. RDS Per ulteriori informazioni, consulta Utilizzo di repliche di lettura a cascata con for Postgree RDS SQL. In ogni caso, l'istanza database di origine deve disporre di backup automatici configurati. A questo scopo, imposta il periodo di conservazione del backup sull'istanza database su un valore diverso da zero. Per ulteriori informazioni, consulta Creazione di una replica di lettura.

È possibile creare repliche di lettura RDS per l'istanza DB di Postgre nella stessa istanza SQL DB di origine. Regione AWS Questo processo è noto come replica nella regione. Puoi anche creare repliche di lettura in un'istanza DB Regioni AWS diversa dall'istanza DB di origine. Questo processo è noto come replica tra regioni. Per informazioni sull'impostazione delle repliche di lettura tra regioni, consulta Creazione di una replica di lettura in un altro Regione AWS. I vari meccanismi che supportano il processo di replica per In-region e Interregion differiscono leggermente a seconda della versione RDS per SQL Postgre, come spiegato in. Come funziona la replica in streaming RDS per diverse versioni di Postgre SQL

Per un efficace funzionamento della replica, ciascuna replica di lettura dovrebbe avere la stessa quantità di risorse di calcolo e storage dell'istanza database di origine. Se si dimensiona l'istanza database di origine, verifica di dimensionare anche le repliche di lettura.

Amazon RDS sovrascrive qualsiasi parametro incompatibile su una replica di lettura se impedisce l'avvio della replica di lettura. Ad esempio, supponiamo che il valore del parametro max_connections sull'istanza database di origine sia superiore a quello sulla replica di lettura. In tal caso, Amazon RDS aggiorna il parametro sulla replica di lettura in modo che corrisponda allo stesso valore dell'istanza DB di origine.

RDSper Postgre SQL le repliche di lettura hanno accesso a database esterni disponibili tramite data wrapper esterni (FDWs) sull'istanza DB di origine. Ad esempio, supponiamo che l'istanza SQL DB RDS for Postgre utilizzi il wrapper per accedere ai dati di for My. mysql_fdw RDS SQL In questo caso, anche le repliche di lettura possono accedere a tali dati. Altre opzioni supportate FDWs includono, e. oracle_fdw postgres_fdw tds_fdw Per ulteriori informazioni, consulta Utilizzo dei wrapper di dati esterni supportati per .

Utilizzo di repliche di SQL lettura RDS per Postgre con configurazioni Multi-AZ

È possibile creare una replica di lettura da un’istanza database Single-AZ o Multi-AZ. Puoi usare implementazioni Multi-AZ per migliorare la durabilità e la disponibilità di dati critici con una replica in standby. Una replica in standby è una replica di lettura dedicata che può assumere il carico di lavoro se si verifica il failover del database di origine. Non è possibile utilizzare una replica in standby per gestire il traffico di lettura. Puoi tuttavia creare repliche di lettura da istanze database Multi-AZ con traffico elevato per l'offload di query di sola lettura. Per ulteriori informazioni sulle implementazioni Multi-AZ, consultare Implementazioni dell'istanza database Multi-AZ.

Se viene eseguito il failover dell'istanza database di origine di un'implementazione Multi-AZ sull'istanza in standby, tutte le repliche di lettura associate passeranno a usare l'istanza in standby (ora primaria) come origine della replica. Potrebbe essere necessario riavviare le repliche di lettura, a seconda della versione RDS per Postgre, come segue: SQL

  • Postgre SQL 13 e versioni successive: il riavvio non è richiesto. Le repliche di lettura vengono automaticamente sincronizzate con il nuovo database primario. Tuttavia, in alcuni casi l'applicazione client potrebbe memorizzare nella cache i dettagli di Domain Name Service (DNS) per le repliche di lettura. In tal caso, impostate il valore time-to-live (TTL) su un valore inferiore a 30 secondi. In questo modo si impedisce alla replica di lettura di mantenere un indirizzo IP obsoleto e pertanto si impedisce la sincronizzazione con il nuovo database primario. Per ulteriori informazioni su questa e altre best practice, consulta Linee guida operative RDS di base di Amazon.

  • Postgre SQL 12 e tutte le versioni precedenti: le repliche di lettura si riavviano automaticamente dopo un failover sulla replica di standby perché la replica in standby (ora principale) ha un indirizzo IP diverso e un nome di istanza diverso. Il riavvio sincronizza la replica di lettura con il nuovo database primario.

Per ulteriori informazioni sul failover, consulta Processo di failover per Amazon RDS. Per ulteriori informazioni su come le repliche di lettura funzionano in una implementazione Multi-AZ, consultare Uso delle repliche di lettura dell'istanza database.

Per fornire il supporto di failover per una replica di lettura, puoi creare la replica di lettura come istanza DB Multi-AZ in modo che Amazon RDS crei uno standby della tua replica in un'altra zona di disponibilità (AZ). La creazione della replica di lettura come un'istanza database Multi-AZ non dipende dal fatto che il database di origine sia un'istanza database Multi-AZ.

Utilizzo di repliche di lettura a cascata con for Postgree RDS SQL

A partire dalla versione 14.1, RDS per Postgre supporta le repliche di lettura a cascata. SQL Con le repliche di lettura a cascata, puoi scalare le letture senza aggiungere costi aggiuntivi all'istanza database di origine per Postgre. RDS SQL Gli aggiornamenti al WAL registro non vengono inviati dall'istanza DB di origine a ciascuna replica di lettura. Al contrario, ogni replica di lettura di una serie a cascata invia gli aggiornamenti del WAL registro alla replica di lettura successiva della serie. Questo riduce il carico sull'istanza database di origine.

Con le repliche di lettura a cascata, l'istanza SQL DB RDS for Postgre invia i WAL dati alla prima replica di lettura della catena. Quella replica di lettura invia quindi WAL i dati alla seconda replica della catena e così via. Il risultato finale è che tutte le repliche di lettura della catena presentano le modifiche rispetto all'istanza DB RDS for Postgre, ma senza il sovraccarico che grava esclusivamente sull'istanza SQL DB di origine.

È possibile creare una serie di un massimo di tre repliche di lettura in una catena da un'istanza database di origine RDS per Postgre. SQL Ad esempio, supponiamo di avere un'istanza DB RDS per SQL Postgre 14.1,. rpg-db-main Puoi eseguire le operazioni indicate di seguito:

  • A partire da rpg-db-main, crea la prima replica di lettura nella catena, read-replica-1.

  • Da read-replica-1, crea quindi la successiva replica di lettura nella catena, read-replica-2.

  • Da read-replica-2, crea infine la terza replica di lettura nella catena, read-replica-3.

Non è possibile creare un'altra replica di lettura oltre la terza replica di lettura a cascata nella serie per rpg-db-main. Una serie completa di istanze, da un'istanza DB di SQL origine RDS per Postgre fino alla fine di una serie di repliche di lettura a cascata, può essere composta da un massimo di quattro istanze DB.

Affinché le repliche di lettura a cascata funzionino, attiva i backup automatici su Postgre. RDS SQL Crea prima la replica di lettura e poi attiva i backup automatici sull'istanza DB per Postgre. RDS SQL Il processo è lo stesso degli altri motori Amazon RDS DB. Per ulteriori informazioni, consulta Creazione di una replica di lettura.

Come per qualsiasi replica di lettura, puoi promuovere una replica di lettura appartenente a una cascata. La promozione di una replica di lettura all'interno di una catena di repliche di lettura rimuove la replica dalla catena. Ad esempio, supponiamo che tu voglia spostare parte del carico di lavoro fuori dall'istanza database rpg-db-main in una nuova istanza usata solo dal reparto contabile. Facendo riferimento alla catena di tre repliche di lettura dell'esempio, decidi di promuovere read-replica-2. La catena verrà modificata come segue:

  • La promozione read-replica-2 rimuove l'istanza dalla catena di replica.

    • Ora è un'istanza database completa di lettura/scrittura.

    • Continua a replicare su read-replica-3, proprio come prima della promozione.

  • L'istanza rpg-db-main continua a venire replicata su read-replica-1.

Per ulteriori informazioni sulla promozione delle repliche di lettura, consulta Promozione di una replica di lettura a istanza database standalone.

Nota

Per le repliche di lettura a cascata, RDS per Postgre SQL supporta 15 repliche di lettura per ogni istanza DB di origine al primo livello di replica e 5 repliche di lettura per ogni istanza DB di origine al secondo e terzo livello di replica.

Creazione di repliche di lettura a cascata su più regioni con for RDS Postgre SQL

RDSfor Postgre supporta repliche di lettura a cascata tra regioni diverseSQL. È possibile creare una replica interregionale dall'istanza DB di origine e quindi creare repliche nella stessa area. È inoltre possibile creare una replica nella stessa area dall'istanza DB di origine e quindi creare repliche interregionali da essa.

Crea una replica interregionale e quindi crea repliche nella stessa area

Puoi utilizzare un'istanza di Postgree SQL DB con versione 14.1 o successiva RDS per effettuare le seguenti operazioni: rpg-db-main

  1. Inizia con rpg-db-main (US- EAST -1), crea la prima replica di lettura interregionale della catena, read-replica-1 (US- -2). WEST

  2. Utilizzando la prima replica interregionale read-replica-1 (US- WEST -2), create la seconda replica letta nella catena, read-replica-2 (US- -2). WEST

  3. Utilizzandoread-replica-2, create la terza replica letta nella catena, read-replica-3 (US- WEST -2).

Crea una replica nella stessa regione e quindi crea repliche tra regioni

Puoi utilizzare un'istanza di Postgree SQL DB con versione 14.1 o successiva RDS per effettuare le seguenti operazioni: rpg-db-main

  1. A partire da rpg-db-main (US- EAST -1), create la prima replica letta nella catena, read-replica-1 (US- -1). EAST

  2. Utilizzando read-replica-1 (US- EAST -1), create la prima replica di lettura interregionale della catena, read-replica-2 (US- WEST -2).

  3. Utilizzando read-replica-2 (US- WEST -2), create la terza replica letta nella catena, read-replica-3 (US- WEST -2).

Limitazioni nella creazione di repliche di lettura tra regioni

  • Una catena di repliche di database a cascata tra regioni può estendersi su un massimo di due regioni, con un massimo di quattro livelli. I quattro livelli includono l'origine del database e tre repliche di lettura.

Vantaggi dell'utilizzo di repliche di lettura a cascata

  • Migliore scalabilità di lettura: distribuendo le query di lettura su più repliche, la replica a cascata aiuta a bilanciare il carico. Ciò migliora le prestazioni, specialmente nelle applicazioni che richiedono molta lettura, riducendo il carico sul database di Writer.

  • Distribuzione geografica: le repliche a cascata possono essere collocate in diverse località geografiche. Ciò riduce la latenza per gli utenti che si trovano lontano dal database principale e fornisce una replica di lettura locale, migliorando le prestazioni e l'esperienza utente.

  • Alta disponibilità e disaster recovery: in caso di guasto del server principale, le repliche possono essere promosse a primarie, garantendo la continuità. La replica in cascata migliora ulteriormente questa situazione fornendo più livelli di opzioni di failover e migliorando la resilienza complessiva del sistema.

  • Flessibilità e crescita modulare: man mano che il sistema cresce, è possibile aggiungere nuove repliche a diversi livelli senza una riconfigurazione importante del database primario. Questo approccio modulare consente una crescita scalabile e gestibile della configurazione di replica.

Per ulteriori informazioni sui vantaggi dell'utilizzo della replica, consulta Informazioni sulla replica nel cloud. SQL

Procedura consigliata per l'utilizzo di repliche di lettura in più regioni

  • Prima di promuovere una replica, crea repliche aggiuntive. Ciò consentirà di risparmiare tempo e di gestire in modo efficiente il carico di lavoro.

Come funziona la replica in streaming RDS per diverse versioni di Postgre SQL

Come discusso in precedenzaLeggi la configurazione della replica con Postgre SQL, RDS per Postgre SQL utilizza il protocollo di replica in streaming nativo SQL di Postgre per inviare dati dall'istanza DB di origine. WAL Invia WAL i dati di origine alle repliche di lettura sia per le repliche di lettura interne che per quelle interregionali. Con la versione 9.4, Postgre SQL ha introdotto gli slot di replica fisica come meccanismo di supporto per il processo di replica.

Uno slot di replica fisico impedisce a un'istanza DB di origine di rimuovere WAL i dati prima che vengano utilizzati da tutte le repliche di lettura. Ogni replica di lettura ha un proprio slot fisico sull'istanza database di origine. Lo slot tiene traccia degli elementi più vecchi WAL (in base al numero di sequenza logicaLSN) che potrebbero essere necessari alla replica. Dopo che tutti gli slot e le connessioni DB sono andati oltre un determinato limite WAL (LSN), questo LSN elemento può essere rimosso al checkpoint successivo.

Amazon RDS utilizza Amazon S3 per archiviare i datiWAL. Per le repliche di lettura nella regione, è possibile utilizzare questi dati archiviati per recuperare la replica di lettura quando necessario. Un esempio di quando è possibile farlo è se la connessione tra database di origine e replica di lettura viene interrotta per qualsiasi motivo.

Nella tabella seguente, puoi trovare un riepilogo delle differenze tra le SQL versioni di Postgre e i meccanismi di supporto per In-region e Interregion utilizzati da per Postgre. RDS SQL

Versione Nella regione Tra regioni
Postgre 14.1 e versioni successive SQL

  • Slot di replica

  • Archivio Amazon S3

  • Slot di replica
SQLPostgre 13 e versioni precedenti

  • Archivio Amazon S3

  • Slot di replica

Per ulteriori informazioni, consulta Monitoraggio e ottimizzazione del processo di replica.

Comprensione dei parametri che controllano la replica di Postgre SQL

I seguenti parametri influenzano il processo di replica e determinano il modo in cui le repliche di lettura restano aggiornate con l'istanza database di origine:

max_wal_senders

Il parametro max_wal_senders specifica il numero massimo di connessioni che l'istanza database di origine può supportare contemporaneamente sul protocollo di replica in streaming. L'impostazione predefinita RDS per Postgre SQL 13 e versioni successive è 20. Questo parametro deve essere impostato su un valore leggermente più alto del numero effettivo di repliche di lettura. Se questo parametro è impostato su un valore troppo basso per il numero di repliche di lettura, la replica viene interrotta.

Per maggiori informazioni, consulta max_wal_senders nella documentazione di Postgre. SQL

wal_keep_segments

Il wal_keep_segments parametro specifica il numero di file write-ahead log (WAL) che l'istanza DB di origine conserva nella directory. pg_wal L'impostazione predefinita è 32.

Se il parametro wal_keep_segments non è impostato su un valore abbastanza grande per l'implementazione, una replica di lettura può avere un ritardo tale che la replica di streaming si arresta. In tal caso, Amazon RDS genera un errore di replica e avvia il ripristino sulla replica di lettura. Lo fa riproducendo i WAL dati archiviati dell'istanza DB di origine da Amazon S3. Il processo di ripristino continua finché la replica di lettura non avrà recuperato abbastanza per continuare la replica di streaming. Puoi vedere questo processo in azione così come registrato dal login di SQL Postgre. Esempio: come ripristinare una replica di lettura dalle interruzioni della replica

Nota

Nella SQL versione 13 di Postgre, il wal_keep_segments parametro è denominato. wal_keep_size Ha lo stesso scopo di wal_keep_segments, ma il suo valore predefinito è espresso in megabyte (MB) (2048 MB) anziché in numero di file. Per ulteriori informazioni, consulta wal_keep_segments e wal_keep_size nella documentazione di Postgre. SQL

max_slot_wal_keep_size

Il max_slot_wal_keep_size parametro controlla la quantità di WAL dati che l'istanza DB for Postgre conserva nella directory RDS per servire gli slot. SQL pg_wal Questo parametro viene utilizzato per le configurazioni che utilizzano gli slot di replica. Il valore predefinito per questo parametro è-1, il che significa che non c'è limite alla quantità di WAL dati conservati nell'istanza DB di origine. Per informazioni sul monitoraggio degli slot di replica, consulta Monitoraggio degli slot di replica RDS per l'istanza DB di SQL Postgre.

Per ulteriori informazioni su questo parametro, consulta max_slot_wal_keep_size nella documentazione di Postgre. SQL

Ogni volta che lo stream che fornisce WAL dati a una replica di lettura viene interrotto, Postgre passa alla modalità di ripristino. SQL Ripristina la replica di lettura utilizzando WAL i dati archiviati da Amazon S3 o utilizzando i WAL dati associati allo slot di replica. Una volta completato questo processo, Postgre ristabilisce la replica in streaming. SQL

Esempio: come ripristinare una replica di lettura dalle interruzioni della replica

Nell'esempio seguente sono disponibili i dettagli del registro che dimostrano il processo di ripristino per una replica di lettura. L'esempio proviene da un'istanza SQL DB RDS per Postgre che esegue la SQL versione 12.9 di Postgre nello stesso database di origine, quindi gli slot di replica Regione AWS non vengono utilizzati. Il processo di ripristino è lo stesso per le altre RDS istanze SQL DB Postgre che eseguono Postgre precedenti alla versione 14.1 con repliche di lettura interne alla regioneSQL.

Quando la replica letta perde il contatto con l'istanza DB di origine, Amazon RDS registra il problema nel log come FATAL: could not receive data from WAL stream messaggio, insieme a. ERROR: requested WAL segment ... has already been removed Come mostrato nella riga in grassetto, Amazon RDS recupera la replica riproducendo un file archiviato. WAL 

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Quando Amazon RDS riproduce sulla replica una quantità sufficiente di WAL dati archiviati da recuperare il ritardo, lo streaming verso la replica di lettura ricomincia. Quando lo streaming riprende, Amazon RDS scrive una voce nel file di registro simile alla seguente.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

Impostazioni dei parametri di controllo della memoria condivisa

I parametri impostati determinano la dimensione della memoria condivisa per tracciare le transazioniIDs, i blocchi e le transazioni preparate. La struttura della memoria condivisa di un'istanza in standby deve essere uguale o superiore a quella di un'istanza primaria. Ciò garantisce che la prima non esaurisca la memoria condivisa durante il ripristino. Se i valori dei parametri sulla replica sono inferiori ai valori dei parametri sulla replica principale, Amazon RDS regolerà automaticamente i parametri della replica e riavvierà il motore.

I parametri interessati sono:

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Per evitare il RDS riavvio delle repliche a causa di memoria insufficiente, consigliamo di applicare le modifiche ai parametri come riavvio progressivo a ciascuna replica. È necessario applicare le seguenti regole quando si impostano i parametri:

  • Aumento dei valori dei parametri:

    • È sempre necessario aumentare prima i valori dei parametri di tutte le repliche di lettura ed eseguire un riavvio in sequenza di tutte le repliche. Quindi, applica le modifiche ai parametri sull'istanza primaria ed esegui un riavvio.

  • Riduzione dei valori dei parametri:

    • È innanzitutto necessario ridurre i valori dei parametri dell'istanza primaria ed eseguire un riavvio. Quindi, applica le modifiche ai parametri a tutte le repliche di lettura associate ed esegui un riavvio in sequenza.

Monitoraggio e ottimizzazione del processo di replica

Si consiglia vivamente di monitorare regolarmente l'istanza di For Postgre DB e di leggere RDS le replicheSQL. È necessario assicurarsi che le repliche di lettura siano aggiornate in base alle modifiche dell'istanza database di origine. Amazon recupera RDS in modo trasparente le repliche di lettura quando si verificano interruzioni del processo di replica. Tuttavia, è meglio evitare il ripristino. Il ripristino tramite slot di replica è più rapido rispetto all'utilizzo dell'archivio Amazon S3, ma qualsiasi processo di ripristino può influire sulle prestazioni di lettura.

Per determinare la qualità dell'aggiornamento delle repliche di lettura in base all'istanza database di origine, è possibile effettuare le seguenti operazioni:

  • Verifica valore di ReplicaLag tra istanza database di origine e repliche. Il valore del ritardo di replica si riferisce al tempo di ritardo di una replica di lettura, in secondi, rispetto all'istanza database di origine. Questo parametro indica il risultato della query seguente.

    SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";

    Il ritardo di replica è un'indicazione della velocità con cui una replica di lettura rimane al passo con l'istanza database di origine. È il valore della latenza tra l'istanza database di origine e un'istanza di lettura specifica. Un valore elevato del ritardo di replica può indicare una mancata corrispondenza tra le classi di istanza database o i tipi di archiviazione (o entrambi) utilizzati dall'istanza database di origine e le relative repliche di lettura. La classe di istanza database, i tipi di archiviazione per l'istanza database di origine e tutte le repliche di lettura devono essere uguali.

    Il ritardo della replica può anche essere il risultato di problemi di connessione non stabile. Puoi monitorare il ritardo di replica in Amazon CloudWatch visualizzando la metrica Amazon RDSReplicaLag. Per ulteriori informazioni ReplicaLag e altre metriche relative ad AmazonRDS, consulta CloudWatch Metriche Amazon per Amazon RDS.

  • Controlla il SQL registro di Postgre per informazioni che puoi utilizzare per modificare le impostazioni. Ad ogni checkpoint, il registro Postgre acquisisce il numero di file di SQL registro delle transazioni riciclati, come mostrato nell'esempio seguente.

    2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s

    Puoi utilizzare queste informazioni per capire quanti file di transazione verranno riciclati in un determinato periodo di tempo. Puoi modificare l'impostazione del parametro wal_keep_segments, se necessario. Ad esempio, supponiamo che il log di Postgre SQL venga visualizzato per un intervallo di 5 minuti. checkpoint complete 35 recycled In questo caso, il valore predefinito 32 del parametro wal_keep_segments non è sufficiente per tenere il passo con l'attività di streaming e pertanto è consigliabile aumentare il valore di questo parametro.

  • Usa Amazon CloudWatch per monitorare i parametri in grado di prevedere i problemi di replica. Invece di analizzare direttamente il SQL log di Postgre, puoi utilizzare Amazon CloudWatch per controllare le metriche che sono state raccolte. Ad esempio, puoi controllare il valore della TransactionLogsGeneration metrica per vedere quanti WAL dati vengono generati dall'istanza DB di origine. In alcuni casi, il carico di lavoro sull'istanza DB potrebbe generare una grande quantità di WAL dati. In questo caso, potrebbe essere necessario modificare la classe di istanza database per l'istanza database di origine e delle repliche di lettura. L'utilizzo di una classe di istanza con prestazioni di rete elevate (10 Gb/s) può ridurre il ritardo delle repliche.

Monitoraggio degli slot di replica RDS per l'istanza DB di SQL Postgre

Tutte le versioni di RDS for Postgre SQL utilizzano slot di replica per repliche di lettura interregionali. RDSper Postgre SQL 14.1 e versioni successive utilizzano gli slot di replica per le repliche di lettura all'interno della regione. Le repliche di lettura locali utilizzano anche Amazon S3 per archiviare i dati. WAL In altre parole, se l'istanza DB e le repliche di lettura eseguono Postgre SQL 14.1 o versioni successive, gli slot di replica e gli archivi Amazon S3 sono entrambi disponibili per il ripristino della replica di lettura. Il ripristino di una replica di lettura utilizzando lo slot di replica è più veloce del ripristino dall'archivio Amazon S3. Pertanto, ti consigliamo di monitorare gli slot di replica e i relativi parametri.

Puoi visualizzare gli slot di replica sulle tue istanze DB RDS per SQL Postgre interrogando la vista, come segue. pg_replication_slots

postgres=> SELECT * FROM pg_replication_slots;
slot_name                  | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 |        | physical  |        |          | f         | t      |      13194 |      |              | 23/D8000060 |                     | reserved   |               | f
(1 row)

Il reserved valore wal_status of indica che la quantità di WAL dati contenuta nello slot rientra nei limiti del parametro. max_wal_size In altre parole, lo slot di replica è dimensionato correttamente. I valori di stato possibili sono i seguenti:

  • extended— Lo slot supera l'max_wal_sizeimpostazione, ma i WAL dati vengono conservati.

  • unreserved— Lo slot non contiene più tutti i dati richiesti. WAL Alcuni di essi verranno rimossi al prossimo checkpoint.

  • lost— Alcuni WAL dati richiesti sono stati rimossi. Lo slot non è più utilizzabile.

lostGli stati unreserved e di wal_status vengono visualizzati solo quando non max_slot_wal_keep_size è negativo.

La vista pg_replication_slots mostra lo stato corrente degli slot di replica. Per valutare le prestazioni dei tuoi slot di replica, puoi utilizzare Amazon CloudWatch e monitorare i seguenti parametri:

  • OldestReplicationSlotLag: elenca la replica con il ritardo più elevato, cioè è più distante rispetto al database primario. Questo ritardo può essere dovuto alla replica di lettura ma anche alla connessione.

  • TransactionLogsDiskUsage— Mostra la quantità di storage utilizzata per i WAL dati. Quando una replica di lettura è in ritardo significativo, il valore di questo parametro può aumentare notevolmente.

Per ulteriori informazioni sull'utilizzo di Amazon CloudWatch e dei relativi parametri RDS per PostgreSQL, consulta. Monitoraggio dei parametri di RDSAmazon con Amazon CloudWatch Per ulteriori informazioni sul monitoraggio della replica in streaming sulle tue istanze SQL DB RDS per Postgre, consulta le migliori pratiche per la replica di Amazon RDS Postgre SQL sul blog del database.AWS

RDSRisoluzione SQL dei problemi relativi alla replica di lettura di Postgre

Di seguito, puoi trovare idee per la risoluzione di alcuni problemi comuni relativi alla replica di lettura RDS di SQL Postgre.

Termina la query che causa il ritardo della replica di lettura

Le transazioni attive o inattive in stato di transazione che rimangono in esecuzione a lungo nel database potrebbero interferire con il processo di replica, aumentando così il ritardo di WAL replica. Pertanto, assicuratevi di monitorare l'esecuzione di queste transazioni con la visualizzazione Postgre. SQL pg_stat_activity

Eseguite una query sull'istanza principale simile alla seguente per trovare l'ID di processo (PID) della query in esecuzione da molto tempo: 


SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
                        
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,* 
FROM  pg_stat_activity 
WHERE state  = 'idle in transaction'
AND   xact_start is not null
ORDER BY 1 DESC;

Dopo aver identificato l'oggetto PID della query, potete scegliere di terminarla.

Esegui una query sull'istanza principale simile alla seguente per terminare la query in esecuzione da molto tempo:

SELECT pg_terminate_backend(PID);