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 courte panne du système SKOOR en raison d'un redémarrage de la base de données (changement de configuration automatique possible). Il sera entièrement fonctionnel et accessible par la suite.

Soyez conscient de ce qui suit :

Les bases de données d'une taille de 100 Go ou plus nécessitent normalement 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 base de données du primaire au 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 aura 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 car, pour une raison quelconque, la réplication est interrompue, beaucoup moins de données seront transférées du primaire au standby .
Cependant, chaque fichier de base de données doit être comparé par 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 la base de données et leurs heures de modification n'est pas suffisamment fiable. Par conséquent, avant le début de la synchronisation proprement dite, l'ensemble de la base de données doit faire l'objet d'une somme de contrôle 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.
C'est une bonne idée d'effectuer une sauvegarde complète sur le système actif actuel avant de commencer 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 sur /opt/eranger/ server /backups/.

Pour démarrer l'initialisation, la commande createstandby doit être émise sur le fichier . Étant donné que cette commande peut s'exécuter pendant plusieurs heures, en fonction de la quantité de données à transférer et de la bande passante du réseau entre le primaire et le standby , il est recommandé d'exécuter la commande dans une session screen . La commande screen permet d'exécuter une commande à distance sans que la commande soit interrompue si la connexion à l'hôte distant est déconnectée pour une raison quelconque. Lancez une nouvelle session d'écran (avec un tampon de défilement d'historique suffisamment grand) sur le primaire en tant que root à l'aide de la commande suivante :

screen -h 10000

Ensuite, dans cette session d'écran, exécutez la commande suivante pour démarrer le processus d'initialisation 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 sera affichée :

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 . La sortie sera plus courte dans ce cas :

Veuillez noter que cette commande transforme ce système en server 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 réintégrer la session d'écran, saisissez la commande de rattachement suivante :

screen -h 10000 -r

Le script effectue les opérations suivantes :

Comparez la somme de contrôle de chaque fichier de base de données entre le primaire et le standby .
Arrêtez le service eranger- server en veille s'il est en cours d'exécution
Les fichiers /var/lib/pgsql/data/recovery.signal et skoor-replication.conf (inclus par postgresql.skoor.conf) sont créés en veille. Ceux-ci permettent au serveur de secours de connaître l'adresse IP de son principal , le port de réplication, les informations d'identification et le chemin d'accès au fichier déclencheur. Voici un exemple de fichier skoor-replication.con en veille :
```
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 l'arrêt de la réplication (c'est-à-dire en cas de basculement/basculement).
recovery.signal n'est qu'un fichier marqueur et 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 sur 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 createstandby, leur contenu n'est répliqué qu'après le démarrage du processus createstandby)
- /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 createstandby, le primaire peut être utilisé normalement pour accepter les données de mesure des collecteurs . L'interface Web SKOOR peut également être utilisée, cependant, 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 en cours de traitement.

Une fois l'exécution de la commande terminée, vérifiez son code de sortie. Il doit être nul :

...
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 le primaire sont immédiatement répliquées sur le standby .

Modes