Utilizzare l'azione createstandby per impostare inizialmente un ambiente primario/standby. I passaggi seguenti devono essere eseguiti come utente root:

L'azione createstandby può causare una breve interruzione del sistema SKOOR a causa del riavvio del database (possibile modifica automatica della configurazione). In seguito sarà completamente funzionante e accessibile.

Tenere presente quanto segue:

I database con dimensioni pari o superiori a 100 GB necessitano normalmente di un numero di file WAL superiore a quello predefinito di 2048. Il parametro wal_keep_size deve essere aumentato prima che la replica possa essere inizializzata:
```
vi /var/lib/pgsql/data/postgresql.skoor.conf
```
Modificare il parametro (il valore può essere maggiore di 4096, considerando lo spazio libero sul disco):
```
wal_keep_size = 4096
```
Lo script sincronizzerà le tabelle del DB dal primario allo standby. Controllare la dimensione dell'intero DB utilizzando:
```
du -sh /var/lib/pgsql
```
È molto probabile che ci siano diversi gigabyte di dati da trasferire. In questo caso, è meglio inizializzare la replica la sera.
La reinizializzazione non copia tutti i file. Se l'inizializzazione è già stata fatta una volta con createstandby, ma deve essere ripetuta perché per qualche motivo la replica è interrotta, verranno trasferiti molti meno dati dal primario allo standby.
Tuttavia, ogni file di database deve essere confrontato con il checksum su entrambi i lati, in modo che i meccanismi di replica siano in grado di determinare quali file devono essere trasferiti. La sincronizzazione basata esclusivamente sulle dimensioni dei file di database e sui loro tempi di modifica non è sufficientemente affidabile. Pertanto, prima di iniziare la sincronizzazione vera e propria, l'intero database deve essere sottoposto a checksum su entrambi i lati, il che può richiedere diverse ore, a seconda delle prestazioni dell'host e delle dimensioni del database.
È buona norma completare un backup completo sul sistema attivo corrente prima di avviare l'inizializzazione. Questo può essere fatto con il comando
```
cd /var/lib/pgsql
```
```
sudo -u postgres bash -l -c '/opt/eranger/bin/eranger-server-backup.sh full'
```
che salverà un backup completo in /opt/eranger/server/backups/.

Per avviare l'inizializzazione, è necessario lanciare il comando createstandby sul sistema primario. Poiché questo comando può durare diverse ore, a seconda della quantità di dati da trasferire e della larghezza di banda della rete tra il primario e lo standby, si consiglia di eseguirlo all'interno di una sessione di schermo. Il comando schermo consente di eseguire un comando in remoto senza che il comando venga terminato se la connessione all'host remoto viene interrotta per qualche motivo. Avviare una nuova sessione di schermo (con un buffer di scrollback della cronologia sufficientemente grande) sul primario come root utilizzando il seguente comando:

screen -h 10000

Quindi, all'interno di questa sessione di schermo, eseguire il seguente comando per avviare il processo di inizializzazione dello standby:

/opt/eranger/bin/eranger-server-replication.pl createstandby

Il seguente è un esempio di output del comando sopra descritto:

192.168.56.221 prepare standby system 192.168.56.222 (primary system 192.168.56.221)..
192.168.56.221
192.168.56.221
192.168.56.221 ============================================================
192.168.56.221 == Setting up standby system on 192.168.56.222
192.168.56.221 == THIS WILL DESTROY DATABASE on 192.168.56.222
192.168.56.221 == make sure you have a backup
192.168.56.221 ============================================================
192.168.56.221
192.168.56.221 if you continue, we will call above command with ssh
press ENTER to continue, Ctrl-C to abort >

Premere Invio per continuare. Verrà visualizzato il seguente output:

192.168.56.221 checking ssh for user reranger
192.168.56.222 stopped skoor syncfs
Removed symlink /etc/systemd/system/multi-user.target.wants/eranger-server.service.
Removed symlink /etc/systemd/system/multi-user.target.wants/eranger-report.service.
192.168.56.221 restart postgresql-13.service..
192.168.56.221 SKOOR Engine start httpd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 httpd already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-report at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-report already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-server at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-server already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ethd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ethd (service eranger-ethd )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-eth-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-eth-alerter (service eranger-eth-alerter )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-collector at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-collector already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-agent at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-agent already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ic-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ic-alerter (service eranger-ic-alerter )..
192.168.56.221 done
192.168.56.221 copied file to /var/lib/pgsql/13/data/
192.168.56.221 copied file to /var/lib/pgsql/data/ng_tblspc/
192.168.56.221 rsync done
NOTICE:  all required WAL segments have been archived
192.168.56.222 stopped skoor syncfs
192.168.56.222 Enable and start eranger-replication-tunnel.service at /opt/eranger/bin/eranger-server-replication.pl line 1751.
192.168.56.221 started skoor syncfs

Il comando createstandby può anche essere eseguito in modalità non interattiva utilizzando il parametro -f. In questo caso l'output sarà più breve:

Si tenga presente che questo comando rende questo sistema il server primario e distrugge immediatamente il database sull'altro nodo.

# eranger-server-replication.pl -f createstandby
192.168.56.221 prepare standby system 192.168.56.222 (primary system 192.168.56.221)..
192.168.56.221
192.168.56.221 checking ssh for user reranger
192.168.56.222 stopped skoor syncfs
192.168.56.221 restart postgresql-13.service..
192.168.56.221 SKOOR Engine start httpd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 httpd already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-report at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-report already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-server at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-server already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ethd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ethd (service eranger-ethd )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-eth-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-eth-alerter (service eranger-eth-alerter )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-collector at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-collector already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-agent at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-agent already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ic-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ic-alerter (service eranger-ic-alerter )..
192.168.56.221 done
192.168.56.221 copied file to /var/lib/pgsql/13/data/
192.168.56.221 copied file to /var/lib/pgsql/data/ng_tblspc/
192.168.56.221 rsync done
NOTICE:  all required WAL segments have been archived
192.168.56.222 stopped skoor syncfs
192.168.56.222 Enable and start eranger-replication-tunnel.service at /opt/eranger/bin/eranger-server-replication.pl line 1751.
192.168.56.221 started skoor syncfs

La sessione di schermo può essere abbandonata in qualsiasi momento premendo prima "Ctrl-a" e poi "d". Per rientrare nella sessione dello schermo, immettere il seguente comando re-attach:

screen -h 10000 -r

Lo script esegue le seguenti operazioni:

Confronta il checksum di ogni file di database tra primario e standby.
Arresta il servizio eranger-server sullo standby se è in esecuzione.
I file /var/lib/pgsql/data/recovery.signal e skoor-replication.conf (incluso in postgresql.skoor.conf) vengono creati sullo standby. Questi permettono allo standby di conoscere l'indirizzo IP del primario, la porta di replica, le credenziali e il percorso del file di trigger. Di seguito è riportato un esempio di file skoor-replication.con sullo standby:
```
primary_conninfo = 'host=10.1.0.88 port=5432 user=replication password=replication'
promote_trigger_file = '/tmp/postgresql.trigger.5432'
```
Il file promote_trigger_file non esiste se la replica è in corso. La sua creazione provoca la fine della replica (ad esempio in caso di switch/failover).
recovery.signal è solo un file di marcatura e quindi vuoto.
Le parti del database che differiscono tra i due host vengono trasferite utilizzando un processo di rsync su ssh. I seguenti percorsi sono esclusi dal processo di sincronizzazione:
- /var/lib/pgsql/data/pg_xlog/ (i log binari, cioè i file WAL, non vengono sincronizzati durante il createstandby, il loro contenuto viene replicato solo dopo l'avvio del processo di createstandby).
- /var/lib/pgsql/data/recovery.signal
- /var/lib/pgsql/data/skoor-replication.conf
- /var/lib/pgsql/data/postmaster.pid
La replica viene avviata

Durante il processo di creazione dell'alternativo, il primario può essere usato normalmente per accettare i dati di misura dai collettori. È possibile utilizzare anche l'interfaccia web di SKOOR, ma le prestazioni potrebbero essere ridotte a causa dei calcoli del checksum e del trasferimento di file di grandi dimensioni attraverso la rete.
Il tempo necessario per inizializzare una replica per la prima volta dipende principalmente dalle dimensioni del database, dalla velocità della rete e dalle prestazioni dell'host.

Ogni commento sulle operazioni dello script è preceduto dall'indirizzo IP dell'host su cui viene eseguita l'operazione.

Al termine dell'esecuzione del comando, controllare il suo codice di uscita. Dovrebbe essere zero:

...
10.1.0.88 done
10.1.0.88 copied file to /var/lib/pgsql/data/
NOTICE:  pg_stop_backup complete, all required WAL segments have been archived
# echo $?
0

La replica è stata avviata e d'ora in poi tutte le query del database eseguite sul primario vengono replicate immediatamente sullo standby.

Modalità