Wussten Sie, dass Sie neben der Web-Benutzeroberfläche von ClusterControl auch eine Befehlszeilenschnittstelle verwenden können, um Ihre PostgreSQL-Instanzen zu verwalten?
ClusterControl unterstützt die PostgreSQL-Streaming-Replikation (sowohl asynchrone als auch synchrone Replikation) sowie eine eigenständige PostgreSQL-Instanz. Wir haben uns nach besten Kräften bemüht, die Befehlszeilenschnittstelle in Bezug auf die verfügbaren Funktionen der Benutzeroberfläche nahe zu bringen.
Warum sollten Sie die CLI verwenden?
Es ermöglicht Ihnen, ein vollständiges Replikationssetup in einem Befehl bereitzustellen, ein Failover durchzuführen oder dem Setup neue Knoten hinzuzufügen. Dies lässt sich sehr gut in Ihren vorhandenen Infrastrukturautomatisierungscode integrieren, der in Ansible, Chef oder Puppet geschrieben ist.
Dieser Blogbeitrag bietet eine exemplarische Vorgehensweise zur Verwaltung eines PostgreSQL-Streaming-Replikationsclusters mit ClusterControl CLI oder s9s.
Beachten Sie, dass die meisten der in diesem Blog-Beitrag gezeigten Funktionen erfordern, dass Sie ClusterControl installiert haben und mit einem gültigen Abonnement ausführen, entweder einer kommerziellen Lizenz oder einer kostenlosen Testlizenz (gültig bis zu 30 Tage nach der Installation von ClusterControl).
Cluster-Bereitstellung und -Import
Bereitstellen eines neuen Clusters
Bevor Sie einen neuen Cluster bereitstellen oder einen vorhandenen PostgreSQL-Cluster in ClusterControl importieren, stellen Sie sicher, dass zuvor passwortloses SSH vom ClusterControl-Knoten zu allen Datenbankknoten konfiguriert wurde. Angenommen, wir möchten eine neue PostgreSQL-Streaming-Replikation mit drei Knoten bereitstellen, führen Sie die folgenden Befehle auf dem ClusterControl-Knoten aus:
$ whoami
root
$ ssh-keygen -t rsa # if you haven't generated SSH key
$ ssh-copy-id 192.168.0.91 # PostgreSQL1
$ ssh-copy-id 192.168.0.92 # PostgreSQL2
$ ssh-copy-id 192.168.0.93 # PostgreSQL3
Überprüfen Sie auf dem ClusterControl-Knoten, ob Sie den folgenden Befehl ohne Kennwort ausführen können:
$ ssh 192.168.0.91 "ls /root"
Wenn Sie den Inhalt des Verzeichnisses sehen können, sind Sie in guter Verfassung. Verwenden Sie als Nächstes die ClusterControl-CLI mit dem Flag --create, um den Cluster bereitzustellen:
$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.91?master;192.168.0.92?slave;192.168.0.93?slave" \
--provider-version='11' \
--db-admin='postgres' \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name='PostgreSQL 11 Streaming Replication' \
--wait
Creating PostgreSQL Cluster
\ Job 259 RUNNING [█▋ ] 15% Installing helper packages
Wir haben den ersten Knoten, 192.168.0.91, als Master festgelegt und der Rest sind Slaves. Da wir bereits passwortloses SSH über den Root-Benutzer konfiguriert haben, haben wir den Betriebssystembenutzer als "root" zusammen mit der entsprechenden SSH-Schlüsseldatei mit dem Flag --os-key-file angegeben. Das Flag --wait bedeutet, dass der Job wartet und den Fortschritt meldet, bis er beendet ist.
Sie können den Bereitstellungsfortschritt auch über die ClusterControl-Benutzeroberfläche unter Aktivität> Jobs> PostgreSQL-Cluster erstellen überwachen :
Sobald die Bereitstellung abgeschlossen ist, können wir die Zusammenfassung des laufenden Clusters anzeigen, indem wir das Flag --stat verwenden:
$ s9s cluster --stat
Importieren eines bestehenden Clusters
Wenn Sie beispielsweise bereits einen PostgreSQL-Streaming-Replikationscluster manuell bereitgestellt haben, können Sie ihn mithilfe des Flags --register in ClusterControl importieren, wie im folgenden Befehl gezeigt:
$ s9s cluster \
--register \
--cluster-type=postgresql \
--nodes="192.168.0.91;192.168.0.92;192.168.0.93" \
--provider-version='11' \
--db-admin='postgres' \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 11" \
--wait
Register PostgreSQL
- Job 263 RUNNING [ █ ] ---% Importing Cluster
ClusterControl stellt dann eine Verbindung zu den angegebenen Knoten her, erkennt die Topologie und registriert den Cluster in ClusterControl. Sie können dies wie oben gezeigt mit dem Befehl 's9s cluster --stat' überprüfen.
Knoten- und Clusterverwaltung
Dienststeuerung
Um einen fortlaufenden Neustart eines Clusters durchzuführen, geben Sie die Cluster-ID an und verwenden Sie das Flag --rolling-restart:
$ s9s cluster --rolling-restart --cluster-id=8 --wait
Rolling Restart
- Job 264 RUNNING [██▊ ] 27% Waiting for 192.168.0.91
Verwenden Sie das Flag --stop für die Komponente "Cluster", um einen Cluster zu stoppen. Um die Jobausgabe anstelle des Fortschrittsbalkens zu sehen, können wir stattdessen das Flag --log verwenden:
$ s9s cluster --stop --cluster-id=8 --log
This is an RPC V2 job (a job created through RPC V2).
The job owner is 'admin'.
Accessing '/.runtime/jobs/jobExecutor' to execute...
Access ok.
Setting cluster to 'SHUTTING_DOWN' state.
192.168.0.91:5432: Stopping PostgreSQL service.
192.168.0.91:5432: Waiting PostgreSQL top stop.
192.168.0.92:5432: Stopping PostgreSQL service.
192.168.0.92:5432: Waiting PostgreSQL top stop.
192.168.0.93:5432: Stopping PostgreSQL service.
192.168.0.93:5432: Waiting PostgreSQL top stop.
Setting cluster to 'STOPPED' state.
Es werden die gleichen Auftragsmeldungen wie die Web-Benutzeroberfläche gemeldet. Ähnlich wie oben verwenden Sie zum Starten eines Clusters einfach das Flag --start (wir verwenden stattdessen das Flag --wait, um den Fortschritt anstelle der Jobprotokolle anzuzeigen):
$ s9s cluster --start --cluster-id=8 --wait
Starting Cluster
\ Job 272 RUNNING [ █ ] ---% Start Cluster
Um den PostgreSQL-Dienst auf einem Datenbankknoten neu zu starten, verwenden wir die „node“-Komponente und das --restart-Flag:
$ s9s node \
--restart \
--cluster-id=8 \
--nodes=192.168.0.92 \
--log
Preparing to restart host.
192.168.0.92:5432: Stopping PostgreSQL service.
192.168.0.92:5432: Waiting to stop.
192.168.0.92:5432: Starting PostgreSQL.
192.168.0.92:5432: The postgresql service was started.
192.168.0.92:5432: Waiting to start.
Um einen PostgreSQL-Knoten zu stoppen und zu starten, wenden Sie einfach denselben Befehl mit dem Flag --stop oder --start an, wie unten gezeigt:
$ s9s node --stop --cluster-id=8 --nodes=192.168.0.92
$ s9s node --start --cluster-id=8 --nodes=192.168.0.92
Beachten Sie, dass diese Aktionen das System nicht neu starten.
Skalierungsknoten
Um einen Knoten aus einem Cluster zu entfernen, verwenden Sie das Flag --remove-node:
$ s9s cluster \
--remove-node \
--nodes=192.168.0.93 \
--cluster-id=8 \
--log
Removing node 192.168.0.93: checking job parameters.
192.168.0.93:5432: Stopping PostgreSQL service.
192.168.0.93:5432: Waiting to stop.
192.168.0.93:5432: removed PostgreSQL Server
Updating load balancers.
Das Hinzufügen eines neuen Knotens funktioniert ähnlich, aber Sie müssen vorher sicherstellen, dass der Knoten über passwortloses SSH erreichbar ist. Konfigurieren Sie es zuerst und fügen Sie dann den Knoten mit dem Flag --add-node hinzu:
$ s9s cluster \
--add-node \
--nodes=192.168.0.93 \
--cluster-id=8 \
--log
addNode: Verifying job parameters.
Found a master candidate: 192.168.0.91:5432, adding 192.168.0.93:5432 as a slave.
Verifying job parameters.
192.168.0.93:5432: Disabling SELinux/Apparmor.
192.168.0.93: Checking firewall.
192.168.0.93: Disabling firewalld.
192.168.0.93: Flushing iptables.
192.168.0.93:5432: Installing new node.
192.168.0.93:5432: Using the master's data directory '/var/lib/pgsql/11/data'.
192.168.0.91: Checking size of '/var/lib/pgsql/11/data'.
192.168.0.91: /var/lib/pgsql/11/data size is 103.00 MiB.
192.168.0.93: Checking free space in '/var/lib/pgsql/11/data'.
192.168.0.93: /var/lib/pgsql/11/data has 34.19 GiB free space.
192.168.0.93:5432: Setting SELinux in permissive mode.
192.168.0.93:5432: Disabling firewall.
192.168.0.93:5432: Tuning OS parameters.
192.168.0.93:5432: Setting vm.swappiness = 1.
192.168.0.93:5432: Installing helper packages.
192.168.0.93: Upgrading nss.
192.168.0.93: Upgrading ca-certificates.
192.168.0.93: Installing net-tools.
192.168.0.93: Installing netcat.
192.168.0.93: Installing nc.
192.168.0.93: Installing socat.
192.168.0.93: Installing perl-Data-Dumper.
192.168.0.93: Installing which.
192.168.0.93: Installing perl-Data-Dumper-Names.
192.168.0.93: Installing psmisc.
192.168.0.93: Installing rsync.
192.168.0.93: Installing libaio.
192.168.0.93: Installing libevent.
192.168.0.93: Installing wget.
192.168.0.93: Installing curl.
192.168.0.93: Installing gnupg2.
192.168.0.93: Installing pigz.
192.168.0.93: Installing bzip2.
192.168.0.93: Installing iproute2.
192.168.0.93: Installing tar.
192.168.0.93: Installing openssl.
192.168.0.93: Upgrading openssl openssl-libs.
192.168.0.93: Finished with helper packages.
192.168.0.93:5432: Using External repositories.
192.168.0.93:5432: Setting up PostgreSQL repositories.
192.168.0.93:5432: Uninstalling old PostgreSQL packages.
192.168.0.93:5432: Installing PostgreSQL 11 packages (centos-7).
192.168.0.93:5432: PostgreSQL installed, init-name: postgresql-11.
192.168.0.93: Updating PostgreSQL port (5432) and directory.
192.168.0.93:5432: Granting remote access to PostgreSQL server.
192.168.0.93:5432: Granting controller (10.0.2.15,192.168.0.19).
192.168.0.93:5432: Updating configuration.
192.168.0.93:5432: Enabling stat_statements plugin.
192.168.0.93:5432: Setting wal options.
192.168.0.93:5432: Performance tuning.
192.168.0.93:5432: Selected workload type: mixed
Detected system memory: 991.18 MiB
Using the following fine-tuning options:
checkpoint_completion_target: 0.9
effective_cache_size: 761229kB
maintenance_work_mem: 63435kB
max_connections: 100
shared_buffers: 253743kB
wal_keep_segments: 32
work_mem: 5074kB
Writing file '192.168.0.93:/var/lib/pgsql/11/data/postgresql.conf'.
192.168.0.93:5432: Restarting PostgreSQL service
192.168.0.93:5432: Testing connection (attempt #1).
192.168.0.93:5432: Connected ok.
192.168.0.93:5432: Using the master's data directory '/var/lib/pgsql/11/data'.
192.168.0.91:5432(master): Verifying PostgreSQL version.
Setting up replication 192.168.0.91:5432->192.168.0.93:5432
Collecting server variables.
192.168.0.91:5432: Using the pg_hba.conf contents for the slave.
192.168.0.93:5432: Updating slave configuration.
Writing file '192.168.0.93:/var/lib/pgsql/11/data/postgresql.conf'.
192.168.0.93:5432: GRANT new node on members to do pg_basebackup.
192.168.0.91:5432: granting 192.168.0.93:5432.
192.168.0.93:5432: Stopping slave.
192.168.0.93:5432: Cleaning up slave data directory: /var/lib/pgsql/11/data
192.168.0.93:5432: detected version: 11.1
192.168.0.93:5432: Doing initial sync (pg_basebackup) from 192.168.0.91:5432.
192.168.0.93:5432: Synchronizing pg_hba.conf from master.
Writing file '192.168.0.93:/var/lib/pgsql/11/data/postgresql.conf'.
192.168.0.93:5432: Creating '/var/lib/pgsql/11/data/recovery.conf': Setting 192.168.0.91:5432 as master.
192.168.0.93:5432: Successfully created '/var/lib/pgsql/11/data/recovery.conf'.
192.168.0.93:5432: Restarting PostgreSQL
192.168.0.93:5432: Grant cluster members on the new node (for failover).
Grant connect access for new host in cluster.
Adding grant on 192.168.0.91:5432.
Adding grant on 192.168.0.92:5432.
192.168.0.93:5432: Waiting until service starts.
192.168.0.93:5432: Registering node.
192.168.0.93:5432: Verifying configuration.
192.168.0.93:5432: Checking 'listen_addresses'.
192.168.0.93:5432: Checking variables.
192.168.0.93:5432: Detected PostgreSQL 11.1.
192.168.0.93:5432: Registering host with host manager.
192.168.0.93:5432: Added host to cluster.
Replication slave job finished.
192.168.0.93: Installing cronie.
192.168.0.91:5432: [postgres] Pulling '/var/lib/pgsql/11/data/postgresql.conf'.
192.168.0.92:5432: [postgres] Pulling '/var/lib/pgsql/11/data/postgresql.conf'.
192.168.0.93:5432: [postgres] Pulling '/var/lib/pgsql/11/data/postgresql.conf'.
Aus den Auftragsprotokollen können wir ersehen, dass der neue Knoten als Slave des Masters bereitgestellt wird, da auf dem Cluster bereits ein Master ausgeführt wird (192.168.0.91). ClusterControl wird dann alle notwendigen Aktionen ausführen und den neuen Knoten entsprechend der gegebenen Rolle vorbereiten.
Wechsel zu einem neuen Master
Um die Umschaltung durchzuführen, wählen Sie einen der Slaves als neuen Master mit dem Flag --promote-slave aus:
$ s9s cluster \
--promote-slave \
--nodes=192.168.0.92 \
--cluster-id=8 \
--log
192.168.0.92:5432: Promoting server to master.
192.168.0.92:5432: Current master is 192.168.0.91:5432.
SERVER HOST_STATUS STATUS ROLE RECEIVE/REPLAY
192.168.0.91 CmonHostOnline NODE_CONNECTED master 0/9000EF0; 0/9000EF0
192.168.0.92 CmonHostOnline NODE_CONNECTED slave 0/9000EF0; 0/9000EF0
192.168.0.93 CmonHostOnline NODE_CONNECTED slave 0/9000EF0; 0/9000EF0
Switching over to 192.168.0.92:5432 (previous master is 192.168.0.91:5432)
192.168.0.91:5432: Stopping the current master.
192.168.0.91:5432: Stopping PostgreSQL service.
192.168.0.91:5432: Waiting to stop.
192.168.0.92:5432: Failover, using file.
192.168.0.92:5432: Waiting to become a master.
192.168.0.92:5432: Became master, ok.
Switching slaves to the new master.
192.168.0.93:5432: Stopping PostgreSQL service.
192.168.0.93:5432: Waiting to stop.
192.168.0.92:5432: Granting host (192.168.0.93:5432).
Running /usr/pgsql-11/bin/pg_rewind --target-pgdata=/var/lib/pgsql/11/data --source-server="host=192.168.0.92 port=5432 user=cmon password=***** dbname=postgres"
192.168.0.93: servers diverged at WAL location 0/9000F60 on timeline 1
no rewind required
192.168.0.93:5432: Creating '/var/lib/pgsql/11/data/recovery.conf': Setting 192.168.0.92:5432 as master.
192.168.0.93:5432: Successfully created '/var/lib/pgsql/11/data/recovery.conf'.
192.168.0.93:5432: Starting PostgreSQL.
192.168.0.93:5432: The postgresql service was started.
192.168.0.93:5432: Waiting to start.
192.168.0.93:5432: Restarted with new master.
192.168.0.91:5432: Stopping PostgreSQL service.
192.168.0.91:5432: Waiting to stop.
192.168.0.92:5432: Granting host (192.168.0.91:5432).
Running /usr/pgsql-11/bin/pg_rewind --target-pgdata=/var/lib/pgsql/11/data --source-server="host=192.168.0.92 port=5432 user=cmon password=***** dbname=postgres"
192.168.0.91: servers diverged at WAL location 0/9000F60 on timeline 1
no rewind required
192.168.0.91:5432: Creating '/var/lib/pgsql/11/data/recovery.conf': Setting 192.168.0.92:5432 as master.
192.168.0.91:5432: Successfully created '/var/lib/pgsql/11/data/recovery.conf'.
192.168.0.91:5432: Starting PostgreSQL.
192.168.0.91:5432: The postgresql service was started.
192.168.0.91:5432: Waiting to start.
192.168.0.91:5432: Restarted with new master.
Servers after promote:
SERVER HOST_STATUS STATUS ROLE RECEIVE/REPLAY
192.168.0.91 CmonHostOnline NODE_CONNECTED slave 0/9001F90; 0/9001F90
192.168.0.92 CmonHostOnline NODE_CONNECTED master 0/9001F90; 0/9001F90
192.168.0.93 CmonHostOnline NODE_CONNECTED slave 0/9001F90; 0/9001F90
192.168.0.92:5432: promote finished (this is the new master).
Successfully promoted a new master.
Die Auftragsmeldungen zeigen, dass ClusterControl zuerst die aktuelle Topologie erkennt und alle Knoten im Cluster stoppt. Dann konfiguriert er den neuen Master und bringt die anderen Knoten dazu, von ihm zu replizieren. Es wird auch versuchen, pg_rewind auszuführen um die PGDATA des heruntergestuften Masters mit einem neuen Basis-Backup neu zu synchronisieren. Am Ende des Jobs meldet ClusterControl die aktuelle Topologie und den Status der Heraufstufung.
Wir können dies dann überprüfen, indem wir alle Knoten für die Cluster-ID 8 auflisten:
$ s9s node --list --cluster-id=8 --long
STAT VERSION CID CLUSTER HOST PORT COMMENT
coC- 1.7.1.2985 8 PostgreSQL 11 192.168.0.19 9500 Up and running.
poS- 11.1 8 PostgreSQL 11 192.168.0.91 5432 Up and running.
poM- 11.1 8 PostgreSQL 11 192.168.0.92 5432 Up and running.
poS- 11.1 8 PostgreSQL 11 192.168.0.93 5432 Up and running.
Der Status "poM-" in der Spalte ganz links hat folgende Bedeutung:
- p - PostgreSQL-Knoten
- o - online
- M - Meister
Datenbankverwaltung
Um alle auf dem Cluster gefundenen Datenbanken aufzulisten, verwenden Sie das Flag --list-database auf dem Komponenten-Cluster:
$ s9s cluster \
--list-database \
--long \
--cluster-id=8
SIZE #TBL #ROWS OWNER GROUP CLUSTER DATABASE
7340032 0 0 system admins PostgreSQL Streaming Replication postgres
7340032 0 0 system admins PostgreSQL Streaming Replication template1
7340032 0 0 system admins PostgreSQL Streaming Replication template0
382730240 12 1156642 system admins PostgreSQL Streaming Replication sbtest
Beachten Sie, dass diese Option einige davon möglicherweise nicht anzeigt, wenn der Cluster über viele Datenbanken verfügt. Das Abtasten einer großen Anzahl von Datenbanken würde eine hohe Last erzeugen, daher hat der Controller eine eingebaute Obergrenze.
Wenn Sie eine neue Datenbank für den Cluster erstellen möchten, tun Sie einfach Folgendes:
$ s9s cluster \
--create-database \
--cluster-id=8 \
--db-name=my_shopping_db
Um einen neuen Datenbankbenutzer zusammen mit einer ihm zugeordneten Datenbank (mit demselben Datenbanknamen) zu erstellen, verwenden Sie das --create-account mit dem Flag --with-database:
$ s9s cluster \
--create-account \
--cluster-id=1 \
--account=mysystem:[email protected] \
--with-database
Account 'mysystem' created.
192.168.0.91:5432: Allowing connections from 192.168.0.15.
192.168.0.92:5432: Allowing connections from 192.168.0.15.
192.168.0.93:5432: Allowing connections from 192.168.0.15.
Database 'mysystem' created.
Access for 'mysystem' to 'mysystem' granted.
ClusterControl führt die erforderlichen Aktionen aus, um die Datenbank und das Benutzerkonto mit den richtigen Berechtigungen zu erstellen und auf allen Datenbankknoten zuzulassen.
Sicherungsverwaltung
ClusterControl unterstützt zwei Backup-Methoden für PostgreSQL:
- pgdump - Alias für pg_dumpall, ein Dienstprogramm zum Schreiben aller PostgreSQL-Datenbanken eines Clusters in eine Skriptdatei.
- pg_basebackup - Ein Dienstprogramm zum Erstellen einer vollständigen Sicherung einer PostgreSQL-Datenbank auf Dateisystemebene.
Erstellen einer Sicherung
Um ein neues Backup mit pg_dumpall zu erstellen, wählen Sie einen Datenbankknoten aus und geben Sie "pgdump" im Flag --backup-method an:
$ s9s backup \
--create \
--backup-method=pgdump \
--cluster-id=8 \
--nodes=192.168.0.92 \
--backup-directory=/storage/backups \
--on-controller
Das Flag --on-controller gibt an, dass die erstellte Sicherung im Verzeichnis /storage/backups auf dem ClusterControl-Knoten gespeichert werden soll. Lassen Sie das Flag weg, wenn Sie es auf dem Datenbankknoten selbst speichern möchten. Derselbe Befehl kann angewendet werden, um eine pg_basebackup-Sicherung zu erstellen. Einfach "pgdump" durch "pg_basebackup" ersetzen würde reichen.
Um das Backup aufzulisten, verwenden Sie einfach die Flags --list und --cluster-id:
$ s9s backup --list --long --cluster-id=8
ID PI CID V I STATE OWNER HOSTNAME CREATED SIZE TITLE
8 - 8 - F COMPLETED admin 192.168.0.92 08:42:47 1204 Untitled Backup Record
9 - 8 - F COMPLETED admin 192.168.0.92 08:45:52 3865462 Untitled Backup Record
Planen einer Sicherung
Das Planen eines Backups ähnelt dem Befehl, den wir zum Erstellen eines Backups verwendet haben, mit dem zusätzlichen Flag --recurrence:
$ s9s backup \
--create \
--backup-method=pg_basebackup \
--cluster-id=8 \
--nodes=192.168.0.92 \
--backup-directory=/storage/backups \
--on-controller \
--recurrence='30 0 * * *'
Der Wiederholungswert muss in Anführungszeichen und im Crontab-Format eingeschlossen werden.
Ein Backup wiederherstellen
Um eine Sicherung in einem Cluster wiederherzustellen, verwenden Sie das Flag --restore und geben Sie die Sicherungs-ID an, die Sie verwenden möchten:
$ s9s backup \
--restore \
--cluster-id=8 \
--backup-id=9 \
--log
192.168.0.19: Checking 'socat' availability.
Stop slaves as restoring offline backup to master.
192.168.0.91:5432: Stopping PostgreSQL service.
192.168.0.91:5432: Waiting to stop.
192.168.0.93:5432: Stopping PostgreSQL service.
192.168.0.93:5432: Waiting to stop.
192.168.0.92:5432: Stopping node for restoring a base-backup.
192.168.0.92:5432: Stopping PostgreSQL service.
192.168.0.92:5432: Waiting to stop.
192.168.0.92:5432: Backing up the current datadir.
192.168.0.92: Mount point of '/var/lib/pgsql/11/data': '/'
192.168.0.92: Creating copy of datadir (using 'mv'): /var/lib/pgsql/11/data_bak
192.168.0.92: Checking 'socat' availability.
192.168.0.92: Starting: su - postgres -c 'socat -u tcp-listen:9999,reuseaddr stdout | tar -C/var/lib/pgsql/11/data -xzf-' 2>&1 > /tmp/netcat.pg.log
192.168.0.92: socat/nc is started.
192.168.0.92: Restoring from '192.168.0.19':'/storage/backups/BACKUP-9/base.tar.gz'
192.168.0.92:5432: Starting node after restored a base-backup.
192.168.0.92:5432: Starting PostgreSQL.
192.168.0.92:5432: The postgresql service was started.
192.168.0.92:5432: Waiting to start.
You may now rebuild your slaves.
Finished restoring.
Checking the cluster.
Setting cluster to 'STARTING' state.
192.168.0.91:5432: Starting PostgreSQL.
192.168.0.91:5432: The postgresql service was started.
192.168.0.93:5432: Starting PostgreSQL.
192.168.0.93:5432: The postgresql service was started.
Cluster is successfully started.
Cluster status is STARTED.
Beachten Sie, dass für die Sicherung von pg_basebackup der Wiederherstellungsvorgang eine Datenbankausfallzeit erfordert. Alle PostgreSQL-Knoten werden vor der Wiederherstellung gestoppt und die Wiederherstellung findet auf dem letzten bekannten Master statt. Dieser Master wird zuerst hochgefahren (gefolgt von allen Slaves), nachdem die Wiederherstellung abgeschlossen ist.
Verifizieren einer Sicherung
Verwenden Sie zum Wiederherstellen und Überprüfen der Sicherung das Flag --verify und geben Sie den Zielserver mit dem Flag --test-server an:
$ s9s backup \
--verify \
--cluster-id=8 \
--backup-id=9 \
--test-server=192.168.0.99 \
--log
Der Testserver darf nicht Teil des Clusters sein und muss über passwortloses SSH vom ClusterControl-Knoten aus erreichbar sein. ClusterControl installiert zuerst den Zielserver mit derselben PostgreSQL-Version, streamt und stellt die Sicherung auf diesem Knoten wieder her. Die Sicherungsüberprüfung sucht nach dem letzten Beendigungscode nach der Wiederherstellung. Wenn die Sicherung wiederherstellbar ist, stoppt ClusterControl den Testserver und entfernt ihn aus ClusterControl (aber ClusterControl fährt ihn nicht herunter). Nach Abschluss des Jobs sollte Folgendes angezeigt werden:
Backup 9 was successfully verified.
Cluster aus Backup erstellen
ClusterControl hat in v1.7.1 eine neue Funktion eingeführt, mit der man einen neuen Cluster basierend auf einer Sicherung erstellen kann, die von einem vorhandenen Cluster erstellt wurde. Dies kann sehr nützlich sein, um Ihre Datenbank auf einer anderen Plattform oder Datenbankversion zu testen. In diesem Beispiel möchten wir einen PostgreSQL 9.6-Cluster mit zwei Knoten basierend auf der Sicherungs-ID 214 bereitstellen:
$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave" \
--provider-version=9.6 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--wait
Beachten Sie, dass das Admin-Benutzerpasswort für den neuen Cluster mit dem PostgreSQL-Admin-Passwort identisch sein muss, das in der Sicherung enthalten ist. Grundsätzlich führt ClusterControl den Bereitstellungsjob in der folgenden Reihenfolge aus:
- Installieren Sie notwendige Software und Abhängigkeiten auf allen PostgreSQL-Knoten.
- Starte den ersten Knoten.
- Backup auf dem ersten Knoten streamen und wiederherstellen (mit Auto-Neustart-Flag).
- Konfigurieren und fügen Sie die restlichen Knoten hinzu.
Anschließend können Sie die Clusterliste mit dem folgenden Befehl überprüfen:
$ s9s cluster --stat
Konfigurationsverwaltung
Um die PostgreSQL-Konfiguration eines Knotens aufzulisten, verwenden Sie das Flag --list-config:
$ s9s node --list-config --cluster-id=8 --nodes=192.168.0.92
GROUP OPTION NAME VALUE
- data_directory '/var/lib/pgsql/11/data'
- listen_addresses '*'
- port 5432
- max_connections 100
- shared_buffers 253743kB
- work_mem 5074kB
- maintenance_work_mem 63435kB
- dynamic_shared_memory_type posix
- wal_level hot_standby
- full_page_writes on
- wal_log_hints on
- max_wal_size 1GB
- min_wal_size 80MB
- checkpoint_completion_target 0.9
- max_wal_senders 16
- wal_keep_segments 32
- hot_standby on
- effective_cache_size 761229kB
- log_destination 'stderr'
- logging_collector on
- log_directory 'log'
- log_filename 'postgresql-%a.log'
- log_truncate_on_rotation on
- log_rotation_age 1d
- log_rotation_size 0
- log_line_prefix '%m [%p] '
- log_timezone 'UTC'
- track_activity_query_size 2048
- datestyle 'iso, mdy'
- timezone 'UTC'
- lc_messages 'en_US.UTF-8'
- lc_monetary 'en_US.UTF-8'
- lc_numeric 'en_US.UTF-8'
- lc_time 'en_US.UTF-8'
- default_text_search_config 'pg_catalog.english'
- shared_preload_libraries 'pg_stat_statements'
- pg_stat_statements.track all
ClusterControl gibt die Ausgabe von OPTION NAME und VALUE entsprechend zurück. Die GROUP-Spalte ist in PostgreSQL nicht anwendbar, daher sollte der Wert „-“ angezeigt werden.
Um eine Konfigurationsoption zu ändern, verwenden Sie das Flag --change-config und geben Sie den Parameter und Wert mit --opt-name bzw. --opt-value an:
$ s9s node \
--change-config \
--nodes=192.168.0.92 \
--opt-name=min_wal_size \
--opt-value='100MB'
192.168.0.92:5432: Changed a read-only parameter. Node restart is required for change to take effect.
Sie sollten sehen, dass ClusterControl den Konfigurationsänderungsstatus zurückgibt und das Folgeverfahren anweist, um sicherzustellen, dass die Konfigurationsänderung wirksam wird. Sie können dann den Befehl "s9s node --restart" verwenden, um den jeweiligen Knoten neu zu starten.
Abschließende Gedanken
ClusterControl bietet große Flexibilität bei der Verwaltung und Überwachung Ihres PostgreSQL-Datenbank-Clusters. Sie haben die Wahl zwischen einer recht einfachen und unkomplizierten Web-Benutzeroberfläche sowie einer Befehlszeilenschnittstelle, die es Ihnen ermöglicht, eine vollständige Datenbankautomatisierung über Skripte zu erreichen. Viel Spaß beim Verwalten!