PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Come gestire i database PostgreSQL dalla CLI ClusterControl

Sapevi che oltre all'interfaccia utente Web ClusterControl, puoi anche utilizzare un'interfaccia a riga di comando per gestire le tue istanze PostgreSQL?

ClusterControl supporta la replica in streaming PostgreSQL (sia asincrona che sincrona) e l'istanza PostgreSQL autonoma. Abbiamo fatto del nostro meglio per rendere l'interfaccia della riga di comando più vicina all'interfaccia utente in termini di funzionalità disponibili.

Perché vorresti utilizzare la CLI?

Consente di distribuire un'intera configurazione di replica in un comando, eseguire un failover o aggiungere nuovi nodi alla configurazione. Questo si integra molto bene con il codice di automazione dell'infrastruttura esistente scritto in Ansible, Chef o Puppet.

Questo post del blog fornisce una procedura dettagliata su come gestire un cluster di replica in streaming PostgreSQL utilizzando ClusterControl CLI o s9s.

Tieni presente che la maggior parte delle funzionalità mostrate in questo post del blog richiede che ClusterControl sia installato e funzionante con un abbonamento valido, una licenza commerciale o una licenza di prova gratuita (valida fino a 30 giorni dopo l'installazione di ClusterControl).

Distribuzione e importazione di cluster

Distribuzione di un nuovo cluster

Prima di distribuire un nuovo cluster o importare un cluster PostgreSQL esistente in ClusterControl, assicurarsi che SSH senza password dal nodo ClusterControl a tutti i nodi del database sia configurato in anticipo. Supponiamo di voler distribuire una nuova replica di streaming PostgreSQL a tre nodi, eseguire i seguenti comandi sul nodo 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

Sul nodo ClusterControl, verificare se è possibile eseguire il comando seguente senza password:

$ ssh 192.168.0.91 "ls /root"

Se riesci a vedere il contenuto della directory, sei in buona forma. Quindi, usa ClusterControl CLI con --create flag per distribuire il cluster:

$ 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

Abbiamo specificato il primo nodo, 192.168.0.91 come master e il resto sono slave. Poiché abbiamo già configurato SSH senza password tramite l'utente root, abbiamo specificato l'utente del sistema operativo come "root" insieme al file della chiave SSH corrispondente utilizzando il flag --os-key-file. Il flag --wait significa che il lavoro attenderà e riporterà lo stato di avanzamento fino al termine.

Puoi anche monitorare l'avanzamento della distribuzione dall'interfaccia utente di ClusterControl in Attività> Lavori> Creazione di un cluster PostgreSQL :

Una volta completata la distribuzione, possiamo vedere il riepilogo del cluster in esecuzione utilizzando il flag --stat:

$ s9s cluster --stat

Importazione di un cluster esistente

Se supponiamo che tu abbia già un cluster di replica in streaming PostgreSQL distribuito manualmente, puoi importarlo in ClusterControl usando il flag --register come mostrato nel comando seguente:

$ 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 si connetterà quindi ai nodi specificati, rileverà la topologia e registrerà il cluster in ClusterControl. Puoi verificare con il comando 's9s cluster --stat' come mostrato sopra.

Gestione di nodi e cluster

Controllo del servizio

Per eseguire un riavvio in sequenza di un cluster, specifica l'ID del cluster e utilizza --rolling-restart flag:

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

Utilizzare il flag --stop per il componente "cluster" per arrestare un cluster. Per vedere l'output del lavoro invece della barra di avanzamento, possiamo invece usare --log flag:

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

Riporterà gli stessi messaggi di lavoro dell'interfaccia utente web. Simile a quanto sopra, per avviare un cluster, usa semplicemente il flag --start (usiamo invece il flag --wait per vedere lo stato di avanzamento invece dei registri dei lavori):

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

Per riavviare il servizio PostgreSQL su un nodo del database, utilizziamo il componente "node" e il flag --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.

Per arrestare e avviare un nodo PostgreSQL, applica semplicemente lo stesso comando con --stop o --start flag, come mostrato di seguito:

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

Tieni presente che queste azioni non riavvieranno il sistema.

Nodo di ridimensionamento

Per rimuovere un nodo da un cluster, utilizza il 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.

L'aggiunta di un nuovo nodo funziona in modo simile, ma devi prima assicurarti che il nodo sia accessibile tramite SSH senza password. Configuralo prima e poi aggiungi il nodo usando il flag --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'.

Dai registri dei lavori, possiamo vedere che poiché il cluster ha già un master in esecuzione (192.168.0.91), il nuovo nodo verrà distribuito come slave al master. ClusterControl eseguirà quindi tutte le azioni necessarie e preparerà il nuovo nodo come ruolo specificato di conseguenza.

Passaggio a un nuovo Master

Per eseguire il passaggio, scegli uno degli slave che diventi il ​​nuovo master con --promote-slave flag:

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

I messaggi di lavoro mostrano che ClusterControl rileverà prima la topologia corrente e arresterà tutti i nodi nel cluster. Quindi, configura il nuovo master e fa in modo che gli altri nodi vengano replicati da esso. Tenterà anche di eseguire pg_rewind per risincronizzare il PGDATA del master sottoposto a downgrade con un nuovo backup di base. Al termine del lavoro, ClusterControl segnala la topologia corrente e lo stato della promozione.

Possiamo quindi verificare elencando tutti i nodi per l'ID cluster 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.

Lo stato "poM-" nella colonna più a sinistra ha il seguente significato:

  • p - Nodo PostgreSQL
  • o - in linea
  • M - maestro

Gestione database

Per elencare tutti i database trovati nel cluster, usa il flag --list-database sul cluster di componenti:

$ 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

Tieni presente che se il cluster ha molti database, questa opzione potrebbe non mostrarne alcuni. Il campionamento di un numero enorme di database genererebbe un carico elevato e quindi il controller ha un limite superiore integrato.

Se vuoi creare un nuovo database per il cluster, fai semplicemente:

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

Per creare un nuovo utente del database, insieme a un database ad esso associato (utilizzando lo stesso nome del database), usa il flag --create-account with --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 eseguirà le azioni necessarie per creare il database e l'account utente con i privilegi appropriati e consentirlo su tutti i nodi del database.

Gestione backup

ClusterControl supporta due metodi di backup per PostgreSQL:

  • pgdump - Alias ​​di pg_dumpall, un'utilità per scrivere tutti i database PostgreSQL di un cluster in un unico file di script.
  • pg_basebackup - Un'utilità per creare un backup completo a livello di file system di un database PostgreSQL.

Creazione di un backup

Per creare un nuovo backup utilizzando pg_dumpall, scegli un nodo del database e specifica "pgdump" nel flag --backup-method:

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

Il flag --on-controller indica che vorremmo che il backup creato fosse archiviato nella directory /storage/backups sul nodo ClusterControl. Ometti il ​​flag se vuoi memorizzarlo sul nodo del database stesso. Lo stesso comando può essere applicato per creare un backup di pg_basebackup. Basta sostituire "pgdump" con "pg_basebackup".

Per elencare il backup, usa semplicemente i flag --list e --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

Pianificazione di un backup

La pianificazione di un backup è simile al comando che abbiamo usato per creare un backup, con il flag --recurrence aggiuntivo:

$ s9s backup \
--create \
--backup-method=pg_basebackup \
--cluster-id=8 \
--nodes=192.168.0.92 \
--backup-directory=/storage/backups \
--on-controller \
--recurrence='30 0 * * *'

Il valore della ricorrenza deve essere racchiuso tra citazione e in formato crontab.

Ripristino di un backup

Per ripristinare un backup su un cluster, utilizza il flag --restore e indica l'ID backup che desideri utilizzare:

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

Tieni presente che per il backup di pg_basebackup, l'operazione di ripristino richiede tempi di inattività del database. Tutti i nodi PostgreSQL verranno arrestati prima del ripristino e il ripristino avrà luogo sull'ultimo master noto. Questo padrone verrà allevato per primo (seguito da tutti gli schiavi) al termine del ripristino.

Verifica di un backup

Per ripristinare e verificare il backup, usa il flag --verify e specifica il server di destinazione usando il flag --test-server:

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

Il server di test non deve far parte del cluster e deve essere accessibile tramite SSH senza password dal nodo ClusterControl. ClusterControl installerà prima il server di destinazione con la stessa versione di PostgreSQL, eseguirà lo streaming e ripristinerà il backup su quel nodo. La verifica di backup cerca l'ultimo codice di uscita dopo il ripristino. Se il backup è ripristinabile, ClusterControl arresterà il server di prova e lo rimuoverà da ClusterControl (ma ClusterControl non lo arresterà). Dovresti vedere quanto segue una volta completato il lavoro:

Backup 9 was successfully verified.

Crea cluster dal backup

ClusterControl ha introdotto una nuova funzionalità nella v1.7.1, in cui è possibile creare un nuovo cluster basato su un backup eseguito da un cluster esistente. Questo può essere molto utile per testare il tuo database su una piattaforma o una versione del database diversa. In questo esempio, vorremmo distribuire un cluster PostgreSQL 9.6 a due nodi basato sull'ID di backup 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

Tieni presente che la password dell'utente amministratore per il nuovo cluster deve essere identica alla password dell'amministratore PostgreSQL inclusa nel backup. Fondamentalmente, ClusterControl esegue il lavoro di distribuzione in base al seguente ordine:

  1. Installa i software e le dipendenze necessari su tutti i nodi PostgreSQL.
  2. Avvia il primo nodo.
  3. Streaming e ripristino del backup sul primo nodo (con flag di riavvio automatico).
  4. Configura e aggiungi il resto dei nodi.

È quindi possibile verificare l'elenco dei cluster utilizzando il comando seguente:

$ s9s cluster --stat

Gestione della configurazione

Per elencare la configurazione PostgreSQL di un nodo, usa il 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 restituisce l'output di OPTION NAME e VALUE di conseguenza. La colonna GROUP non è applicabile in PostgreSQL quindi dovresti vedere il valore '-'.

Per modificare un'opzione di configurazione, usa --change-config flag e specifica il parametro e il valore usando rispettivamente --opt-name e --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.

Dovrebbe essere visualizzato ClusterControl restituire lo stato di modifica della configurazione e consigliare la procedura di follow-up per assicurarsi che la modifica della configurazione abbia effetto. È quindi possibile utilizzare il comando "s9s node --restart" per riavviare il nodo particolare.

Pensieri finali

ClusterControl offre grande flessibilità quando si tratta di gestire e monitorare il cluster di database PostgreSQL. Puoi scegliere l'interfaccia utente web, che è abbastanza semplice e diretta, oltre all'interfaccia a riga di comando, che ti consente di ottenere l'automazione completa del database tramite script. Buona gestione!