PostgreSQL il database supporta diverse soluzioni di replica per creare applicazioni ad alta disponibilità, scalabili e tolleranti ai guasti, una delle quali è il Registro di scrittura in anticipo (WAL ) Spedizione. Questa soluzione consente l'implementazione di un server in 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 principale/principale, che trasmette in streaming WAL record in standby mentre vengono generati, senza attendere il WAL file da compilare.
Per impostazione predefinita, la replica in streaming è asincrona in cui i dati vengono scritti sui server di standby dopo che una transazione è stata salvata sul server primario. Ciò significa che c'è un piccolo ritardo tra il commit di una transazione nel server master e le modifiche che diventano visibili nel server di standby. Uno svantaggio di questo approccio è che in caso di arresto anomalo del server master, le transazioni non vincolate potrebbero non essere replicate e ciò può causare la perdita di dati.
Questa guida mostra come configurare un Postgresql 12 replica streaming master-standby su CentOS 8 . Utilizzeremo "slot di replica ” per lo standby come soluzione per evitare che il server master ricicla il vecchio WAL segmenti prima che lo standby li abbia ricevuti.
Tieni presente che, rispetto ad altri metodi, gli slot di replica conservano solo il numero di segmenti notoriamente necessari.
Ambiente di test:
Questa guida presuppone che tu sia connesso ai server di database master e standby come root tramite SSH (usa Sudo comando ove necessario se sei connesso come un normale utente con diritti di amministratore):
Postgresql master database server: 10.20.20.9 Postgresql standby database server: 10.20.20.8
Entrambi i server di database devono avere Postgresql 12 installato, in caso contrario, vedere:Come installare PostgreSQL e pgAdmin in CentOS 8.
Nota :PostgreSQL 12 viene fornito con importanti modifiche all'implementazione e alla configurazione della replica, come la sostituzione di recovery.conf e la conversione di recovery.conf parametri ai normali parametri di configurazione di PostgreSQL, rendendo molto più semplice configurare la replica del cluster.
Fase 1:configurazione del server di 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, utilizzeremo * significa tutto.
# su - postgres $ psql -c "ALTER SYSTEM SET listen_addresses TO '*';"
Il SET DI SISTEMA ALTER Il comando SQL è una potente funzionalità per modificare i parametri di configurazione di un server, direttamente con una query SQL. Le configurazioni vengono salvate in postgresql.conf.auto file situato nella radice della cartella dei dati (ad es. /var/lib/pgsql/12/data/ ) e leggere le aggiunte a quelle archiviate in postgresql.conf . Ma le configurazioni nel primo hanno la precedenza su quelle nel successivo e in altri file correlati.
Configura indirizzi IP su PostgreSQL Master
2. Quindi crea un ruolo di replica che verrà utilizzato per le connessioni dal server di standby al server master, utilizzando createuser programma. Nel comando seguente, il -P flag richiede una password per il nuovo ruolo e -e fa eco ai comandi che createuser genera e invia al server del database.
# su – postgres $ createuser --replication -P -e replicator $ exit
Crea utente di replica su Pgmaster
3. Quindi inserisci la seguente voce alla fine di /var/lib/pgsql/12/data/pg_hba.conf file di configurazione dell'autenticazione del client con il campo del database impostato su replica come mostrato nello screenshot.
host replication replicator 10.20.20.8/24 md5
Configura l'autenticazione della replica
4. Ora riavvia Postgres12 servizio utilizzando il seguente comando systemctl per applicare le modifiche.
# systemctl restart postgresql-12.service
5. Successivamente, se hai il firewalld servizio in esecuzione, è necessario 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
Fase 2:eseguire un backup di base per avviare il server di standby
6. Successivamente, è necessario eseguire un backup di base del server master dal server di standby; questo aiuta ad avviare il server di standby. È necessario arrestare il servizio postgresql 12 sul server di standby, passare all'account utente postgres, eseguire il backup della directory dei dati (/var/lib/pgsql/12/data/ ), quindi elimina tutto ciò che contiene 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 il pg_basebackup strumento per eseguire il backup di base con il diritto di proprietà (l'utente del sistema di database, ad esempio Postgres , all'interno di Postgres account utente) e con i permessi corretti.
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 il reporting sullo stato di avanzamento.-v– abilita la modalità dettagliata.-R– abilita la creazione della configurazione di ripristino:crea un standby.signal file e aggiungi le impostazioni di connessione a postgresql.auto.conf nella directory dei dati.-X– utilizzato per includere i file di registro write-ahead (file WAL) richiesti nel backup. Un valore di stream significa eseguire 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.5 -D /var/lib/pgsql/12/data -U replicator -P -v -R -X stream -C -S pgstandby1 $ exit
Backup di base del server principale
8. Al termine del processo di backup, la nuova directory dei dati sul server di standby dovrebbe essere simile a quella dello screenshot. Un segnale.standby viene creato 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/
Verifica la directory dei dati di backup
Uno slave di replica verrà eseguito in "Hot Standby ” se è hot_standby il parametro è impostato su on (il valore predefinito) in postgresql.conf e c'è un segnale.standby file presente nella directory dei dati.
9. Ora di nuovo sul server principale, dovresti essere in grado di vedere lo slot di replica chiamato pgstandby1 quando apri gli pg_replication_slots visualizzare come segue.
# su - postgres $ psql -c "SELECT * FROM pg_replication_slots;" $ exit
Crea slot di replica
10. Per visualizzare le impostazioni di connessione aggiunte in postgresql.auto.conf file, usa il comando cat.
# cat /var/lib/pgsql/12/data/postgresql.auto.conf
Visualizza le impostazioni di connessione
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 in streaming PostgreSQL
12. Una volta stabilita correttamente una connessione tra il master e lo standby, vedrai un WAL processo ricevitore nel server di standby con uno stato di streaming, puoi verificarlo utilizzando il pg_stat_wal_receiver visualizza.
$ psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"
Controlla il processo di ricezione WAL
e un corrispondente WAL processo del mittente nel server principale/principale con uno stato di streaming e uno sync_state di asincrono, puoi controllare questa vista pg_stat_replication pg_stat_replication.
$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"
Controlla il processo mittente WAL in Master
Dallo screenshot sopra, la replica in streaming è asincrona. Nella prossima sezione, dimostreremo come abilitare facoltativamente la replica sincrona.
13. Ora verifica se la replica funziona correttamente creando un database di test nel server master e controlla se esiste nel server di standby.
[master]postgres=# CREATE DATABASE tecmint;
[standby]postgres=# \l
Prova la replica in streaming
Facoltativo:abilitazione della replica sincrona
14. La replica sincrona offre la possibilità di eseguire il commit di una transazione (o di scrivere dati) nel database primario e nello standby/replica contemporaneamente. Conferma solo che una transazione ha 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, il synchronous_commit deve anche essere impostato su on (che è il valore predefinito, quindi non è necessaria alcuna modifica) e devi anche impostare i synchronous_standby_names parametro a un valore non vuoto. Per questa guida, la imposteremo su tutti.
$ psql -c "ALTER SYSTEM SET synchronous_standby_names TO '*';"
Imposta i nomi in standby di sincronizzazione in Master
15. Quindi ricarica il servizio PostgreSQL 12 per applicare le nuove modifiche.
# systemctl reload postgresql-12.service
16. Ora quando interroghi il WAL processo mittente sul server primario ancora una volta, dovrebbe mostrare uno stato di streaming e uno sync_state di sincronizzazione .
$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"
Controlla il processo mittente WAL in Master
Siamo giunti alla fine di questa guida. Abbiamo mostrato come configurare PostgreSQL 12 replica dello streaming del database master-standby 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 il proprio ambiente IT e/o i requisiti specifici dell'applicazione. Per maggiori dettagli, vai a Log-Shipping Standby Server nella documentazione di PostgreSQL 12.
Condividere è prendersi cura...Condividi su FacebookCondividi su TwitterCondividi su LinkedinCondividi su Reddit