Erstellen eines PostgreSQL-Replikations-Setups unter Debian / Ubuntu

PostgreSQL kann separat auf mehreren Computern mit derselben Datenstruktur arbeiten, wodurch die Persistenzschicht der Anwendung widerstandsfähiger wird und auf unerwartete Ereignisse vorbereitet ist, die die Kontinuität des Dienstes beeinträchtigen könnten.

Die Idee dahinter ist, die Antwortzeit des Systems zu verbessern, indem die Anfragen in einem „Round Robin“-Netzwerk verteilt werden, in dem jeder vorhandene Knoten ein Cluster ist. Bei dieser Art von Setup ist es nicht wichtig, welcher die Anfragen zur Verarbeitung zugestellt werden, da die Antwort immer gleich wäre.

In diesem Blog erklären wir, wie Sie einen PostgreSQL-Cluster mit den in der Programminstallation bereitgestellten Tools replizieren. Die verwendete Version ist PostgreSQL 11.5, die aktuelle stabile, allgemein verfügbare Version für das Betriebssystem Debian Buster. Für die Beispiele in diesem Blog wird davon ausgegangen, dass Sie bereits mit Linux vertraut sind.

PostgreSQL-Programme

Im Verzeichnis /usr/bin/ befindet sich das Programm, das für die Verwaltung des Clusters verantwortlich ist.

# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_

Aktivitäten, die durch diese Programme durchgeführt werden, können nacheinander oder sogar in Kombination mit anderen Programmen durchgeführt werden. Das Ausführen eines Blocks dieser Aktivitäten über einen einzigen Befehl ist dank eines Linux-Programms namens make.

Um die vorhandenen Cluster aufzulisten, verwenden Sie das Programm pg_lsclusters. Sie können es auch mit make ausführen. Seine Arbeit hängt von einer Datei namens Makefile ab, die sich im selben Verzeichnis befinden muss, in dem der Befehl ausgeführt wird.

# 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 editing

Die Definition eines Blocks mit dem Namen ls und einem einzelnen auszuführenden Programm, pg_lsclusters, wird unten gezeigt.

# 1. Block name
ls:
# 2. Program to be executed
pg_lsclusters

Die Datei Makefile kann mehrere Blöcke enthalten, und jeder kann so viele Programme ausführen, wie Sie benötigen, und sogar Parameter empfangen. Es ist zwingend erforderlich, dass die Zeilen, die zu einem Ausführungsblock gehören, korrekt sind, indem anstelle von Leerzeichen Tabulatoren zum Einrücken verwendet werden.

Die Verwendung von make zum Ausführen des pg_lsclusters-Programms wird durch die Verwendung des make ls-Befehls erreicht.

# 1. Executes pg_lsclusters
make ls

Das Ergebnis einer kürzlich durchgeführten PostgreSQL-Installation bringt einen einzelnen Cluster namens main, der Port 5432 des Betriebssystems zugewiesen ist. Wenn das Programm pg_createcluster verwendet wird, wird dem neu erstellten Cluster ein neuer Port mit dem Wert 5432 als Ausgangspunkt zugewiesen, bis ein anderer in aufsteigender Reihenfolge gefunden wird.

Write-Ahead-Protokollierung (WAL)

Dieses Replikationsverfahren besteht darin, ein Backup eines funktionierenden Clusters zu erstellen, der weiterhin Updates erhält. Wenn dies jedoch auf derselben Maschine erfolgt, gehen viele der Vorteile dieser Technik verloren.

Die horizontale Skalierung eines Systems gewährleistet eine höhere Verfügbarkeit des Dienstes, denn wenn Hardwareprobleme auftreten, würde dies keinen großen Unterschied machen, da andere Computer bereit sind, die Arbeitslast zu übernehmen.

WAL ist der Begriff, der verwendet wird, um einen internen komplexen Algorithmus für PostgreSQL darzustellen, der die Integrität der Transaktionen sicherstellt, die auf dem System durchgeführt werden. Es darf jedoch nur ein einzelner Cluster die Verantwortung haben, darauf mit Schreibberechtigung zuzugreifen.

Die Architektur hat jetzt drei verschiedene Arten von Clustern:

1. Ein Primärer mit der Verantwortung für das Schreiben an WAL;
2. Ein Replikat, das bereit ist, den Hauptposten zu übernehmen;
3. Verschiedene andere Nachbildungen mit WAL-Lesepflicht.

Schreiboperationen sind alle Aktivitäten, die darauf abzielen, die Datenstruktur zu ändern, entweder durch Einfügen neuer Elemente oder Aktualisieren und Löschen bestehender Datensätze.

PostgreSQL-Clusterkonfiguration

Jeder Cluster hat zwei Verzeichnisse, eines mit seinen Konfigurationsdateien und ein anderes mit den Transaktionsprotokollen. Diese befinden sich in /etc/postgresql/11/$(cluster) bzw. /var/lib/postgresql/11/$(cluster) (wobei $(cluster) der Name des Clusters ist).

Die Datei postgresql.conf wird unmittelbar nach der Erstellung des Clusters durch Ausführen des Programms pg_createcluster erstellt, und die Eigenschaften können für die Anpassung eines Clusters geändert werden.

Eine direkte Bearbeitung dieser Datei wird nicht empfohlen, da sie fast alle Eigenschaften enthält. Ihre Werte wurden auskommentiert, wobei das Symbol # am Anfang jeder Zeile steht, und mehrere andere Zeilen, die Anweisungen zum Ändern der Eigenschaftswerte enthalten, sind auskommentiert.

Das Hinzufügen einer weiteren Datei mit den gewünschten Änderungen ist möglich, bearbeiten Sie einfach eine einzelne Eigenschaft namens include und ersetzen Sie den Standardwert #include =‘’ durch include =‘postgresql.replication.conf’.

Bevor Sie den Cluster starten, benötigen Sie die Datei postgresql.replication.conf im gleichen Verzeichnis, in dem Sie die ursprüngliche Konfigurationsdatei namens postgresql.conf finden.

# 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.conf

Die Verwendung von --data-checksums bei der Erstellung des Clusters fügt den Daten ein höheres Maß an Integrität hinzu, was etwas Leistung kostet, aber sehr wichtig ist, um eine Beschädigung der Dateien zu vermeiden von einem Cluster auf einen anderen übertragen.

Die oben beschriebenen Prozeduren können für andere Cluster wiederverwendet werden, indem einfach ein Wert an $(cluster) als Parameter bei der Ausführung des Programms make übergeben wird.

# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primary

Nachdem nun eine kurze Automatisierung der Aufgaben eingerichtet wurde, bleibt noch die Definition der Datei postgresql.replication.conf entsprechend der Notwendigkeit für jeden Cluster.

Replikation auf PostgreSQL

Zwei Möglichkeiten zur Replikation eines Clusters sind möglich, eine vollständig, die andere unter Einbeziehung des gesamten Clusters (als Streaming-Replikation bezeichnet) und eine andere teilweise oder vollständig (als logische Replikation bezeichnet).

Die Einstellungen, die für einen Cluster angegeben werden müssen, fallen in vier Hauptkategorien:

• Master-Server
• Standby-Server
• Sendeserver
• Abonnenten

Wie wir bereits gesehen haben, ist WAL eine Datei, die die Transaktionen enthält, die auf dem Cluster durchgeführt werden, und die Replikation ist die Übertragung dieser Dateien von einem Cluster zum anderen.

Innerhalb der Einstellungen in der Datei postgresql.conf können wir Eigenschaften sehen, die das Verhalten des Clusters in Bezug auf die WAL-Dateien definieren, wie z. B. die Größe dieser Dateien.

# default values
max_wal_size = 1GB
min_wal_size = 80MB

Eine weitere wichtige Eigenschaft namens max_wal_senders. Die Zugehörigkeit zu einem Cluster mit charakteristischen Sendeservern ist die Anzahl der Prozesse, die für das Senden dieser Dateien an andere Cluster verantwortlich sind, und muss immer einen Wert größer sein als die Anzahl der Cluster, die von ihrem Empfang abhängen.

WAL-Dateien können für die Übertragung an einen Cluster gespeichert werden, der sich spät verbindet oder einige Probleme beim Empfang hatte und frühere Dateien in Bezug auf die aktuelle Zeit benötigt, mit der Eigenschaft wal_keep_segments als Spezifikation wie viele WAL-Dateisegmente von einem Cluster verwaltet werden sollen.

Ein Replikations-Slot ist eine Funktion, die es dem Cluster ermöglicht, WAL-Dateien zu speichern, die benötigt werden, um einen anderen Cluster mit allen Datensätzen zu versorgen, wobei die Option max_replication_slots seine Eigenschaft ist.

# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10

Wenn die Speicherung dieser WAL-Dateien ausgelagert werden soll, kann eine andere Methode zur Verarbeitung dieser Dateien verwendet werden, die als kontinuierliche Archivierung bezeichnet wird.

Kontinuierliche Archivierung

Dieses Konzept ermöglicht es Ihnen, die WAL-Dateien mit einem Linux-Programm und zwei Variablen, die den Pfad der Datei und ihren Namen darstellen, wie %p und %f, an einen bestimmten Ort zu leiten. bzw..

Diese Eigenschaft ist standardmäßig deaktiviert, aber ihre Verwendung kann leicht implementiert werden, indem die Verantwortung eines Clusters vom Speichern solch wichtiger Dateien entzogen wird, und kann der Datei postgresql.replication.conf hinzugefügt werden.

# 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]

Nach der Cluster-Initialisierung müssen möglicherweise einige Eigenschaften geändert werden, und es kann ein Neustart des Clusters erforderlich sein. Einige Eigenschaften können jedoch nur neu geladen werden, ohne dass ein vollständiger Neustart eines Clusters erforderlich ist.

Informationen zu solchen Themen erhalten Sie über die Kommentare in der Datei postgresql.conf, die als # erscheinen (Hinweis:Änderung erfordert Neustart).

Wenn dies der Fall ist, lässt sich das Problem einfach mit dem Linux-Programm systemctl beheben, das zuvor zum Starten des Clusters verwendet wurde, wobei nur die Option zum Neustart überschrieben werden muss.

Wenn kein vollständiger Neustart erforderlich ist, kann der Cluster selbst seine Eigenschaften durch eine in sich selbst ausgeführte Abfrage neu zuweisen. Wenn jedoch mehrere Cluster auf demselben Computer ausgeführt werden, muss ein Parameter übergeben werden mit dem Portwert, der dem Cluster auf dem Betriebssystem zugewiesen ist.

# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433

Im obigen Beispiel erfordert die Eigenschaft archive_mode einen Neustart, nicht jedoch archive_command. Sehen wir uns nach dieser kurzen Einführung in dieses Thema an, wie ein Replikat-Cluster diese archivierten WAL-Dateien mit Point-In-Time-Recovery (PITR) sichern kann.

Point-in-Time-Wiederherstellung der PostgreSQL-Replikation

Dieser vielsagende Name ermöglicht es einem Cluster, in seinen Zustand aus einem bestimmten Zeitraum zurückzukehren. Dies erfolgt über eine Eigenschaft namens recovery_target_timeline, die einen Wert im Datumsformat erwartet, z. B. 2019-08-22 12:05 GMT, oder die Zuweisung spätestens, um über die Notwendigkeit einer Wiederherstellung bis zum letzten vorhandenen Datensatz zu informieren.

Das Programm pg_basebackup erstellt bei seiner Ausführung eine Kopie eines Verzeichnisses, das die Daten eines Clusters enthält, an einen anderen Ort. Dieses Programm erhält tendenziell mehrere Parameter, darunter -R, das eine Datei namens recovery.conf im kopierten Verzeichnis erstellt, die wiederum nicht mit den anderen Konfigurationsdateien identisch ist, die zuvor gesehen wurden, wie z. B. postgresql.conf .

Die Datei recovery.conf speichert die Parameter, die bei der Ausführung des Programms pg_basebackup übergeben werden, und ihre Existenz ist für die Implementierung der Streaming-Replikation unerlässlich, da in ihr die Rückwärtsoperation zur kontinuierlichen Archivierung möglich ist durchgeführt werden.

# 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.conf

Dieser oben angegebene Replikationsblock muss vom Postgres-Benutzer des Betriebssystems ausgeführt werden, um potenzielle Konflikte damit zu vermeiden, wer der Eigentümer der Clusterdaten ist, postgres, oder der Benutzer root.

Der Replica-Cluster steht noch und bastelt ihn, um die Replikation erfolgreich zu starten, wobei der Replica-Cluster-Prozess namens pg_walreceiver mit dem primären Cluster namens pg_walsender über eine TCP-Verbindung interagiert.

# 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]

Die Überprüfung des Zustands dieses Replikationsmodells, Streaming-Replikation genannt, wird durch eine Abfrage durchgeführt, die auf dem primären Cluster ausgeführt wird.

# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433

Fazit

In diesem Blog haben wir gezeigt, wie man eine asynchrone Streaming-Replikation zwischen zwei PostgreSQL-Clustern einrichtet. Denken Sie jedoch daran, dass der obige Code Sicherheitslücken enthält. Beispielsweise wird die Verwendung des postgres-Benutzers für eine solche Aufgabe nicht empfohlen.

Die Replikation eines Clusters bietet mehrere Vorteile, wenn sie richtig verwendet wird und einfachen Zugriff auf die APIs hat, die mit den Clustern interagieren.