Utilisez l'action createstandby pour configurer initialement un environnement primaire/de secours. Les étapes suivantes doivent être effectuées en tant qu'utilisateur root :

L'action createstandby peut provoquer une brève interruption du système SKOOR en raison d'un redémarrage de la base de données (changement de configuration automatique possible). Elle sera pleinement fonctionnelle et accessible par la suite.

Tenez compte des points suivants :

Les bases de données d'une taille de 100 Go ou plus ont normalement besoin de plus de fichiers WAL que la valeur par défaut de 2048. Le paramètre wal_keep_size doit être augmenté avant que la réplication puisse être initialisée :
```
vi /var/lib/pgsql/data/postgresql.skoor.conf
```
Modifiez le paramètre (la valeur peut être supérieure à 4096, tenez compte de l'espace libre sur le disque) :
```
wal_keep_size = 4096
```
Le script synchronisera les tables de la BD du primaire vers le standby. Vérifiez la taille de l'ensemble de la base de données en utilisant :
```
du -sh /var/lib/pgsql
```
Il est très probable qu'il y ait plusieurs gigaoctets de données à transférer. Dans ce cas, il est préférable d'initialiser la réplication le soir.
La réinitialisation ne copie pas tous les fichiers. Si une initialisation a déjà été effectuée une fois avec createstandby, mais qu'elle doit être répétée parce que, pour une raison quelconque, la réplication est interrompue, beaucoup moins de données seront transférées du primaire vers le standby.
Cependant, chaque fichier de base de données doit être comparé par la somme de contrôle des deux côtés afin que les mécanismes de réplication puissent déterminer quels fichiers doivent être transférés. La synchronisation basée uniquement sur la taille des fichiers de base de données et leur temps de modification n'est pas suffisamment fiable. Par conséquent, avant que la synchronisation ne commence, l'ensemble de la base de données doit être vérifié des deux côtés, ce qui peut prendre plusieurs heures, en fonction des performances de l'hôte et de la taille de la base de données.
Il est conseillé d'effectuer une sauvegarde complète sur le système actif actuel avant de lancer l'initialisation. Cela peut être fait avec la commande :
```
cd /var/lib/pgsql
```
```
sudo -u postgres bash -l -c '/opt/eranger/bin/eranger-server-backup.sh full'
```
qui enregistrera une sauvegarde complète dans /opt/eranger/server/backups/.

Pour lancer l'initialisation, la commande createstandby doit être lancée sur le système principal. Comme cette commande peut durer plusieurs heures, en fonction de la quantité de données à transférer et de la bande passante du réseau entre le serveur principal et le serveur de secours, il est recommandé d'exécuter la commande dans le cadre d'une session d'écran. La commande screen permet d'exécuter une commande à distance sans qu'elle soit interrompue si la connexion à l'hôte distant est coupée pour une raison quelconque. Ouvrez une nouvelle session écran (avec une mémoire tampon de défilement de l'historique suffisamment grande) sur le serveur principal en tant que super-utilisateur à l'aide de la commande suivante :

screen -h 10000

Ensuite, dans cette session d'écran, exécutez la commande suivante pour lancer le processus d'initialisation de l'état de veille :

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

Voici un exemple de sortie de la commande ci-dessus :

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 >

Appuyez sur Entrée pour continuer. La sortie suivante s'affiche :

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

La commande createstandby peut également être exécutée en mode non interactif à l'aide du paramètre -f. Dans ce cas, la sortie sera plus courte :

Sachez que cette commande fait de ce système le serveur principal et détruit immédiatement la base de données sur l'autre nœud

# 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 session d'écran peut être quittée à tout moment en appuyant d'abord sur "Ctrl-a", puis sur "d". Pour revenir à la session écran, entrez la commande re-attach suivante :

screen -h 10000 -r

Le script effectue les opérations suivantes

Comparer la somme de contrôle de chaque fichier de base de données entre le serveur principal et le serveur de secours.
Arrêter le service eranger-server sur le standby s'il est en cours d'exécution.
Les fichiers /var/lib/pgsql/data/recovery.signal et skoor-replication.conf (qui est inclus par postgresql.skoor.conf) sont créés sur le standby. Ils permettent au standby de connaître l'adresse IP de son primaire, le port de réplication, les informations d'identification et le chemin d'accès au fichier de déclenchement. La figure suivante montre un exemple de fichier skoor-replication.con sur le standby :
```
primary_conninfo = 'host=10.1.0.88 port=5432 user=replication password=replication'
promote_trigger_file = '/tmp/postgresql.trigger.5432'
```
Le fichier promote_trigger_file n'existe pas si la réplication est en cours d'exécution. Sa création entraîne la fin de la réplication (par exemple, en cas de basculement).
recovery.signal n'est qu'un fichier marqueur et est donc vide.
Les parties de la base de données qui diffèrent entre les deux hôtes sont transférées à l'aide d'un processus rsync over ssh. Les chemins suivants sont exclus du processus de synchronisation :
- /var/lib/pgsql/data/pg_xlog/ (les journaux binaires, c'est-à-dire les fichiers WAL, ne sont pas synchronisés pendant la procédure de mise en attente, leur contenu n'est répliqué qu'après le lancement de la procédure de mise en attente).
- /var/lib/pgsql/data/recovery.signal
- /var/lib/pgsql/data/skoor-replication.conf
- /var/lib/pgsql/data/postmaster.pid
La réplication est lancée

Pendant le processus de création du standby, le primaire peut être utilisé normalement pour accepter les données de mesure des collecteurs. L'interface web de SKOOR peut également être utilisée, mais les performances peuvent être dégradées en raison des calculs de somme de contrôle et du transfert de fichiers volumineux sur le réseau.
Le temps nécessaire pour initialiser une réplication pour la première fois dépend principalement de la taille de la base de données, de la vitesse du réseau et des performances de l'hôte.

Chaque commentaire sur ce que fait le script est précédé de l'adresse IP de l'hôte sur lequel la tâche est exécutée.

Après l'exécution de la commande, vérifiez son code de sortie. Il doit être égal à zéro :

...
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 réplication est maintenant lancée et, à partir de maintenant, toutes les requêtes de base de données exécutées sur l'hôte principal sont immédiatement répliquées sur l'hôte de secours.

Modes