Come impostare la replica fisica con PostgreSQL

“PostgreSQL è un popolare sistema di gestione del database relazionale open source supportato dal sistema più operativo. Il modo per mantenere la copia del database principale si chiama replica. La copia del database principale viene replicata sui diversi server fisici. La replica viene eseguita impostando la configurazione Master-Slave. Qui, il master funge da istanza principale e memorizza la copia principale del database e lo slave funge da istanza secondaria che memorizza la copia identica del database principale. Il master funziona come server read-write e lo slave funziona come server di sola lettura. Due tipi di repliche sono supportati dal database PostgreSQL che aiuta a implementare applicazioni scalabili, ad alta disponibilità, tolleranti ai guasti. Si tratta di replicazione di streaming fisica e replicazione logica. Il modo per impostare la replica fisica o in streaming con il database PostgreSQL è stato spiegato in questo tutorial."

Replica fisica o in streaming

La soluzione di replica più comunemente usata è Write-ahead log (Wal) Replica di spedizione o in streaming. Il server di database di standby o lo slave di replica è configurato per stabilire la connessione con il server primario/master. I record WAL vengono trasmessi in streaming sul server di standby prima di riempire il file WAL. I dati vengono trasmessi al server di standby in modalità asincrona per impostazione predefinita. Ciò significa che i dati vengono trasmessi al server di standby dopo aver commesso la transazione nel server primario. Ciò può causare perdita di dati perché se il server principale si blocca senza commettere alcuna transazione, tale transazione non verrà replicata sul server di standby.

L'architettura della replicazione fisica

Un processo di fondo che si chiama Wal Sender inizia sulla macchina principale dopo aver configurato le configurazioni di replica fisica. Accetta una richiesta dallo standby e trasmette continuamente Wal Records allo standby. Un altro processo di background che viene chiamato WAL Ricevitore inizia sulla machine slave che riceve e applica le modifiche del database principale nel database della machine degli slave. La replicazione fisica può essere definita dal seguente diagramma.

Caratteristiche di replicazione fisica

L'intero dati di un singolo cluster è copiato dal processo di replica fisica, in cui il cluster è l'insieme di database gestiti dal database PostgreSQL. La macchina di origine è chiamata server principale e la macchina di destinazione è chiamata server di standby. Di seguito sono state menzionate alcune importanti caratteristiche della replicazione fisica.

File wal

La serie ordinata di record WAL è generata dal server PostgreSQL. Questi record verranno trasportati su un'altra macchina utilizzando la replica fisica e la modifica verrà effettuata nel database locale. I record WAL sono divisi in file di dimensioni equidali che sono chiamati segmenti WAL. Questi file vengono creati sulla directory PG_WAL e i vecchi file WAL vengono rimossi quando non sono più necessari.

Standby caldo, freddo e caldo

Il server Hot Standby viene utilizzato per archiviare i dati aggiornati e consentire ai client di eseguire la transazione di sola lettura. Il server di standby freddo non è attivo e funzionante normalmente e inizia quando si verifica un errore. Il server di standby caldo funziona in modo simile al server di standby hot, tranne per il fatto che non può stabilire la connessione con il client.

Modalità di recupero

I server di standby caldo e caldo vengono eseguiti in modalità di recupero e Postgres importerà e applicherà i file WAL generati da un server primario in modalità di ripristino.

Vantaggi della replicazione fisica o di streaming

• Può essere utilizzato per mantenere il backup del database e aiuta a recuperare i dati quando il server primario si blocca.
• È meglio utilizzare operazioni di sola lettura.
• Garantisce che verrà salvata una copia dell'ultima operazione del server primario.
• Uno o più server di standby possono essere collegati al server primario e le informazioni del registro flussi dal server primario a tutti i server di standby connessi. Se uno dei server di standby è disconnesso o ritardato per qualsiasi motivo, lo streaming verrà continuato per un altro server di standby.
• Se il server primario viene scollegato o chiuso per qualsiasi motivo, aspetterà di inviare i dati aggiornati al server di standby prima di spegnere.

Svantaggi della replicazione fisica o in streaming

• Replica i dati in modo asincrono per impostazione predefinita. Ciò significa che i file WAL che non sono copiati sul server di standby possono essere rimossi quando vengono eseguite eventuali modifiche nel server primario. È meglio impostare un valore più elevato nei wal_keep_segments per evitare la perdita di dati.
• Non supporta la replica tra diversi server postgresql.
• I dati non sono più sicuri in questa replica perché i dati sensibili possono essere estratti senza autenticazione dell'utente.
• Non tronca il comando.
• Non supporta tabelle straniere, visualizzazione e partizione di root tabelle.
• Non supporta la replicazione di grandi oggetti.
• Non supporta schema di database e comandi DDL.

Configurazione della replica fisica

I passaggi di implementazione della replica logica nel database PostgreSQL sono stati mostrati in questa parte di questo tutorial.

Prerequisiti

Imposta i nodi master e replica

È possibile impostare il maestro e i nodi replica in due modi. Un modo è utilizzare due computer separati in cui è installato il sistema operativo Ubuntu e un altro modo è utilizzare due macchine virtuali installate sullo stesso computer. Il processo di test del processo di replica fisica sarà più semplice se si utilizzano due computer separati per il nodo principale e il nodo replica perché un indirizzo IP specifico può essere assegnato facilmente per ciascun computer. Ma se si utilizzano due macchine virtuali sullo stesso computer, l'indirizzo IP statico dovrà essere impostato per ciascuna macchina virtuale e assicurarsi che entrambe le macchine virtuali possano comunicare tra loro tramite l'indirizzo IP statico. Ho usato due macchine virtuali per testare il processo di replica fisica in questo tutorial. Il nome host del nodo principale è stato impostato Fahmida-Master, e il nome host del nodo replica è stato impostato su fahmida-slave Qui.

Installa PostgreSQL su entrambi i nodi Master e Replica

È necessario installare l'ultima versione del server di database PostgreSQL su due macchine prima di iniziare i passaggi di questo tutorial. La versione 14 di PostgreSQL è stata utilizzata in questo tutorial. Esegui i seguenti comandi per verificare la versione installata di PostgreSQL nel nodo principale.

Esegui il comando seguente per diventare un utente root.

$ sudo -i

Esegui i seguenti comandi per accedere come utenti di Postgres con privilegi superutenti e stabilire una connessione con il database PostgreSQL.

$ su - Postgres
$ PSQL

L'output mostra che PostgreSQL versione 14.4 è stato installato su Ubuntu versione 22.04.1.

È necessario installare la stessa versione PostgreSQL nel nodo replica perché la replica logica non può essere impostata tra le diverse versioni del server PostgreSQL.

Configurazione del nodo primario

Le configurazioni necessarie per il nodo primario sono state mostrate in questa parte del tutorial. Le seguenti attività saranno completate nel nodo primario.

• Modifica PostgreSQL.File conf per impostare l'indirizzo IP e il livello WAL.
• Crea un utente di ruolo con quella password per effettuare una connessione con il nodo primario dal nodo replica.
• Modifica PG_HBA.Conf File per aggiungere informazioni sulla connessione di rete

Modificare il Postgresql.conf file

È necessario impostare l'indirizzo IP del nodo primario nel file di configurazione PostgreSQL Postgresql.conf che si trova sulla posizione, /etc/postgresql/14/main/postgresql.conf. Accedi come utente root nel nodo primario ed esegui il comando seguente per modificare il file.

$ nano/etc/postgresql/14/main/postgresql.conf

Scopri il Ascolta_addresses Variabile nel file, rimuovere l'hash (#) dall'inizio della variabile per rimuovere la linea. È possibile impostare un asterisco (*) o l'indirizzo IP del nodo primario per questa variabile. Se si imposta Asterisk (*), il server primario ascolterà tutti gli indirizzi IP. Ascolterà l'indirizzo IP specifico se l'indirizzo IP del server primario è impostato su questa variabile. In questo tutorial, l'indirizzo IP del server primario che è stato impostato su questa variabile è 192.168.10.5.

ascolt_addressess = ""

Successivamente, scopri il Wal_Level variabile per impostare il tipo di replica. Qui, il valore della variabile sarà un replica.

Wal_Level = replica

Eseguire il seguente comando per riavviare il server PostgreSQL dopo aver modificato il Postgresql.conf file.

$ SystemCtl Riavvia PostgreSQL

*** Nota: dopo aver configurato la configurazione, se si affronta un problema che avvia il server PostgreSQL, quindi eseguire i seguenti comandi per la versione PostgreSQL 14.

$ sudo chmod 700 -r/var/lib/postgresql/14/main
$ sudo -i -u postgres
#/usr/lib/postgresql/14/bin/pg_ctl riavvio -d/var/lib/postgresql/14/main

Sarai in grado di connetterti con il server PostgreSQL dopo aver eseguito correttamente il comando sopra.

Crea ruolo/utente per la replica

Per la replica è richiesto un ruolo/utente con autorizzazione specifica. Esegui il seguente comando SQL per creare un ruolo con l'utente per la replica.

# Crea ruolo replicaUser con password di accesso alla replica '12345';

Il seguente output apparirà se il ruolo viene creato correttamente.

Modificare il pg_hba.conf file

È necessario impostare l'indirizzo IP del nodo secondario nel file di configurazione PostgreSQL pg_hba.conf che si trova sulla posizione, /etc/postgresql/14/main/pg_hba.conf. Accedi come utente root nel nodo primario ed esegui il comando seguente per modificare il file.

$ nano/etc/postgresql/14/main/pg_hba.conf

Aggiungi le seguenti informazioni alla fine di questo file.

host /32 Scram-sha-256

L'IP del server slave è impostato su "192.168.10.10" Qui. Secondo i passaggi precedenti, la riga seguente è stata aggiunta al file.

replica host replicauser 192.168.10.10/32 Scram-sha-256

Riavvia il server PostgreSQL

Esegui il seguente comando per riavviare il server PostgreSQL come utente root.

$ SystemCtl Riavvia PostgreSQL

Configurazione del nodo replica

Le attività necessarie verranno eseguite per il nodo replica in cui verrà memorizzata la copia del database principale. Il contenuto di database esistente del nodo replica verrà rimosso per mantenere il backup del database del nodo primario e rendere il server PostgreSQL del nodo replica di sola lettura.

Arrestare il server PostgreSQL sul nodo replica

Esegui il comando seguente dopo aver effettuato l'accesso come utente root per arrestare il server PostgreSQL.

$ SYSTEMCTL STOP POSTGRESQL

Rimuovere il contenuto esistente del nodo replica

Esegui il comando seguente per rimuovere il contenuto del database esistente dal server PostgreSQL del nodo replica. È necessario per scopi di replica. Il nodo replica verrà lavorato in modalità di sola lettura dopo aver eseguito il seguente comando

$ rm -rf/var/lib/postgresql/14/main/*

Testare il processo di replicazione fisica

È necessario creare un database con una o più tabelle nel nodo primario per verificare se la replica fisica funziona correttamente o meno. Qui, il database esistente chiamato Postgres del server primario è stato utilizzato per scopi di test. Se lo desideri, puoi creare la tabella creando un nuovo database. Le seguenti attività saranno svolte in questa parte del tutorial.

• Aggiungi una nuova tabella nel database selezionato del nodo primario.
• Aggiungi un record alla tabella.
• Archivia la copia del database del nodo primario nel nodo replica.
• Crea una tabella nel server primario

Accedi al database PostgreSQL del nodo primario ed esegui la seguente istruzione SQL per creare un dipendenti Tabella nel database esistente Postgres. Se lo desideri, è possibile creare un nuovo database e creare la tabella selezionando il nuovo database. Non ho creato alcun nuovo database qui. Quindi, la tabella verrà creata nel database predefinito. La tabella dei dipendenti conterrà 5 campi. Questi sono ID, nome, indirizzo, e -mail e telefono.

# Crea dipendenti della tabella (
Chiave primaria seriale ID,
Nome varchar (15) non null,
il testo dell'indirizzo non null,
Email Varchar (30),
telefono char (14) non null);

Esegui la seguente istruzione SQL per inserire un record nella tabella.

# Inserisci nei dipendenti (nome, indirizzo, e -mail, telefono)
Valori ('Farheen Hasan', '12/A, Dhanmondi, Dhaka.',' [email protected] ',' +8801826783423 ');
Esegui la seguente istruzione SQL per leggere il contenuto della tabella dei dipendenti.
# Seleziona * dai dipendenti;

Se viene creata la tabella e un record viene inserito nella tabella correttamente, verrà visualizzato il seguente output dopo l'esecuzione della query selezionata. Un record è stato inserito nella tabella mostrata nell'output.

Copia il database su un server di replica

Accedi al database PostgreSQL del server replica ed esegui la seguente istruzione SQL per creare una copia del Postgres database del server primario nel server replica. Dopo aver eseguito l'istruzione, chiederà la password dell'utente creata nel passaggio precedente. Se l'autenticazione viene eseguita correttamente, verrà avviata la replica.

# pg_basebackup -r -h 192.168.10.5 -u replicauser -d/var/lib/postgresql/14/main -p

Il seguente output mostra che la replica viene eseguita correttamente e 34962 KB è stata copiata.

Esegui il comando seguente dopo aver completato la replica come utente root per riavviare il server PostgreSQL nel nodo replica.

$ SystemCtl Riavvia PostgreSQL

Ora, accedi al server PostgreSQL sul nodo replica ed esegui la seguente istruzione SQL per verificare se il dipendenti' La tabella è stata copiata nel nodo replica o no.

# Seleziona * dai dipendenti;

Il seguente output mostra il contenuto del dipendenti' tavolo del replica Il nodo è lo stesso del contenuto del dipendenti' tavolo del primario nodo.

È possibile aggiungere uno o più record o aggiornare i record o eliminare i record nella tabella dei dipendenti del nodo primario o aggiungere una o più tabelle nel database selezionato del nodo primario e controllare il database del nodo replica per verificare che il contenuto aggiornato del database primario viene replicato correttamente nel database del nodo replica o no.

Inserire nuovi record nel nodo primario:

Ora, esegui il seguente comando insert per aggiungere altri tre record nella tabella dei dipendenti del Postgres database che si trova in primario nodo.

# Inserisci nei dipendenti (nome, indirizzo, e -mail, telefono)
Valori ('Abir Hossain', '10, Jigatola, Dhaka.',' [email protected] ',' +8801888564345 '),
('Nila Chowdhury', '67/B, Mirpur, Dhaka.',' [email protected] ',' +8801799453123 '),
("Mizanur Rahman", "8/C, Malibag, Dhaka.',' [email protected] ',' +8801957864564 ');
Esegui il comando seguente per verificare il contenuto corrente della tabella dei dipendenti nel nodo principale.
# Seleziona * dai dipendenti;

Il seguente output mostra che tre nuovi record sono stati inseriti correttamente nella tabella.

Controlla il nodo replica dopo l'inserimento:

Ora, devi verificare se la tabella dei dipendenti del nodo replica è stata aggiornata o no. Accedi al server PostgreSQL del nodo replica ed esegui il seguente comando per controllare il contenuto della tabella dei dipendenti.

# Seleziona * dai dipendenti;

Il seguente output mostra che tre nuovi record sono stati inseriti nel dipendenti' tavolo del replica nodo inserito nel primario nodo del dipendenti' tavolo. Quindi, le modifiche nel database principale sono state replicate correttamente nel nodo replica.

Aggiorna il record nel nodo principale:

Esegui il seguente comando di aggiornamento che aggiornerà il valore del campo del telefono in cui il valore del campo è "Nila Chowdhury". C'è solo un record in dipendenti' Tabella che corrisponde alla condizione della query di aggiornamento.

# Aggiorna i dipendenti set telefono = “+8801911111111” dove name = “Nila Chowdhury”;

Eseguire il comando seguente per verificare il contenuto corrente di dipendenti' tavolo nel primario nodo.

# Seleziona * dai dipendenti;

Il seguente output lo mostra il telefono Il valore di campo del record particolare è stato aggiornato dopo aver eseguito la query di aggiornamento.

Controlla il nodo replica dopo l'aggiornamento:

Ora, devi verificare se la tabella dei dipendenti del nodo replica è stata aggiornata o no. Accedi al server PostgreSQL del nodo replica ed esegui il seguente comando per controllare il contenuto della tabella dei dipendenti.

# Seleziona * dai dipendenti;

Il seguente output mostra che un record è stato aggiornato in dipendenti' tavolo del replica nodo, che è stato aggiornato nel primario nodo del dipendenti' tavolo. Quindi, le modifiche nel database principale sono state replicate correttamente nel nodo replica.

Elimina il record nel nodo primario:

Esegui il seguente comando Elimina che eliminerà un record dal dipendenti' tavolo del primario nodo in cui il valore del campo e -mail è “[email protected] ". C'è solo un record in dipendenti' Tabella che corrisponde alla condizione della query Elimina.

# Elimina dai dipendenti dove email = '[email protected] ';

Eseguire il comando seguente per verificare il contenuto corrente di dipendenti' tavolo nel primario nodo.

# Seleziona * dai dipendenti;

Il seguente output mostra che un record è stato eliminato dopo aver eseguito la query Elimina.

Controllare il nodo replica dopo aver eliminato il record:

Ora, devi verificare se la tabella dei dipendenti del nodo replica è stata eliminata o no. Accedi al server PostgreSQL del nodo replica ed esegui il seguente comando per controllare il contenuto della tabella dei dipendenti.

# Seleziona * dai dipendenti;

Il seguente output mostra che un record è stato eliminato nel dipendenti' tavolo del replica nodo, che è stato eliminato nel primario nodo del dipendenti' tavolo. Quindi, le modifiche nel database principale sono state replicate correttamente nel nodo replica.

Conclusione

Lo scopo della replicazione fisica per mantenere il backup del database, l'architettura della replicazione fisica, i vantaggi e gli svantaggi della replicazione fisica e le fasi dell'implementazione della replicazione fisica nel database PostgreSQL sono stati spiegati in questo tutorial con esempi. Spero che il concetto di replica fisica venga cancellato per gli utenti e che gli utenti saranno in grado di utilizzare questa funzione nel loro database PostgreSQL dopo aver letto questo tutorial.