Ricerca nel sito web

Come configurare la replica di streaming di PostgreSQL 12 in CentOS 8

Il database PostgreSQL supporta diverse soluzioni di replica per creare applicazioni ad alta disponibilità, scalabili e con tolleranza agli errori, una delle quali è Write-Ahead Log (WAL ) Spedizione. Questa soluzione consente di implementare un server di standby utilizzando il log shipping basato su file o la replica in streaming o, ove possibile, una combinazione di entrambi gli approcci.

Con la replica in streaming, un server di database in standby (slave di replica) è configurato per connettersi al server master/primario, che trasmette i record WAL al server in standby man mano che vengono generati, senza attendere il WAL file da compilare.

Per impostazione predefinita, la replica del flusso è asincrona in cui i dati vengono scritti sui server di standby dopo il commit di una transazione sul server primario. Ciò significa che c'è un piccolo ritardo tra il commit di una transazione nel server master e la visibilità delle modifiche nel server di standby. Uno svantaggio di questo approccio è che, in caso di arresto anomalo del server master, eventuali transazioni non confermate potrebbero non essere replicate e ciò potrebbe causare la perdita di dati.

Questa guida mostra come impostare una replica di streaming master-standby Postgresql 12 su CentOS 8. Utilizzeremo gli "slot di replica" per lo standby come soluzione per evitare che il server master ricicli i vecchi segmenti WAL prima che lo standby li abbia ricevuti.

Si noti che rispetto ad altri metodi, gli slot di replica conservano solo il numero di segmenti necessari.

Ambiente di test:

Questa guida presuppone che tu sia connesso ai server del database master e di standby come root tramite SSH (usa il comando Sudo dove necessario se sei connesso come un normale utente con diritti amministrativi):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Entrambi i server database devono avere Postgresql 12 installato, altrimenti vedere: Come installare PostgreSQL e pgAdmin in CentOS 8.

Nota: PostgreSQL 12 include importanti modifiche all'implementazione e alla configurazione della replica, come la sostituzione di recovery.conf e la conversione dei parametri recovery.conf in normali parametri di configurazione PostgreSQL, rendendo molto più semplice la configurazione della replica del cluster.

Passaggio 1: configurazione del server database master/primario PostgreSQL

1. Sul server master, passa all'account di sistema postgres e configura gli indirizzi IP su cui il server master ascolterà le connessioni dai client.

In questo caso useremo * per indicare tutto.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

Il comando SQL ALTER SYSTEM SET è una potente funzionalità per modificare i parametri di configurazione di un server, direttamente con una query SQL. Le configurazioni vengono salvate nel file postgresql.conf.auto situato nella radice della cartella dei dati (ad esempio /var/lib/pgsql/12/data/) e leggi l'aggiunta a quelli memorizzati in postgresql.conf. Ma le configurazioni dei primi hanno la precedenza su quelle dei successivi e su altri file correlati.

2. Quindi crea un ruolo di replica che verrà utilizzato per le connessioni dal server di standby al server master, utilizzando il programma createuser. Nel comando seguente, il flag -P richiede una password per il nuovo ruolo e -e riecheggia i comandi che createuser genera e invia al server del database.

su – postgres
createuser --replication -P -e replicator
exit

3. Quindi inserisci la seguente voce alla fine del file di configurazione dell'autenticazione client /var/lib/pgsql/12/data/pg_hba.conf con il campo del database impostato su replica come mostrato nello screenshot.

host    replication     replicator      10.20.20.8/24     md5

4. Ora riavvia il servizio Postgres12 utilizzando il seguente comando systemctl per applicare le modifiche.

systemctl restart postgresql-12.service

5. Successivamente, se hai il servizio firewalld in esecuzione, devi aggiungere il servizio Postgresql nella configurazione firewalld per consentire le richieste dal server di standby al master.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Passaggio 2: eseguire un backup di base per avviare il server di standby

6. Successivamente, è necessario effettuare un backup di base del server master dal server di standby; questo aiuta ad avviare il server di standby. È necessario interrompere il servizio postgresql 12 sul server in standby, passare all'account utente postgres, eseguire il backup della directory dei dati (/var/lib/pgsql/12/data/), quindi eliminare tutto ciò che si trova sotto come mostrato, prima di eseguire il backup di base.

systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Quindi utilizza lo strumento pg_basebackup per eseguire il backup di base con la proprietà corretta (l'utente del sistema di database, ovvero Postgres, all'interno del account utente Postgres) e con le giuste autorizzazioni.

Nel comando seguente, l'opzione:

  • -h – specifica l'host che è il server principale.
  • -D – specifica la directory dei dati.
  • -U – specifica l'utente della connessione.
  • -P – abilita la segnalazione dei progressi.
  • -v – abilita la modalità dettagliata.
  • -R – abilita la creazione della configurazione di ripristino: crea un file standby.signal e aggiunge le impostazioni di connessione a postgresql.auto.conf sotto i dati directory.
  • -X – utilizzato per includere nel backup i file di registro write-ahead richiesti (file WAL). Un valore stream indica lo streaming del WAL mentre viene creato il backup.
  • -C – abilita la creazione di uno slot di replica denominato dall'opzione -S prima di avviare il backup.
  • -S – specifica il nome dello slot di replica.
pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Al termine del processo di backup, la nuova directory dei dati sul server in standby dovrebbe apparire come quella nello screenshot. Viene creato un standby.signal e le impostazioni di connessione vengono aggiunte a postgresql.auto.conf. Puoi elencarne il contenuto usando il comando ls.

ls -l /var/lib/pgsql/12/data/

Uno slave di replica verrà eseguito in modalità “Hot Standby” se il parametro hot_standby è impostato su on (il valore predefinito) in postgresql.conf e è presente un file standby.signal nella directory dei dati.

9. Ora tornando sul server principale, dovresti essere in grado di vedere lo slot di replica chiamato pgstandby1 quando apri la vista pg_replication_slots come segue.

su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

10. Per visualizzare le impostazioni di connessione aggiunte al file postgresql.auto.conf, utilizzare il comando cat.

cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Ora inizia le normali operazioni del database sul server di standby avviando il servizio PostgreSQL come segue.

systemctl start postgresql-12

Passaggio 3: test della replica di streaming PostgreSQL

12. Una volta stabilita con successo una connessione tra il master e lo standby, vedrai un processo di ricezione WAL nel server standby con uno stato di streaming, puoi verificarlo utilizzando la vista pg_stat_wal_receiver.

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

e un processo mittente WAL corrispondente nel server master/primario con uno stato di streaming e uno sync_state async, puoi controllare questa vista pg_stat_replication pg_stat_replication.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Dallo screenshot sopra, la replica dello streaming è asincrona. Nella sezione successiva verrà illustrato come abilitare facoltativamente la replica sincrona.

13. Ora verifica se la replica funziona correttamente creando un database di prova nel server master e controlla se esiste nel server di standby.
[master]postgres=# CREA DATABASE tecmint;
[standby]postgres=# \l

Facoltativo: abilitazione della replica sincrona

14. La replica sincrona offre la possibilità di eseguire il commit di una transazione (o scrivere dati) sul database primario e sullo standby/replica contemporaneamente. Conferma solo che una transazione ha avuto esito positivo quando tutte le modifiche apportate dalla transazione sono state trasferite a uno o più server di standby sincroni.

Per abilitare la replica sincrona, anche il synchronous_commit deve essere impostato su on (che è il valore predefinito, quindi non è necessaria alcuna modifica) e devi anche impostare il parametro synchronous_standby_names ad un valore non vuoto. Per questa guida lo imposteremo su tutti.

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Quindi ricarica il servizio PostgreSQL 12 per applicare le nuove modifiche.

systemctl reload postgresql-12.service

16. Ora quando interroghi ancora una volta il processo del mittente WAL sul server primario, dovrebbe mostrare uno stato di streaming e un sync_state di sincronizzazione.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Siamo giunti alla fine di questa guida. Abbiamo mostrato come configurare la replica in streaming del database master-standby PostgreSQL 12 in CentOS 8. Abbiamo anche spiegato come abilitare la replica sincrona in un cluster di database PostgreSQL.

Esistono molti usi della replica ed è sempre possibile scegliere una soluzione che soddisfi i requisiti specifici dell'ambiente IT e/o dell'applicazione. Per maggiori dettagli, vai a Server di standby per la distribuzione dei log nella documentazione di PostgreSQL 12.