Documentazione

Inizializzazione / Createstandby

Utilizzare l'azione createstandby per configurare inizialmente un ambiente primario/di standby. I seguenti passaggi 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). Successivamente il sistema sarà pienamente funzionante e accessibile. 

Tenere presente quanto segue:

  • I database con una dimensione pari o superiore a 100 GB richiedono normalmente un numero di file WAL superiore al valore predefinito di 2048. Il parametro wal_keep_size deve essere aumentato prima di poter inizializzare la replica:

    vi /var/lib/pgsql/data/postgresql.skoor.conf

    Modificare il parametro (il valore può essere superiore a 4096, tenendo conto dello spazio libero sul disco):

    wal_keep_size = 4096

  • Lo script sincronizzerà le tabelle del database dal primario allo standby. Controllare la dimensione dell'intero database utilizzando:

    du -sh /var/lib/pgsql

    È molto probabile che ci siano diversi gigabyte di dati da trasferire. In questo caso, è meglio inizializzare la replica di sera.

  • La reinizializzazione non copia tutti i file. Se l'inizializzazione è già stata eseguita 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 tramite checksum su entrambe le parti 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 sulle loro date di modifica non è sufficientemente affidabile. Pertanto, prima che inizi la sincronizzazione vera e propria, è necessario calcolare il checksum dell'intero database su entrambe le parti, operazione che può richiedere diverse ore, a seconda delle prestazioni dell'host e delle dimensioni del database.

  • È consigliabile eseguire un backup completo sul sistema attualmente attivo prima di avviare l'inizializzazione. Ciò 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 eseguire il comando createstandby sul primario. Poiché questo comando può durare diverse ore, a seconda della quantità di dati da trasferire e della larghezza di banda di rete tra primario e standby, si consiglia di eseguire il comando all'interno di una sessione screen. Il comando screen consente di eseguire un comando in remoto senza che questo venga interrotto se la connessione all'host remoto viene disconnessa per qualche motivo. Avviare una nuova sessione screen (con un buffer di scorrimento della cronologia sufficientemente ampio) sul primario come root utilizzando il seguente comando:

screen -h 10000

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

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

Di seguito è riportato un esempio di output del comando sopra indicato:

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-17.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ò essere eseguito anche in modalità non interattiva utilizzando il parametro -f. In questo caso l'output sarà più breve:

Si prega di tenere 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-17.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

È possibile uscire dalla sessione screen in qualsiasi momento premendo prima "Ctrl-a" e poi "d". Per rientrare nella sessione screen, immettere il seguente comando di ricollegamento:

screen -h 10000 -r

Lo script esegue le seguenti operazioni:

  • Confronta il checksum di ogni file di database tra il primario e lo standby.

  • Arresta il servizio eranger-server sullo standby se è in esecuzione

  • I file /var/lib/pgsql/data/recovery.signal e skoor-replication.conf (che è incluso in postgresql.skoor.conf) vengono creati sul nodo di standby. Questi consentono al nodo di standby di conoscere l'indirizzo IP del nodo primario, la porta di replica, le credenziali e il percorso del file di trigger. Di seguito è riportato un esempio di file skoor-replication.con sul nodo di 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 esecuzione. La sua creazione provoca la fine della replica (ad esempio in caso di switch/failover).
    recovery.signal è solo un file marcatore e quindi vuoto.

  • Le parti del database che differiscono tra i due host vengono trasferite utilizzando un processo rsync su ssh. I seguenti percorsi sono esclusi dal processo di sincronizzazione:

    • /var/lib/pgsql/data/pg_xlog/ (i log binari, ovvero i file WAL non vengono sincronizzati durante createstandby, il loro contenuto viene replicato solo dopo l'avvio del processo 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 createstandby, il primario può essere utilizzato normalmente per accettare i dati di misurazione dai collettori. È possibile utilizzare anche l'interfaccia web SKOOR, tuttavia le prestazioni potrebbero risultare compromesse 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 relativo all'operatività dello script è preceduto dall'indirizzo IP dell'host su cui viene elaborata l'attività.

Una volta terminata l'esecuzione del comando, controlla 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 è ora avviata e d'ora in poi tutte le query del database eseguite sul primario vengono replicate immediatamente sullo standby.

Precedente
Modalità
Successivo
Uso / Aiuto