PostgreSQL HA installieren und konfigurieren
Die unten angegebenen Richtlinien unterstützen die Implementierung des vorherigen Diagramms. Sie sind für die PostgreSQL-Administratoren und Benutzer vorgesehen, die eine PostgreSQL-Bereitstellung mit Hochverfügbarkeit (High Availability, HA) implementieren.
Als Referenz enthält die Beispielbereitstellung von PostgreSQL HA mit Pgpool-II eine exemplarische Vorgehensweise für Downloads, Befehlszeilensequenzen und Skripts, die zum Implementieren dieser Lösung verwendet werden.
Referenzdokumente
Vor der Installation von PostgreSQL müssen Sie alle Installations- und Konfigurationsdokumente lesen und verstehen, einschließlich der Dokumentation für erforderliche Software. Es ist wichtig, die richtigen Einstellungen zu verstehen und anzuwenden, einschließlich Sicherheitsempfehlungen.
Die folgenden Links bieten nützliche Informationen zur Installation und Konfiguration von PostgreSQL HA mit Streaming-Replikation und pgpool-II für die Knotenverwaltung.
PostgreSQL installieren und eine neue Benutzerrolle in PostgreSQL erstellen
Anweisungen zum Installieren und Konfigurieren von PostgreSQL finden Sie im Handbuch ThingWorx installieren. Im Installationshandbuch finden Sie Informationen zur bereitzustellenden Version von ThingWorx. Dieselben Installations- und Konfigurationsaufgaben müssen für alle drei PostgreSQL-Knoten ausgeführt werden.
PostgreSQL-Datenbankskript konfigurieren und ausführen
Anweisungen zum Erstellen der Datenbank in PostgreSQL finden Sie im Handbuch ThingWorx installieren. Im Installationshandbuch finden Sie Informationen zur bereitzustellenden Version von ThingWorx. Dieselben Installations- und Konfigurationsaufgaben müssen für alle drei PostgreSQL-Knoten ausgeführt werden.
Modell-/Datenanbieter-Schemaskript konfigurieren und ausführen
Anweisungen zum Erstellen des ThingWorx Schemas in PostgreSQL finden Sie im Handbuch ThingWorx installieren. Im Installationshandbuch finden Sie Informationen zu der bereitzustellenden Version von ThingWorx. Dieselben Konfigurationsaufgaben müssen für alle drei PostgreSQL-Knoten ausgeführt werden.
Replikationsbenutzer auf allen PostgreSQL-Knoten erstellen
Erstellen Sie einen PostgreSQL-Benutzer zum Verwalten von Replikationsaufgaben auf allen Knoten. Es müssen derselbe Benutzername und dasselbe Passwort verwendet werden.
Replikationsparameter zu allen PostgreSQL-Knoten hinzufügen
Die folgende Tabelle enthält PostgreSQL-Parameter, die die Replikationsdienste steuern.
 |
Die Werte in der Spalte "Konfiguration" spiegeln die Beispielbereitstellung in der Referenzarchitektur wider, können aber für Ihre Umgebung geändert werden. Für viele der Einstellungen in der folgenden Tabelle werden Links bereitgestellt, mit denen Sie die entsprechenden Konfigurationswerte für Ihre Umgebung bestimmen können.
|
|
Einstellung
|
Konfiguration
|
Beschreibung
|
|---|---|---|
|
listen_addresses
|
‘*’
|
Alle Netzwerkschnittstellen überwachen. In einigen Situationen, in denen es mehrere Netzwerkschnittstellen gibt, ist es am besten, dies auf bestimmte Netzwerkschnittstellen einzuschränken.
|
|
Port
|
5432
|
Das ist die standardmäßige Portnummer.
|
|
max_connections
|
200
|
Der Standardwert in PostgreSQL ist 100. Die Standardeinstellung in ThingWorx ist 100 (maxpoolsize). Erhöhen Sie diese Zahl basierend auf der Gesamtzahl der gleichzeitigen Verbindungen, die in der Datenbank erwartet werden. Dies sollte immer größer sein als die Anzahl der Server im Cluster multipliziert mit der maximalen Poolgröße, die in der Datei platform-settings.json für ThingWorx konfiguriert ist.
|
|
shared_buffers
|
1024MB
|
Optionale Leistungsoptimierung. Legt den Arbeitsspeicher fest, den der Datenbankserver für gemeinsam genutzte Arbeitsspeicherpuffer verwendet. Es wird empfohlen, diesen Wert auf ein Viertel des verfügbaren Arbeitsspeichers auf dem Rechner festzulegen. Weitere Informationen finden Sie unter Resource Consumption > Memory.
|
|
work_mem
|
32MB
|
Optionale Leistungsoptimierung. Gibt den Arbeitsspeicher an, der durch interne Sortieroperationen und Hash-Tabellen vor dem Schreiben auf temporäre Festplattendateien verwendet wird. Weitere Informationen finden Sie unter Resource Consumption > Memory. Führen Sie einen Bildlauf nach unten zu work_mem durch.
|
|
maintenance_work_mem
|
512MB
|
Optionale Leistungsoptimierung. Gibt den maximalen Arbeitsspeicher an, der von Wartungsoperationen verwendet werden soll. Weitere Informationen finden Sie unter Resource Consumption > Memory. Diese Option wird unmittelbar nach work_mem angezeigt.
|
|
wal_level
|
enum
|
Optionale Leistungsoptimierung. Gibt den maximalen Arbeitsspeicher an, der von Wartungsoperationen verwendet werden soll. Weitere Informationen finden Sie unter Write Ahead Log > Settings.
|
|
synchronous_commit
|
on
|
Gehen Sie zu Write Ahead Log > Settings, und führen Sie einen Bildlauf zu synchronous_commit (enum) durch.
|
|
archive_mode
|
on
|
|
|
archive_command
|
‘cd .’
|
Gehen Sie zu Write Ahead Log > Archiving, und führen Sie einen Bildlauf nach unten zu archive_command (string) durch.
|
|
max_wal_size
|
10
|
Gehen Sie zu Write Ahead Log, und klicken Sie auf den Link ARCHIVING. Führen Sie einen Bildlauf zu max_wal_size (integer) durch. Weitere Informationen zur WAL-Konfiguration finden Sie unter WAL Configuration in der PostgreSQL 10-Dokumentation.
|
|
synchronous_standby_names
|
node1, node2 oder node2, node0 oder node0, node1
|
Fügen Sie als kommagetrennte Liste den "application_name" des anderen Knotens hinzu, wie in den recovery.conf-Dateien angegeben. Weitere Informationen finden Sie unter "synchronous_commit" im Abschnitt "Settings" von Write Ahead Log.
|
|
hot_standby
|
wahr/falsch
|
Informationen zu diesem Modus finden Sie unter Hot Standby.
|
|
fsync
|
on
|
Gehen Sie zu Write Ahead Log > Settings, und führen Sie einen Bildlauf nach unten zu fsync durch.
|
|
Checkpoint-Einstellungen
|
Unter Checkpoints finden Sie Information zu den Checkpoint-Einstellungen.
|
start_replication- und retargetMaster-Skripts einrichten
Erstellen Sie auf jedem Knoten ein Skript, um Replikationsdienste zu aktivieren, und stellen Sie sicher, dass der PostgreSQL-Knoten mit dem System synchron ist.
Erstellen Sie außerdem auf jedem Knoten ein Skript, das eine recovery.conf-Datei erstellen und implementieren kann. Die Datei recovery.conf sollte die Änderungen enthalten, die erforderlich sind, um je nach auftretendem Fehler zu ändern, welcher Knoten Masterknoten und welcher Standby-Knoten ist.
Externe Verbindungsparameter an alle PostgreSQL-Knoten anpassen
Ändern Sie die Parameter in jeder Datei pg_hba.conf, damit Benutzer und Datenbank die ThingWorx Daten speichern können, auf die über die IP zugegriffen werden soll. Diese IP stellt eine Verbindung mit der Datenbank her.
|
|
Wenn Sie eine Verbindung von pgpool-II herstellen, überprüfen Sie, ob der Authentifizierungszugriff der hier dokumentierten pgpool-II-Dokumentation (md5 oder trust) entspricht.
|
Weitere Informationen zur Datei pg_hba.conf finden Sie unter "The pg_hba.conf File" in der PostgreSQL 10-Dokumentation.
PostgreSQL-Dienste zum Initiieren der Replikation neu starten
Starten Sie alle PostgreSQL-Knoten in einer Sequenz neu, um zu steuern, welcher Knoten der Masterknoten (zuerst gestartet), welcher der primäre Standby-Knoten (als zweiter Knoten gestartet) und welcher der dritte Knoten (zuletzt gestartet) ist.
Starten Sie für den Masterknoten die PostgreSQL-Dienste.
Führen Sie für den primären Standby-Knoten zuerst das Skript start_replication aus, um es mit dem Masterknoten zu synchronisieren. Starten Sie dann die PostgreSQL-Dienste.
Führen Sie für den zweiten Standby-Knoten zuerst das Skript start_replication aus, um es mit dem primären Standby-Knoten zu synchronisieren. Starten Sie dann die PostgreSQL-Dienste.
pgpool-II-Knoten installieren
Vor der Installation von pgpool müssen Sie alle Installationsdokumente lesen und verstehen, einschließlich Dokumentation für erforderliche Software. Es ist wichtig, die richtigen Einstellungen zu verstehen und anzuwenden, einschließlich Sicherheitsempfehlungen.
Download-Informationen für pgpool-II finden Sie hier:
Anweisungen zur Installation von pgpool-II finden Sie in der Dokumentation zum Betriebssystem. Dieselbe Version von pgpool-II sollte auf allen Knoten installiert sein, auf denen pgpool-II-Dienste ausgeführt werden sollen.
pgpool-II-Knoten konfigurieren
Die folgende Tabelle enthält die Parameter, die für eine pgpool-II-Installation zu ändern sind. Alle pgpool-II-Parameter werden in der Datei pgpool.conf beibehalten. Diese Eigenschaften und Werte müssen allen pgpool-II-Knoten hinzugefügt werden.
|
Einstellung
|
Wert
|
Beschreibung
|
||
|---|---|---|---|---|
|
listen_addresses
|
‘*’
|
Wählen Sie Werte, die es dem Modellanbieter der ThingWorx Anwendung ermöglichen, eine Verbindung zu pgpool-II herzustellen, unabhängig davon, ob er sich auf demselben oder auf einem anderen Server befindet.
|
||
|
port
|
5432
|
TCP-Port zum Überwachen von Client-Verbindungen
|
||
|
pcp_listen_address
|
*
|
IP-/Host-Filter für Port Control Protocol(PCP)-Verbindungen (* lässt alle zu)
|
||
|
pcp_port
|
9898
|
TCP-Port zum Überwachen von PCP-Verbindungen
|
||
|
backend_hostname
backend_port
backend_weight
backend_data_directory
backend_flag
|
<ip of backend#>
<port of backend#>
1
/var/lib/postgresql/10.x/main
ALLOW_TO_FAILOVER
|
Legen Sie diese Backend-Konfigurationswerte für jeden Ihrer drei Knoten fest (Master und zwei Standby-Knoten). Beispielsweise ist backend_hostname0 Ihr Master, backend_hostname1 ist Standby 1 und so weiter. Weitere Informationen finden Sie in der PostgreSQL-Online-Dokumentation.
|
||
|
enable_pool_hba
|
on
|
Aktiviert pool_hba.conf
|
||
|
master_slave_mode
|
on
|
Dies informiert PostgreSQL, dass Sie die Master-/Standby-Replikation verwenden.
|
||
|
load_balance_mode
|
off
|
|
||
|
master_slave_sub_mode
|
stream
|
Dies weist pgpool-II an, die vordefinierte PostgreSQL-Streaming-Replikation zu verwenden.
|
||
|
replication_mode
|
off
|
Verwenden Sie nicht die Replikation von pgpool-II, sondern verwenden Sie stattdessen die vordefinierte PostgreSQL-Streaming-Replikation.
|
||
|
sr_check_period
|
10
|
Streaming-Replikationsverzögerung in Sekunden
|
||
|
sr_check_user
|
replicator
|
Benutzer für Streaming-Replikation
|
||
|
sr_check_password
|
replicator
|
Passwort für Streaming-Replikation
|
||
|
sr_check_database
|
postgres
|
Streaming-Replikationsdatenbank
|
||
|
health_check_user
|
postgres
|
Benutzer für Failover-Integritätsprüfung
|
||
|
health_check_password
|
postgres
|
Passwort für Failover-Integritätsprüfung
|
||
|
health_check_database
|
postgres
|
Datenbank für Failover-Integritätsprüfung
|
||
|
failover_command
|
/etc/pgpool2/failover.sh %d %h %D %m %H %R %M %P
|
Weitere Informationen zu dieser Einstellung finden Sie im Abschnitt "failover_command" weiter unten.
Siehe auch die folgenden Beispielskripts in Anhang C:
• failover.sh
• retargetMaster_001.sh
• retargetMaster_002.sh
• retargetMaster_003.sh
|
||
|
num_init_children
max_pool
max_child_connections
superuser_reserved_connections
|
Leistungsoptimierungsparameter. Diese Einstellungen beziehen sich auf die Verbindungs-Pooling-Funktionen von pgpool-II. Stellen Sie sicher, dass beim Start so viele Verbindungen bereitgestellt werden, wie für Ihre spezifischen Anforderungen an den höchsten Volume-Datenverkehrsdurchsatz erforderlich sind, und dass die Einstellung für maximale Verbindungen der PostgreSQL-DB-Knoten nicht überschritten wird. Im Abschnitt "Pools" des Handbuchs (siehe Link oben) finden Sie Vorschläge sowie Formeln zum Berechnen von Werten.
|
PostgreSQL-Failover-Skript konfigurieren
Erstellen Sie ein Failover-Skript innerhalb jedes pgpool-II-Knotens, das der pgpool-II-Dienst bei der Fehlererkennung aufruft. Dieses Skript muss die Logik und Aufgaben enthalten, die für jeden PostgreSQL-Knotenfehler ausgeführt werden sollen.
Weitere Informationen finden Sie im Abschnitt "Failover" der PostgreSQL 10-Online-Dokumentation.
PCP-Konfiguration aktualisieren
Aktualisieren Sie die Datei pool_hba.conf, damit alle ThingWorx Server erkannt werden.
Für ThingWorx Anfragen an PostgreSQL stellt pgpool-II mithilfe der ThingWorx Anmeldeinformationen eine Verbindung zu den PostgreSQL-Knoten her, um die festgelegten Zugriffsberechtigungen und -beschränkungen beizubehalten. Die Datei pool_hba.conf verwendet dasselbe Format sowie dieselben Authentifizierungsmethoden und -optionen (md5, trust usw.) wie pg_hba.conf.
Weitere Informationen zum Konfigurieren von pool_hba.conf finden Sie unter http://www.pgpool.net/docs/latest/en/html/client-authentication.html.
Clientauthentifizierung aktualisieren
Aktualisieren Sie die Datei pool_hba.conf, damit alle ThingWorx Server erkannt werden.
Für ThingWorx Anfragen an PostgreSQL stellt pgpool-II mithilfe der ThingWorx Anmeldeinformationen eine Verbindung zu den PostgreSQL-Knoten her, um die festgelegten Zugriffsberechtigungen und -beschränkungen beizubehalten. Die Datei pool_hba.conf verwendet dasselbe Format sowie dieselben Authentifizierungsmethoden und -optionen (MD5, trust usw.) wie pg_hba.conf.
Weitere Informationen zum Konfigurieren von pool_hba.conf finden Sie unter http://www.pgpool.net/docs/latest/en/html/client-authentication.html.
pgpool-II für Failover konfigurieren
In Konfigurationen mit Hochverfügbarkeit arbeitet pgpool-II im aktiven/passiven Betrieb, in der Regel mit einem aktiven pgpool-II-Knoten und einem Standby-Knoten. pgpool-II stellt den Watchdog-Prozess zur Überwachung der Knotenintegrität bereit und aktiviert den Standby-Knoten bei einem Ausfall des primären Knotens.
Weitere Informationen und die Konfiguration von Watchdog finden Sie in der pgpool-Dokumentation (http://www.pgpool.net/docs/latest/en/html/example-watchdog.html).
Die folgende Tabelle enthält Einstellungen und Werte, die beim Konfigurieren von Watchdog in pgpool-II zu bedenken sind. Diese Einstellungen und Werte sollten der Datei pgpool.conf jedes pgpool-II-Knotens hinzugefügt werden.
|
Einstellung
|
Wert
|
Beschreibung
|
|---|---|---|
|
use_watchdog
|
on
|
Aktiviert Watchdog in pgpool-II
|
|
wd_hostname
|
'{IP address of this Pgpool-II node}'
|
Hostname oder IP-Adresse dieses Watchdogs
|
|
wd_port
|
9000
|
Portnummer dieses Watchdogs
|
|
delegate_IP
|
'{Virtual IP address to access PostgreSQL}'
|
Virtuelle IP-Adresse, die Clients für den Zugriff auf PostgreSQL (über pgpool-II) verwenden
|
|
ifconfig_path
|
/etc/pgpool2
|
Absoluter Pfad des Verzeichnisses, das die Befehle oder Skripts "if_up_cmd" und "if_down_cmd" enthält.
|
|
if_up_cmd
|
'ifup.sh $_IP_$ <eni id of Pgpool node>'
|
Befehl, der ausgegeben wird, wenn pgpool-II versucht, die virtuelle IP-Schnittstelle mit der "delegate_IP"-Adresse aufzurufen. Sie können die ENI-ID des pgpool-II-Knotens abrufen, indem Sie sich bei der EC2-Verwaltungskonsole anmelden und zu Ihrer pgpool-II-Instanz wechseln. Suchen Sie in der Beschreibung in der Konsole nach dem Eintrag Network interfaces, klicken Sie auf eth0, und suchen Sie die Schnittstellen-ID. Verwenden Sie sie für $<eni id of Pgpool node>.
|
|
if_down_cmd
|
'ifdown.sh $_IP_$ <eni id of Pgpool node>'
|
Befehl, der ausgegeben wird, wenn pgpool-II versucht, die virtuelle IP-Schnittstelle mit der "delegate_IP"-Adresse herunterzufahren. Unter "if_up_cmd" finden Sie die ENI-ID des pgpool-II-Knotens.
|
|
arping_path
|
/usr/bin
|
Pfad des iputils-arping-Installationspakets
|
|
arping_cmd
|
arping -U $_IP_$ -w 1
|
arping-Befehl, mit dem die IPs verifiziert werden.
|
|
heartbeat_destination0
|
'{IP address of the other Pgpool-II node}'
|
IP-Adresse, für die die Heartbeat-Prüfung vorgenommen wird. Der Wert der other_pgpool_hostname0-Einstellung.
|
|
heartbeat_destination_port0
|
9694
|
Verwenden Sie den Standardwert.
|
|
heartbeat_device
|
'eth0'
|
NIC-Gerät für die IP-Adresse für die Heartbeat-Kommunikation
|
|
other_pgpool_hostname0
|
'{IP address of the other Pgpool-II node}'
|
IP-Adresse der anderen pgpool-II-Serverinstanz
|
|
other_pgpool_port0
|
5432
|
Port, den der andere pgpool-II-Knoten überwacht
|
|
other_wd_port0
|
9000
|
Port, den die andere pgpool-II-Watchdog-Funktion überwacht
|