PostgreSQL può funzionare separatamente su più macchine con la stessa struttura dati, rendendo il livello di persistenza dell'applicazione più resiliente e preparato per qualche evento imprevisto che potrebbe compromettere la continuità del servizio.
L'idea alla base è quella di migliorare i tempi di risposta del sistema distribuendo le richieste in una rete “Round Robin” dove ogni nodo presente è un cluster. In questo tipo di configurazione non è importante quale delle richieste verranno consegnate per essere elaborate, in quanto la risposta sarebbe sempre la stessa.
In questo blog spiegheremo come replicare un cluster PostgreSQL utilizzando gli strumenti forniti nell'installazione del programma. La versione utilizzata è PostgreSQL 11.5, l'attuale versione stabile e generalmente disponibile per il sistema operativo Debian Buster. Per gli esempi in questo blog si presume che tu abbia già familiarità con Linux.
Programmi PostgreSQL
All'interno della directory /usr/bin/ c'è il programma responsabile della gestione del cluster.
# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_Le attività svolte attraverso questi programmi possono essere eseguite in sequenza o anche in combinazione con altri programmi. L'esecuzione di un blocco di queste attività tramite un unico comando è possibile grazie ad un programma Linux che si trova nella stessa directory, chiamato make.
Per elencare i cluster presenti usa il programma pg_lsclusters. Puoi anche usare make per eseguirlo. Il suo lavoro dipende da un file chiamato Makefile, che deve trovarsi nella stessa directory in cui verrà eseguito il comando.
# 1. The current directory is checked
pwd
# 2. Creates a directory
mkdir ~/Documents/Severalnines/
# 3. Enroute to the chosen directory
cd ~/Documents/Severalnines/
# 4. Create the file Makefile
touch Makefile
# 5. Open the file for editingDi seguito è mostrata la definizione di un blocco, avente come nome ls, e un unico programma da eseguire, pg_lsclusters.
# 1. Block name
ls:
# 2. Program to be executed
pg_lsclustersIl file Makefile può contenere più blocchi e ciascuno può eseguire tutti i programmi necessari e persino ricevere parametri. È fondamentale che le righe appartenenti a un blocco di esecuzione siano corrette, utilizzando le tabulazioni per il rientro anziché gli spazi.
L'uso di make per eseguire il programma pg_lsclusters si ottiene usando il comando make ls.
# 1. Executes pg_lsclusters
make lsIl risultato ottenuto in una recente installazione di PostgreSQL porta un unico cluster chiamato main, allocato sulla porta 5432 del sistema operativo. Quando viene utilizzato il programma pg_createcluster, al nuovo cluster creato viene allocata una nuova porta, avente come punto di partenza il valore 5432, finché non se ne trova un'altra in ordine crescente.
Registrazione scrittura anticipata (WAL)
Questa procedura di replica consiste nell'effettuare un backup di un cluster funzionante che continua a ricevere aggiornamenti. Se ciò avviene sulla stessa macchina, tuttavia, molti dei vantaggi apportati da questa tecnica vengono persi.
Il ridimensionamento orizzontale di un sistema garantisce una maggiore disponibilità del servizio, come se si verificassero problemi hardware non farebbe molta differenza in quanto ci sono altre macchine pronte ad affrontare il carico di lavoro.
WAL è il termine usato per rappresentare un algoritmo complesso interno a PostgreSQL che garantisce l'integrità delle transazioni effettuate sul sistema. Tuttavia, solo un singolo cluster deve avere la responsabilità di accedervi con l'autorizzazione di scrittura.
L'architettura ora ha tre tipi distinti di cluster:
- Un primario con responsabilità di scrivere a WAL;
- Una replica pronta per occupare il posto principale;
- Varie altre repliche con funzione di lettura WAL.
Le operazioni di scrittura sono tutte le attività che hanno lo scopo di modificare la struttura dei dati, inserendo nuovi elementi o aggiornando ed eliminando record esistenti.
Configurazione del cluster PostgreSQL
Ogni cluster ha due directory, una contenente i suoi file di configurazione e l'altra con i log delle transazioni. Questi si trovano rispettivamente in /etc/postgresql/11/$(cluster) e /var/lib/postgresql/11/$(cluster) (dove $(cluster) è il nome del cluster).
Il file postgresql.conf viene creato subito dopo la creazione del cluster eseguendo il programma pg_createcluster, e le proprietà possono essere modificate per la personalizzazione di un cluster.
La modifica diretta di questo file non è consigliata perché contiene quasi tutte le proprietà. I loro valori sono stati commentati, con il simbolo # all'inizio di ogni riga e molte altre righe commentate contenenti istruzioni per modificare i valori delle proprietà.
È possibile aggiungere un altro file contenente le modifiche desiderate, è sufficiente modificare una singola proprietà denominata include, sostituendo il valore predefinito #include ='' con include ='postgresql.replication.conf'.
Prima di avviare il cluster, è necessaria la presenza del file postgresql.replication.conf nella stessa directory in cui si trova il file di configurazione originale, chiamato postgresql.conf.
# 1. Block name
create:
# 2. Creates the cluster
pg_createcluster 11 $(cluster) -- --data-checksums
# 3. Copies the file to the directory
cp postgresql.replication.conf /etc/postgresql/11/$(cluster)/
# 4. A value is assigned to the property
sed -i "s|^#include = ''|include = 'postgresql.replication.conf'|g" /etc/postgresql/11/$(cluster)/postgresql.confL'uso di --data-checksums nella creazione del cluster aggiunge un maggiore livello di integrità ai dati, costando un po' di prestazioni ma essendo molto importante per evitare il danneggiamento dei file quando trasferiti da un cluster all'altro.
Le procedure sopra descritte possono essere riutilizzate per altri cluster, semplicemente passando un valore a $(cluster) come parametro nell'esecuzione del programma make.
# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primaryOra che è stata stabilita una breve automazione delle attività, ciò che resta da fare è la definizione del file postgresql.replication.conf in base alle necessità di ciascun cluster.
Replica su PostgreSQL
Sono possibili due modi per replicare un cluster, uno completo, l'altro che coinvolge l'intero cluster (denominato Streaming Replication) e un altro può essere parziale o completo (denominato Logical Replication).
Le impostazioni che devono essere specificate per un cluster rientrano in quattro categorie principali:
- Server principale
- Server in standby
- Server di invio
- Abbonati
Come abbiamo visto in precedenza, WAL è un file che contiene le transazioni effettuate sul cluster e la replica è la trasmissione di questi file da un cluster all'altro.
All'interno delle impostazioni presenti nel file postgresql.conf, possiamo vedere delle proprietà che definiscono il comportamento del cluster in relazione ai file WAL, come la dimensione di quei file.
# default values
max_wal_size = 1GB
min_wal_size = 80MBUn'altra proprietà importante chiamata max_wal_senders. Appartenente a un cluster con i caratteristici Sending Server, è la quantità di processi responsabili dell'invio di questi file ad altri cluster, avendo sempre un valore superiore al numero di cluster che dipendono dalla loro ricezione.
I file WAL possono essere archiviati per la trasmissione a un cluster che si connette in ritardo, o che ha avuto qualche problema nella ricezione, e necessita di file precedenti in relazione all'ora corrente, avendo come specifica la proprietà wal_keep_segments per quanti segmenti di file WAL devono essere gestiti da un cluster.
Uno slot di replica è una funzionalità che consente al cluster di archiviare i file WAL necessari per fornire a un altro cluster tutti i record, avendo l'opzione max_replication_slots come proprietà.
# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10Quando l'intenzione è di esternalizzare l'archiviazione di questi file WAL, è possibile utilizzare un altro metodo di elaborazione di questi file, chiamato Archiviazione Continua.
Archiviazione continua
Questo concetto consente di indirizzare i file WAL in una posizione specifica, utilizzando un programma Linux e due variabili che rappresentano il percorso del file e il suo nome, come %p e %f, rispettivamente.
Questa proprietà è disabilitata per impostazione predefinita, ma il suo utilizzo può essere facilmente implementato sottraendo la responsabilità di un cluster alla memorizzazione di file così importanti e può essere aggiunta al file postgresql.replication.conf.
# 1. Creates a directory
mkdir ~/Documents/Severalnines/Archiving
# 2. Implementation on postgresql.replication.conf
archive_mode = on
archive_command = 'cp %p ~/Documents/Severalnines/Archiving/%f'
# 3. Starts the cluster
sudo systemctl start [email protected]Dopo l'inizializzazione del cluster, potrebbe essere necessario modificare alcune proprietà e potrebbe essere necessario un riavvio del cluster. Tuttavia, alcune proprietà possono solo essere ricaricate, senza la necessità di un riavvio completo di un cluster.
Informazioni su tali argomenti possono essere ottenute tramite i commenti presenti nel file postgresql.conf, che compare come # (nota:la modifica richiede il riavvio).
Se questo è il caso, un modo semplice per risolvere è con il programma Linux systemctl, utilizzato in precedenza per avviare il cluster, dovendo solo sovrascrivere l'opzione di riavvio.
Quando non è richiesto un riavvio completo, il cluster stesso può riassegnare le sue proprietà tramite una query eseguita al suo interno, tuttavia, se più cluster sono in esecuzione sulla stessa macchina, sarà richiesto di passare un parametro contenente il valore della porta che il cluster è allocato sul sistema operativo.
# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433Nell'esempio sopra, la proprietà archive_mode richiede un riavvio, mentre archive_command no. Dopo questa breve introduzione a questo argomento, diamo un'occhiata a come un cluster di replica può eseguire il backup di questi file WAL archiviati, utilizzando il Point In Time Recovery (PITR).
Recupero point-in-time della replica PostgreSQL
Questo nome suggestivo consente a un ammasso di tornare al suo stato da un certo periodo di tempo. Ciò avviene tramite una proprietà denominata recovery_target_timeline, che prevede di ricevere un valore in formato data, ad esempio 2019-08-22 12:05 GMT, o l'ultima assegnazione, informando la necessità di un ripristino fino all'ultimo record esistente.
Il programma pg_basebackup quando viene eseguito, crea una copia di una directory contenente i dati da un cluster in un'altra posizione. Questo programma tende a ricevere più parametri, uno di questi è -R, che crea un file chiamato recovery.conf all'interno della directory copiata, che a sua volta non è la stessa che contiene gli altri file di configurazione visti in precedenza, come postgresql.conf .
Il file recovery.conf memorizza i parametri passati nell'esecuzione del programma pg_basebackup, e la sua esistenza è fondamentale per l'implementazione della Streaming Replication, perché è al suo interno che può essere eseguita l'operazione inversa all'Archiviazione Continua essere eseguito.
# 1. Block name
replicate:
# 2. Removes the current data directory
rm -rf /var/lib/postgresql/11/$(replica)
# 3. Connects to primary cluster as user postgres
# 4. Copies the entire data directory
# 5. Creates the file recovery.conf
pg_basebackup -U postgres -d postgresql://localhost:$(primaryPort) -D /var/lib/postgresql/11/$(replica) -P -R
# 6. Inserts the restore_command property and its value
echo "restore_command = 'cp ~/Documents/Severalnines/Archiving/%f %p'" >> /var/lib/postgresql/11/$(replica)/recovery.conf
# 7. The same is done with recovery_target_timeline
echo "recovery_target_timeline = 'latest'" >> /var/lib/postgresql/11/$(replica)/recovery.confQuesto blocco di replica specificato sopra deve essere eseguito dall'utente postgres del sistema operativo, al fine di evitare potenziali conflitti con chi è il proprietario dei dati del cluster, postgres o l'utente root.
Il cluster di replica è ancora in piedi, imbastindolo per avviare correttamente la replica, con il processo del cluster di replica chiamato pg_walreceiver che interagisce con il cluster primario chiamato pg_walsender su una connessione TCP.
# 1. Executes the block ‘replicate’ by passing two parameters
sudo -H -u postgres make replicate replica=replica primaryPort=5433
# 2. Starts the cluster replica
sudo systemctl start [email protected]La verifica dell'integrità di questo modello di replica, denominata Streaming Replication, viene eseguita da una query eseguita sul cluster primario.
# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433Conclusione
In questo blog, abbiamo mostrato come configurare la replica di streaming asincrona tra due cluster PostgreSQL. Ricorda, tuttavia, che esistono vulnerabilità nel codice sopra, ad esempio, non è consigliabile utilizzare l'utente postgres per eseguire tale attività.
La replica di un cluster offre numerosi vantaggi quando viene utilizzato nel modo corretto e ha un facile accesso alle API che interagiscono con i cluster.
