Как да управлявате вашите PostgreSQL бази данни от ClusterControl CLI

Знаете ли, че освен уеб потребителския интерфейс на ClusterControl, можете да използвате и интерфейс на командния ред, за да управлявате вашите PostgreSQL екземпляри?

ClusterControl поддържа поточно репликация на PostgreSQL (както асинхронна, така и синхронна репликация), както и самостоятелен екземпляр на PostgreSQL. Положихме всичко възможно интерфейсът на командния ред да бъде близък до потребителския интерфейс по отношение на наличната функционалност.

Защо искате да използвате CLI?

Позволява ви да разположите цяла настройка за репликация с една команда или да извършите отказ, или да добавите нови възли към настройката. Това се интегрира много добре със съществуващия ви код за автоматизация на инфраструктурата, написан на Ansible, Chef или Puppet.

Тази публикация в блога предоставя инструкции как да управлявате клъстер за поточно репликация на PostgreSQL с помощта на ClusterControl CLI или s9s.

Обърнете внимание, че повечето от функционалностите, показани в тази публикация в блога, изискват да имате инсталиран ClusterControl и да работи с валиден абонамент, или търговски лиценз, или безплатен пробен лиценз (валиден до 30 дни след инсталирането на ClusterControl).

Разгръщане и импортиране на клъстер

Разгръщане на нов клъстер

Преди да разположите нов клъстер или да импортирате съществуващ PostgreSQL клъстер в ClusterControl, уверете се, че SSH без парола от възела на ClusterControl към всички възли на базата данни е конфигуриран предварително. Да предположим, че искаме да разположим нова поточно репликация на PostgreSQL с три възела, изпълнете следните команди на възел 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

На възела ClusterControl проверете дали можете да изпълните следната команда без парола:

$ ssh 192.168.0.91 "ls /root"

Ако можете да видите съдържанието на директорията, вие сте в добра форма. След това използвайте ClusterControl CLI с флага --create, за да разположите клъстера:

$ 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

Ние посочихме първия възел, 192.168.0.91 като главен, а останалите са подчинени. Тъй като вече конфигурирахме SSH без парола чрез root потребител, посочихме потребителя на ОС като "root" заедно със съответния ключов файл за SSH, използвайки флага --os-key-file. Флагът --wait означава, че задачата ще изчака и ще докладва напредъка, докато приключи.

Можете също да наблюдавате напредъка на внедряването от потребителския интерфейс на ClusterControl под Дейност> Работни места> Създаване на PostgreSQL клъстер :

След като внедряването завърши, можем да видим обобщението на работещия клъстер, като използваме флага --stat:

$ s9s cluster --stat

Импортиране на съществуващ клъстер

Ако да кажем, че вече имате клъстер за поточно репликация на PostgreSQL, разгърнат ръчно, можете да го импортирате в ClusterControl с помощта на флага --register, както е показано в следната команда:

$ 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 ще се свърже с посочените възли, ще открие топологията и ще регистрира клъстера в ClusterControl. Можете да потвърдите с командата 's9s cluster --stat', както е показано по-горе.

Управление на възли и клъстери

Управление на услугите

За да извършите непрекъснато рестартиране на клъстер, посочете идентификатора на клъстера и използвайте флага --rolling-restart:

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

Използвайте флага --stop за компонент "клъстер", за да спрете клъстер. За да видим изхода на заданието вместо лентата за напредък, можем да използваме флага --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.

Той ще докладва същите съобщения за работа като уеб потребителския интерфейс. Подобно на горното, за да стартирате клъстер, просто използвайте флага --start (вместо това използваме флага --wait, за да видите напредъка вместо журналите на заданията):

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

За да рестартирате услугата PostgreSQL на възел на база данни, ние използваме компонента "node" и флага --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.

За да спрете и стартирате възел на PostgreSQL, просто приложете същата команда с флага --stop или --start, както е показано по-долу:

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

Обърнете внимание, че тези действия няма да рестартират системата.

Мащабиращ възел

За да премахнете възел от клъстер, използвайте флага --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.

Добавянето на нов възел работи по подобен начин, но трябва предварително да се уверите, че възелът е достъпен чрез SSH без парола. Първо го конфигурирайте и след това добавете възела, като използвате флага --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'.

От дневниците на заданията можем да видим, че тъй като клъстерът вече има работещ главен (192.168.0.91), новият възел ще бъде разгърнат като подчинен на главния. След това ClusterControl ще извърши всички необходими действия и съответно ще подготви новия възел като дадената роля.

Превключете към нов главен

За да извършите превключването, изберете един от подчинените, за да стане новият главен с флаг --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.

Съобщенията за задание показват, че ClusterControl първо ще открие текущата топология и ще спре всички възли в клъстера. След това конфигурира новия главен обект и кара другите възли да се репликират от него. Също така ще се опита да изпълни pg_rewind за повторно синхронизиране на PGDATA на понижения главен файл с ново резервно копие на базата. В края на заданието ClusterControl отчита текущата топология и състоянието на повишението.

След това можем да проверим, като изброим всички възли за клъстер ID 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.

Състоянието "poM-" в най-лявата колона има следното значение:

p - PostgreSQL възел
o - онлайн
M - майстор

Управление на база данни

За да изброите всички бази данни, открити в клъстера, използвайте флага --list-database на компонентния клъстер:

$ 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

Обърнете внимание, че ако клъстерът има много бази данни, тази опция може да не показва някои от тях. Вземането на проби от огромен брой бази данни би генерирало голямо натоварване и така контролерът има вградена горна граница.

Ако искате да създадете нова база данни за клъстера, просто направете:

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

За да създадете нов потребител на база данни, заедно с свързана с него база данни (използвайки същото име на база данни), използвайте --create-account с флага --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 ще извърши необходимите действия за създаване на базата данни и потребителски акаунт с подходящи привилегии и ще го разреши на всички възли на базата данни.

Управление на архивиране

ClusterControl поддържа два метода за архивиране за PostgreSQL:

pgdump – Псевдоним на pg_dumpall, помощна програма за изписване на всички PostgreSQL бази данни на клъстер в един скриптов файл.
pg_basebackup – Помощна програма за създаване на пълен архив на ниво файлова система на PostgreSQL база данни.

Създаване на резервно копие

За да създадете ново архивиране с помощта на pg_dumpall, изберете един възел на базата данни и посочете "pgdump" във флага --backup-method:

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

Флагът --on-controller показва, че бихме искали създаденото архивиране да се съхранява в директорията /storage/backups на възела ClusterControl. Пропуснете флага, ако искате да го съхраните на самия възел на базата данни. Същата команда може да се приложи за създаване на pg_basebackup архивиране. Просто заменете "pgdump" с "pg_basebackup" ще стане.

За да изброите резервното копие, просто използвайте флаговете --list и --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

Насрочване на архивиране

Планирането на архивиране е подобно на командата, която използвахме за създаване на резервно копие, с допълнителен флаг --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 * * *'

Стойността на повторението трябва да бъде приложена с цитат и във формат crontab.

Възстановяване на резервно копие

За да възстановите резервно копие в клъстер, използвайте флага --restore и посочете идентификатора на архива, който искате да използвате:

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

Обърнете внимание, че за архивирането на pg_basebackup операцията за възстановяване изисква престой на базата данни. Всички PostgreSQL възли ще бъдат спрени преди възстановяването и възстановяването се извършва на последния известен главен код. Този главен ще бъде изведен първи (последван от всички подчинени) след приключване на възстановяването.

Проверка на резервно копие

За да възстановите и потвърдите архива, използвайте флага --verify и посочете дестинационния сървър, като използвате флага --test-server:

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

Тестовият сървър не трябва да е част от клъстера и трябва да е достъпен чрез SSH без парола от възела ClusterControl. ClusterControl първо ще инсталира целевия сървър със същата версия на PostgreSQL, ще предава поточно и ще възстанови архива на този възел. Проверката на резервното копие търси последния изходен код след възстановяване. Ако архивът може да се възстанови, ClusterControl ще спре тестовия сървър и ще го премахне от ClusterControl (но ClusterControl няма да го изключи). След като задачата приключи, трябва да видите следното:

Backup 9 was successfully verified.

Създаване на клъстер от архивиране

ClusterControl въведе нова функция във v1.7.1, където може да се създаде нов клъстер на базата на архив, направен от съществуващ клъстер. Това може да бъде много полезно за тестване на вашата база данни на различна платформа или версия на базата данни. В този пример бихме искали да разгърнем PostgreSQL 9.6 клъстер с два възела на базата на резервен ID 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

Обърнете внимание, че паролата на администратора на потребителя за новия клъстер трябва да бъде идентична с администраторската парола на PostgreSQL, включена в архива. По принцип ClusterControl изпълнява задачата по разгръщане въз основа на следния ред:

Инсталирайте необходимия софтуер и зависимости на всички PostgreSQL възли.
Стартирайте първия възел.
Предаване и възстановяване на архивно копие на първия възел (с флаг за автоматично рестартиране).
Конфигурирайте и добавете останалите възли.

След това можете да проверите списъка с клъстери, като използвате следната команда:

$ s9s cluster --stat

Управление на конфигурацията

За да посочите конфигурацията на PostgreSQL на възел, използвайте флага --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 връща съответно изхода на OPTION NAME и VALUE. Колоната GROUP не е приложима в PostgreSQL, така че трябва да видите стойността на '-'.

За да промените опция за конфигурация, използвайте флага --change-config и посочете параметъра и стойността, използвайки съответно --opt-name и --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.

Трябва да видите, че ClusterControl връща състоянието на промяна на конфигурацията и съветва последващата процедура, за да се уверите, че промяната на конфигурацията ще се отрази. След това можете да използвате командата "s9s node --restart", за да рестартирате конкретния възел.

Последни мисли

ClusterControl предлага голяма гъвкавост, когато става въпрос за управление и наблюдение на вашия PostgreSQL клъстер от база данни. Имате избор на уеб потребителски интерфейс, който е доста прост и ясен плюс интерфейс на командния ред, който ви дава възможност да постигнете пълна автоматизация на базата данни чрез скриптове. Приятно управление!