Jak zarządzać bazami danych PostgreSQL z poziomu ClusterControl CLI

Czy wiesz, że oprócz internetowego interfejsu użytkownika ClusterControl możesz również używać interfejsu wiersza poleceń do zarządzania instancjami PostgreSQL?

ClusterControl obsługuje replikację strumieniową PostgreSQL (zarówno asynchroniczną, jak i synchroniczną), a także samodzielną instancję PostgreSQL. Dołożyliśmy wszelkich starań, aby interfejs wiersza poleceń był zbliżony do interfejsu użytkownika pod względem dostępnych funkcji.

Dlaczego chcesz używać CLI?

Umożliwia wdrożenie całej konfiguracji replikacji za pomocą jednego polecenia, wykonanie przełączenia awaryjnego lub dodanie nowych węzłów do konfiguracji. To bardzo dobrze integruje się z istniejącym kodem automatyzacji infrastruktury napisanym w Ansible, Chef lub Puppet.

Ten wpis na blogu zawiera przewodnik dotyczący zarządzania klastrem replikacji strumieniowej PostgreSQL za pomocą ClusterControl CLI lub s9s.

Zwróć uwagę, że większość funkcji przedstawionych w tym poście na blogu wymaga zainstalowania i uruchomienia ClusterControl z ważną subskrypcją, licencją komercyjną lub bezpłatną licencją próbną (ważną do 30 dni po instalacji ClusterControl).

Wdrażanie i importowanie klastrów

Wdrażanie nowego klastra

Przed wdrożeniem nowego klastra lub zaimportowaniem istniejącego klastra PostgreSQL do ClusterControl upewnij się, że wcześniej skonfigurowano bezhasłowe SSH z węzła ClusterControl do wszystkich węzłów bazy danych. Załóżmy, że chcielibyśmy wdrożyć nową trzywęzłową replikację strumieniową PostgreSQL, uruchom następujące polecenia w węźle ClusterControl:

$ 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

W węźle ClusterControl sprawdź, czy możesz wykonać następujące polecenie bez hasła:

$ ssh 192.168.0.91 "ls /root"

Jeśli widzisz zawartość katalogu, jesteś w dobrej formie. Następnie użyj ClusterControl CLI z flagą --create, aby wdrożyć klaster:

$ 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

Określiliśmy pierwszy węzeł, 192.168.0.91 jako nadrzędny, a reszta to podrzędne. Ponieważ skonfigurowaliśmy już SSH bez hasła przez użytkownika root, określiliśmy użytkownika systemu operacyjnego jako „root” wraz z odpowiednim plikiem klucza SSH za pomocą flagi --os-key-file. Flaga --wait oznacza, że zadanie będzie czekać i zgłosi postęp aż do zakończenia.

Możesz również monitorować postęp wdrażania z interfejsu użytkownika ClusterControl w sekcji Aktywność> Zadania> Tworzenie klastra PostgreSQL :

Po zakończeniu wdrażania możemy zobaczyć podsumowanie działającego klastra za pomocą flagi --stat:

$ s9s cluster --stat

Importowanie istniejącego klastra

Jeśli załóżmy, że masz już ręcznie wdrożony klaster strumieniowej replikacji PostgreSQL, możesz go zaimportować do ClusterControl za pomocą flagi --register, jak pokazano w następującym poleceniu:

$ 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 połączy się następnie z określonymi węzłami, odkryje topologię i zarejestruje klaster w ClusterControl. Możesz to zweryfikować za pomocą polecenia 's9s cluster --stat', jak pokazano powyżej.

Zarządzanie węzłem i klastrem

Kontrola usług

Aby wykonać stopniowe ponowne uruchomienie klastra, określ identyfikator klastra i użyj flagi --rolling-restart:

$ s9s cluster --rolling-restart --cluster-id=8 --wait
Rolling Restart
- Job 264 RUNNING    [██▊       ]  27% Waiting for 192.168.0.91

Użyj flagi --stop dla składnika „cluster”, aby zatrzymać klaster. Aby zobaczyć wynik zadania zamiast paska postępu, możemy zamiast tego użyć flagi --log:

$ 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.

Zgłosi te same komunikaty o zadaniach, co internetowy interfejs użytkownika. Podobnie jak powyżej, aby uruchomić klaster, po prostu użyj flagi --start (zamiast tego używamy flagi --wait, aby zobaczyć postęp zamiast dzienników zadań):

$ s9s cluster --start --cluster-id=8 --wait
Starting Cluster
\ Job 272 RUNNING    [     █    ] ---% Start Cluster

Aby ponownie uruchomić usługę PostgreSQL na węźle bazy danych, używamy komponentu „node” i flagi --restart:

$ 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.

Aby zatrzymać i uruchomić węzeł PostgreSQL, po prostu zastosuj to samo polecenie z flagą --stop lub --start, jak pokazano poniżej:

$ s9s node --stop --cluster-id=8 --nodes=192.168.0.92
$ s9s node --start --cluster-id=8 --nodes=192.168.0.92

Pamiętaj, że te działania nie spowodują ponownego uruchomienia systemu.

Skalowanie węzła

Aby usunąć węzeł z klastra, użyj flagi --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.

Dodawanie nowego węzła działa podobnie, ale musisz wcześniej upewnić się, że węzeł jest dostępny przez SSH bez hasła. Skonfiguruj go najpierw, a następnie dodaj węzeł za pomocą flagi --add-node:

$ 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'.

Z dzienników zadań widać, że ponieważ klaster ma już działający master (192.168.0.91), nowy węzeł zostanie wdrożony jako slave do mastera. ClusterControl wykona następnie wszystkie niezbędne działania i odpowiednio przygotuje nowy węzeł jako przypisaną rolę.

Przełącz się na nowego mistrza

Aby dokonać przełączenia, wybierz jednego z urządzeń podrzędnych na nowego mastera z flagą --promote-slave:

$ 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.

Komunikaty zadania pokazują, że ClusterControl najpierw wykryje bieżącą topologię i zatrzyma wszystkie węzły w klastrze. Następnie konfiguruje nowego mastera i nakazuje innym węzłom replikację z niego. Będzie również próbował uruchomić pg_rewind aby ponownie zsynchronizować PGDATA z obniżoną wersją mastera z nową podstawową kopią zapasową. Po zakończeniu zadania ClusterControl zgłasza aktualną topologię i stan promocji.

Następnie możemy zweryfikować, wypisując wszystkie węzły dla klastra o identyfikatorze 8:

$ 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.

Stan „poM-” w skrajnej lewej kolumnie ma następujące znaczenie:

p — węzeł PostgreSQL
o - online
M - mistrz

Zarządzanie bazą danych

Aby wyświetlić listę wszystkich baz danych znalezionych w klastrze, użyj flagi --list-database w klastrze komponentów:

$ 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

Zwróć uwagę, że jeśli klaster ma wiele baz danych, ta opcja może nie wyświetlać niektórych z nich. Próbkowanie ogromnej liczby baz danych generowałoby duże obciążenie, dlatego kontroler ma wbudowany górny limit.

Jeśli chcesz utworzyć nową bazę danych dla klastra, po prostu wykonaj:

$ s9s cluster \
--create-database \
--cluster-id=8 \
--db-name=my_shopping_db

Aby utworzyć nowego użytkownika bazy danych, wraz z powiązaną z nim bazą danych (przy użyciu tej samej nazwy bazy danych), użyj opcji --create-account z 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 wykona niezbędne działania, aby utworzyć bazę danych i konto użytkownika z odpowiednimi uprawnieniami i zezwoli na to na wszystkich węzłach bazy danych.

Zarządzanie kopiami zapasowymi

ClusterControl obsługuje dwie metody tworzenia kopii zapasowych dla PostgreSQL:

pgdump — alias do pg_dumpall, narzędzie do zapisywania wszystkich baz danych PostgreSQL klastra w jednym pliku skryptu.
pg_basebackup — narzędzie do tworzenia pełnej kopii zapasowej bazy danych PostgreSQL na poziomie systemu plików.

Tworzenie kopii zapasowej

Aby utworzyć nową kopię zapasową za pomocą pg_dumpall, wybierz jeden węzeł bazy danych i określ „pgdump” w opcji --backup-method:

$ s9s backup \
--create \
--backup-method=pgdump \
--cluster-id=8 \
--nodes=192.168.0.92 \
--backup-directory=/storage/backups \
    --on-controller

Flaga --on-controller wskazuje, że chcemy, aby utworzona kopia zapasowa była przechowywana w katalogu /storage/backups w węźle ClusterControl. Pomiń flagę, jeśli chcesz przechowywać ją w samym węźle bazy danych. To samo polecenie można zastosować do utworzenia kopii zapasowej pg_basebackup. Wystarczy zamienić „pgdump” na „pg_basebackup”.

Aby wyświetlić listę kopii zapasowej, po prostu użyj flag --list i --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

Planowanie kopii zapasowej

Planowanie kopii zapasowej jest podobne do polecenia, którego użyliśmy do utworzenia kopii zapasowej, z dodatkową 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 * * *'

Wartość recurrence musi być ujęta w cudzysłów i w formacie crontab.

Przywracanie kopii zapasowej

Aby przywrócić kopię zapasową do klastra, użyj flagi --restore i wskaż identyfikator kopii zapasowej, którego chcesz użyć:

$ 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.

Zwróć uwagę, że w przypadku kopii zapasowej pg_basebackup operacja przywracania wymaga przestoju bazy danych. Wszystkie węzły PostgreSQL zostaną zatrzymane przed przywróceniem, a przywracanie nastąpi na ostatnim znanym serwerze głównym. Ten master zostanie przywrócony jako pierwszy (a następnie wszystkie slave) po zakończeniu przywracania.

Weryfikacja kopii zapasowej

Aby przywrócić i zweryfikować kopię zapasową, użyj flagi --verify i określ serwer docelowy za pomocą flagi --test-server:

$ s9s backup \
--verify \
--cluster-id=8 \
--backup-id=9 \
--test-server=192.168.0.99 \
--log

Serwer testowy nie może być częścią klastra i musi być dostępny przez SSH bez hasła z węzła ClusterControl. ClusterControl najpierw zainstaluje serwer docelowy z tą samą wersją PostgreSQL, prześle strumieniowo i przywróci kopię zapasową na tym węźle. Weryfikacja kopii zapasowej szuka ostatniego kodu wyjścia po przywróceniu. Jeśli kopię zapasową można przywrócić, ClusterControl zatrzyma serwer testowy i usunie go z ClusterControl (ale ClusterControl nie wyłączy go). Po zakończeniu zadania powinieneś zobaczyć następujące informacje:

Backup 9 was successfully verified.

Utwórz klaster z kopii zapasowej

ClusterControl wprowadził nową funkcję w wersji 1.7.1, w której można utworzyć nowy klaster na podstawie kopii zapasowej wykonanej przez istniejący klaster. Może to być bardzo przydatne do testowania bazy danych na innej platformie lub innej wersji bazy danych. W tym przykładzie chcielibyśmy wdrożyć dwuwęzłowy klaster PostgreSQL 9.6 w oparciu o identyfikator kopii zapasowej 214:

$ 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

Zwróć uwagę, że hasło administratora dla nowego klastra musi być identyczne z hasłem administratora PostgreSQL zawartym w kopii zapasowej. Zasadniczo ClusterControl wykonuje zadanie wdrożenia w następującej kolejności:

Zainstaluj niezbędne oprogramowanie i zależności na wszystkich węzłach PostgreSQL.
Uruchom pierwszy węzeł.
Przesyłaj strumieniowo i przywracaj kopię zapasową w pierwszym węźle (z flagą automatycznego restartu).
Skonfiguruj i dodaj resztę węzłów.

Następnie możesz zweryfikować listę klastrów za pomocą następującego polecenia:

$ s9s cluster --stat

Zarządzanie konfiguracją

Aby wyświetlić konfigurację PostgreSQL węzła, użyj flagi --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 zwraca odpowiednio dane wyjściowe NAZWA OPCJI i WARTOŚĆ. Kolumna GROUP nie ma zastosowania w PostgreSQL, dlatego powinna być widoczna wartość „-”.

Aby zmienić opcję konfiguracji, użyj flagi --change-config i określ parametr i wartość odpowiednio za pomocą --opt-name i --opt-value:

$ 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.

Powinieneś zobaczyć, jak ClusterControl zwraca status modyfikacji konfiguracji i doradza procedurę kontrolną, aby upewnić się, że zmiana konfiguracji wpłynie. Następnie możesz użyć polecenia „s9s node --restart”, aby zrestartować dany węzeł.

Ostateczne myśli

ClusterControl oferuje dużą elastyczność, jeśli chodzi o zarządzanie i monitorowanie klastra bazy danych PostgreSQL. Masz do wyboru interfejs sieciowy, który jest dość prosty i bezpośredni, oraz interfejs wiersza poleceń, który umożliwia osiągnięcie pełnej automatyzacji bazy danych za pomocą skryptów. Miłego zarządzania!