Utilizzo delle repliche di lettura per Amazon RDS per PostgreSQL - Amazon Relational Database Service
Decodifica logica su una replica di letturaLimitazioni per le repliche di lettura con PostgreSQLConfigurazione delle repliche di lettura con PostgreSQLUso di repliche di lettura a cascataCreazione di repliche di lettura a cascata in più regioniFunzionamento della replica per diverse versioni di RDS per PostgreSQLMonitoraggio e ottimizzazione del processo di replicaRisoluzione dei problemi relativi alla replica di lettura RDS per PostgreSQL

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 per PostgreSQL

Puoi scalare le letture per le tue istanze DB Amazon RDS for PostgreSQL aggiungendo repliche di lettura alle istanze. Come altri motori di database Amazon RDS, RDS per PostgreSQL utilizza meccanismi di replica nativi di PostgreSQL per mantenere le repliche di lettura aggiornate in base alle modifiche sul DB di origine. Per informazioni generali sulle repliche di lettura e Amazon RDS, consulta Uso delle repliche di lettura dell'istanza database.

Questa sezione contiene informazioni specifiche sull'utilizzo delle repliche di lettura con RDS per PostgreSQL.

Decodifica logica su una replica di lettura

RDS per PostgreSQL supporta la replica logica dagli standby con PostgreSQL 16.1. 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 Configurazione delle repliche di lettura con PostgreSQL.

    • Per attivare la replica logica per un'istanza DB RDS for PostgreSQL appena creata, 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 relativa 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 DB RDS for PostgreSQL esistente: modifica il gruppo di parametri database 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 database che esegua il motore di database di PostgreSQL.

    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

    Utilizzate una query SELECT 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: crea un'altra istanza DB RDS per PostgreSQL come istanza di replica logica. Assicurati che il VPC sia configurato 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 query SELECT 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)

Limitazioni per le repliche di lettura con PostgreSQL

Di seguito sono elencate le limitazioni per le repliche di lettura PostgreSQL:

  • Le repliche di lettura PostgreSQL sono di sola lettura. Sebbene una replica di lettura non sia un'istanza database scrivibile, è possibile promuoverla a un'istanza database RDS per PostgreSQL autonoma. Tuttavia, il processo non è reversibile.

  • Non è possibile creare una replica di lettura da un'altra replica di lettura se l'istanza database RDS per PostgreSQL esegue una versione di PostgreSQL precedente alla 14.1. RDS per PostgreSQL supporta solo le repliche di lettura a cascata su RDS per PostgreSQL versione 14.1 e versioni successive. Per ulteriori informazioni, consulta Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL.

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

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

  • Se sull'istanza database di origine non sono in esecuzione transazioni utente, la replica di lettura PostgreSQL associata è caratterizzata da un ritardo di replica fino a cinque minuti. Il ritardo di replica viene calcolato come currentTime - lastCommitedTransactionTimestamp, il che 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 WAL (write-ahead log) cambia. Per impostazione predefinita, RDS per PostgreSQL cambia il segmento WAL ogni 5 minuti, il che comporta un record di transazione e una riduzione del ritardo segnalato.

  • Non è possibile attivare i backup automatici per le repliche di lettura PostgreSQL per le versioni precedenti alla 14.1 di RDS per PostgreSQL. I backup automatici per le repliche di lettura sono supportati solo per RDS per PostgreSQL 14.1 e versioni successive. Per RDS per PostgreSQL 13 e versioni precedenti, crea uno snapshot da una replica di lettura se si desidera creare un backup da tale snapshot.

  • Point-in-time il ripristino (PITR) non è supportato per le repliche di lettura. È possibile utilizzare ripristino point-in-time (PITR) solo con un'istanza primaria (istanza di scrittura), non con una replica di lettura. Per ulteriori informazioni, consulta Ripristino di un'istanza DB a un'ora specificata per Amazon RDS.

  • Leggi le repliche per le versioni 12 e precedenti di PostgreSQL, riavvia automaticamente durante la finestra di manutenzione di 60-90 giorni per applicare la rotazione delle password. Se la replica perde la connessione all'origine prima del riavvio pianificato, si riavvia comunque per riprendere la replica. Per le versioni 13 e successive di PostgreSQL, le repliche di lettura potrebbero subire brevi disconnessioni e riconnessioni di replica durante il processo di rotazione della password.

Configurazione delle repliche di lettura con PostgreSQL

RDS per PostgreSQL utilizza la replica di streaming nativa PostgreSQL per creare una copia di sola lettura di un'istanza database di origine. Questa istanza database di replica di lettura è una replica fisica creata in modo asincrono dell'istanza database di origine. Viene creata da una speciale connessione che trasmette i dati Write Ahead Log (WAL) dall'istanza database di origine alla replica di lettura. Per ulteriori informazioni, consulta la sezione relativa alla replica in streaming nella documentazione di PostgreSQL.

PostgreSQL trasmette in streaming in modo asincrono le modifiche al database a questa connessione sicura man mano che vengono effettuate sull'istanza database 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 del protocollo SSL con un'istanza database PostgreSQL.

PostgreSQL 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. PostgreSQL utilizza un unico processo per la gestione della replica.

È possibile creare una replica di lettura PostgreSQL senza alcun impatto sulle operazioni o sugli utenti dell'istanza database di origine. Amazon RDS imposta i parametri e le autorizzazioni necessari per l'istanza database di origine e la replica di lettura senza ripercussioni 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 RDS per PostgreSQL 14.1, è anche possibile creare fino a tre livelli di replica di lettura in una catena (cascata) da un'istanza database di origine. Per ulteriori informazioni, consulta Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL. 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 per l'istanza database RDS per PostgreSQL nella stessa Regione AWS dell'istanza database di origine. Questo processo è noto come replica nella regione. È inoltre possibile creare repliche di lettura in un'istanza DB diversa dall'istanza DB di origine. Regioni AWS 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 "in regione" e "tra regioni" variano leggermente a seconda della versione di RDS per PostgreSQL, come spiegato in Funzionamento della replica in streaming per diverse versioni di RDS per PostgreSQL.

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 sostituisce qualsiasi parametro incompatibile in una replica di lettura che impedisca 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 questo caso, Amazon RDS aggiorna il parametro sulla replica di lettura in modo che il valore coincida con quello sull'istanza database di origine.

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

Utilizzo di repliche di lettura di RDS per PostgreSQL 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 di istanze DB Multi-AZ per Amazon RDS.

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 PostgreSQL, come segue:

  • PostgreSQL 13 e versioni successive: il riavvio non è obbligatorio. 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 DNS (Domain Name Service) per le repliche di lettura. In tal caso, imposta 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 di base per Amazon RDS.

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

Per ulteriori informazioni sul failover, consulta Failover di un'istanza DB Multi-AZ 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 garantire il supporto del failover per una replica di lettura, puoi creare una replica di lettura come un'istanza database Multi-AZ. Amazon RDS crea una replica in standby della 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 RDS per PostgreSQL

A partire dalla versione 14.1, RDS per PostgreSQL supporta le repliche di lettura a cascata. Con le repliche di lettura a cascata, puoi dimensionare le letture senza aggiungere sovraccarico all'istanza database RDS per PostgreSQL di origine. Gli aggiornamenti del registro WAL non vengono inviati dall'istanza database di origine a ciascuna replica di lettura. Invece, ogni replica di lettura in una serie a cascata invia gli aggiornamenti del registro WAL alla successiva replica di lettura della serie. Questo riduce il carico sull'istanza database di origine.

Con le repliche di lettura a cascata, l'istanza database RDS per PostgreSQL invia i dati WAL alla prima replica di lettura della catena. La replica di lettura invia quindi i dati WAL alla seconda replica della catena e così via. Il risultato finale è che tutte le repliche di lettura nella catena includono le modifiche dall'istanza database RDS per PostgreSQL, ma senza sovraccaricare esclusivamente l'istanza database di origine.

È possibile creare una serie di fino a tre repliche di lettura in una catena da un'istanza database RDS per PostgreSQL di origine. Ad esempio, supponiamo di avere un'istanza database RDS per PostgreSQL 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 database RDS per PostgreSQL di origine fino alla fine di una serie di repliche di lettura a cascata può essere composta al massimo da quattro istanze database.

Affinché le repliche di lettura a cascata funzionino, attiva i backup automatici su RDS per PostgreSQL. Crea prima la replica di lettura e quindi attiva i backup automatici sull'istanza database RDS per PostgreSQL. Il processo è lo stesso valido per gli altri motori di database Amazon RDS. 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

  • RDS per PostgreSQL non supporta gli aggiornamenti delle versioni principali per le repliche a cascata. Prima di eseguire un aggiornamento della versione principale, è necessario rimuovere le repliche a cascata. È possibile ricrearle dopo aver completato l'aggiornamento sull'istanza DB di origine e sulle repliche di primo livello.

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

Creazione di repliche di lettura a cascata tra regioni diverse con RDS per PostgreSQL

RDS per PostgreSQL supporta repliche di lettura a cascata su più regioni. È possibile creare una replica interregionale dall'istanza DB di origine e quindi creare repliche della stessa regione da essa. È 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

È possibile utilizzare un'istanza DB RDS for PostgreSQL con versione 14.1 o successiva 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, (US-WEST-2). read-replica-1

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

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

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

È possibile utilizzare un'istanza DB RDS for PostgreSQL con versione 14.1 o successiva 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, (US-EAST-1). read-replica-1

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

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

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.

Procedura ottimale 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.

Funzionamento della replica in streaming per diverse versioni di RDS per PostgreSQL

Come illustrato in Configurazione delle repliche di lettura con PostgreSQL, RDS per PostgreSQL utilizza il protocollo di replica in streaming nativo di PostgreSQL per inviare dati WAL dall'istanza database di origine. Invia i dati WAL di origine per leggere le repliche sia per le repliche di lettura nella regione che tra regioni. Con la versione 9.4, PostgreSQL ha introdotto gli slot di replica fisica come meccanismo di supporto per il processo di replica.

Uno slot di replica fisica impedisce a un'istanza database di origine di rimuovere i dati WAL prima che vengano consumati da tutte le repliche di lettura. Ogni replica di lettura ha un proprio slot fisico sull'istanza database di origine. Lo slot tiene traccia dei dati WAL più vecchi (per numero di sequenza logica, LSN) che potrebbero essere necessari per la replica. Dopo che tutti gli slot e le connessioni di database sono progrediti oltre un determinato WAL (LSN), il numero di sequenza logica (LSN) diventa un candidato per la rimozione al checkpoint successivo.

Amazon RDS utilizza Amazon S3 per archiviare i dati WAL. 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 è possibile trovare un riepilogo delle differenze tra le versioni di PostgreSQL e i meccanismi di supporto per la replica nella regione e tra regioni utilizzata da RDS per PostgreSQL.

Versione Nella regione Tra regioni
PostgreSQL 14.1 e versioni successive

  • Slot di replica

  • Archivio Amazon S3

  • Slot di replica
PostgreSQL 13 e versioni precedenti

  • Archivio Amazon S3

  • Slot di replica

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

Informazioni sui parametri di controllo della replica PostgreSQL

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.

Il valore predefinito varia per le versioni di RDS per PostgreSQL:

  • Per le versioni 13, 14 e 15, il valore predefinito è 20.

  • Per le versioni 16 e successive, il valore predefinito è 35.

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 ulteriori informazioni, consulta la sezione relativa al parametro max_wal_senders nella documentazione di PostgreSQL.

Nota

max_wal_sendersè un parametro statico che richiede il riavvio dell'istanza DB per rendere effettive le modifiche.

wal_keep_segments

Il parametro wal_keep_segments specifica il numero di file WAL (write-ahead log) conservati dall'istanza database di origine 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 questo caso, Amazon RDS genera un errore di replica e inizia il ripristino sulla replica di lettura. A tale scopo, riproduce i dati WAL archiviati dell'istanza database 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. È possibile vedere questo processo in esecuzione come viene acquisito dal registro PostgreSQL in Esempio: come ripristinare una replica di lettura dalle interruzioni della replica.

Nota

In PostgreSQL versione 13, il parametro wal_keep_segments è 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 la sezione relativa ai parametri wal_keep_segments e wal_keep_size nella documentazione di PostgreSQL.

max_slot_wal_keep_size

Il parametro max_slot_wal_keep_size controlla la quantità di dati WAL che l'istanza database RDS per PostgreSQL conserva nella directory pg_wal per servire gli slot. Questo parametro viene utilizzato per le configurazioni che utilizzano gli slot di replica. Il valore predefinito per questo parametro è -1, ovvero non esiste alcun limite per la quantità di dati WAL conservati nell'istanza database di origine. Per informazioni sul monitoraggio degli slot di replica, consulta Monitoraggio degli slot di replica per l'istanza database RDS per PostgreSQL.

Per ulteriori informazioni su questo parametro, consulta la sezione max_slot_wal_keep_size nella documentazione di PostgreSQL.

Se si interrompe il flusso WAL che fornisce i dati a una replica di lettura, PostgreSQL passa alla modalità di ripristino. Ripristina la replica di lettura utilizzando i dati WAL archiviati da Amazon S3 o utilizzando i dati WAL associati allo slot di replica. Al termine di questo processo, PostgreSQL tenta di ristabilire la replica in streaming.

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 DB RDS per PostgreSQL che esegue PostgreSQL versione 12.9 nello Regione AWS stesso database di origine, quindi non vengono utilizzati slot di replica. Il processo di ripristino è lo stesso valido per le altre istanze database RDS per PostgreSQL che eseguono la versione precedente alla 14.1 di PostgreSQL con repliche di lettura nella regione.

Quando la replica di lettura perde il contatto con l'istanza database di origine, Amazon RDS registra il problema nel registro sotto forma di messaggio FATAL: could not receive data from WAL stream, assieme a ERROR: requested WAL segment ... has already been removed. Come evidenziato nella riga in grassetto, Amazon RDS recupera la replica riproducendo un file WAL archiviato. 

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 abbastanza file WAL archiviati sulla replica da recuperare, viene ripreso lo streaming nella replica di lettura. Quando riprende lo streaming, 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 il monitoraggio delle transazioni, dei blocchi e delle transazioni preparate. IDs 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 primaria, 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 che RDS riavvii le repliche a causa della memoria insufficiente, si consiglia di applicare le modifiche ai parametri come riavvio in sequenza 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 database RDS per PostgreSQL e le repliche di lettura. È necessario assicurarsi che le repliche di lettura siano aggiornate in base alle modifiche dell'istanza database di origine. Amazon RDS recupera 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 ReplicaLag RDS. Per ulteriori informazioni su ReplicaLag e altri parametri per Amazon RDS, consulta CloudWatch Parametri Amazon per Amazon RDS.

  • Controlla il registro PostgreSQL per informazioni che puoi usare per regolare le impostazioni. In ogni checkpoint, il registro PostgreSQL acquisisce il numero di file di registro delle transazioni riciclati, come illustrato 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. Supponiamo, ad esempio, che il registro di PostgreSQL in checkpoint complete mostri 35 recycled per un intervallo di 5 minuti. 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 log di PostgreSQL, puoi utilizzare CloudWatch Amazon per controllare i parametri raccolti. Ad esempio, è possibile monitorare il valore del parametro TransactionLogsGeneration per vedere quanti dati WAL vengono generati dall'istanza database di origine. In alcuni casi, il carico di lavoro sull'istanza database potrebbe generare una grande quantità di dati WAL. 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 per l'istanza database RDS per PostgreSQL

Tutte le versioni di RDS per PostgreSQL utilizzano gli slot di replica per le repliche di lettura tra regioni. RDS per PostgreSQL 14.1 e versioni successive utilizzano gli slot di replica per le repliche di lettura a livello di regione. Le repliche di lettura a livello di regione utilizzano anche Amazon S3 per archiviare i dati WAL. In altre parole, se l'istanza database e le repliche di lettura eseguono PostgreSQL 14.1 o versioni successive, gli slot di replica e gli archivi Amazon S3 sono entrambi disponibili per il ripristino della replica in 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.

È possibile visualizzare gli slot di replica sulle istanze database RDS per PostgreSQL eseguendo una query sulla vista pg_replication_slots, come segue.

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 parametro wal_status con valore reserved significa che la quantità di dati WAL conservati dallo 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'impostazione del parametro max_wal_size, ma i dati WAL vengono conservati.

  • unreserved: lo slot non include più tutti i dati WAL richiesti. Alcuni di essi verranno rimossi al prossimo checkpoint.

  • lost: alcuni dati WAL obbligatori sono stati rimossi. Lo slot non è più utilizzabile.

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

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— Mostra la quantità di dati Write-Ahead Log (WAL) sull'origine che non è stata utilizzata dalla replica con maggior ritardo.

  • TransactionLogsDiskUsage - Mostra la quantità di archiviazione utilizzata per i dati WAL. 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 per RDS per PostgreSQL, consulta. Monitoraggio dei parametri di Amazon RDS Aurora con Amazon CloudWatch Per ulteriori informazioni sul monitoraggio della replica in streaming sulle istanze database RDS per PostgreSQL, consulta la sezione relativa alle best practice per la replica Amazon RDS PostgreSQL sul blog dei database AWS .

Risoluzione dei problemi relativi alla replica di lettura RDS per PostgreSQL

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

Termina la query che causa il ritardo della replica di lettura

Le transazioni attive o inattive in stato di transazione che sono in esecuzione da molto tempo nel database potrebbero interferire con il processo di replica WAL, aumentando così il ritardo di replica. Pertanto, assicurati di monitorare il runtime di queste transazioni con la vista PostgreSQLpg_stat_activity.

Esegui 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 il PID della query, puoi scegliere di terminare la query.

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

SELECT pg_terminate_backend(PID);