Initialisation / Mise en veille

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

L'action createstandby peut entraîner une brève interruption du système SKOOR en raison d'un redémarrage de la base de données (modification automatique de la configuration possible). Le système sera ensuite pleinement fonctionnel et accessible. 

Veuillez noter ce qui suit :

  • Les bases de données d'une taille de 100 Go ou plus nécessitent généralement 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 base de données du serveur principal vers le serveur de secours. Vérifiez la taille totale de la base de données à l'aide de :

    du -sh /var/lib/pgsql

    Il est très probable que plusieurs gigaoctets de données doivent être transférés. Dans ce cas, il est préférable d'initialiser la réplication en soirée.

  • 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 serveur principal vers le serveur de secours.

  • 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. Une synchronisation basée uniquement sur la taille des fichiers de base de données et leurs dates de modification n'est pas suffisamment fiable. Par conséquent, avant que la synchronisation proprement dite ne commence, la base de données entière doit faire l'objet d'un calcul de 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.

  • Il est recommandé d'effectuer une sauvegarde complète sur le système actif actuel avant de lancer l'initialisation. Cela peut être fait à l'aide de 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 exécutée sur le serveur principal. É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 réseau entre le serveur principal et le serveur de secours, il est recommandé de l'exécuter dans une session screen. La commande screen permet d'exécuter une commande à distance sans que celle-ci ne soit interrompue si la connexion à l'hôte distant est coupée pour une raison quelconque. Lancez une nouvelle session screen (avec un tampon de défilement de l'historique suffisamment grand) sur le serveur principal en tant qu'administrateur à l'aide de la commande suivante :

screen -h 10000

Puis, au sein de cette session screen, exécutez la commande suivante pour lancer le processus d'initialisation du serveur de secours :

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

Voici un exemple de résultat 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. Le résultat suivant s'affichera :

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

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

Veuillez noter que cette commande fait de ce système le 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-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

Vous pouvez quitter la session Screen à tout moment en appuyant d'abord sur « Ctrl-a », puis sur « d ». Pour réintégrer la session Screen, entrez la commande de reconnexion suivante :

screen -h 10000 -r

Le script effectue les opérations suivantes :

  • Compare la somme de contrôle de chaque fichier de base de données entre le serveur principal et le serveur de secours.

  • Arrête le service eranger-server sur le nœud de secours s'il est en cours d'exécution

  • Les fichiers /var/lib/pgsql/data/recovery.signal et skoor-replication.conf (qui est inclus dans postgresql.skoor.conf) sont créés sur le nœud de secours. Ceux-ci permettent au nœud de secours de connaître l'adresse IP de son nœud principal, le port de réplication, les identifiants et le chemin d'accès au fichier de déclenchement. Voici un exemple de fichier skoor-replication.conf sur le nœud de secours :

    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. Sa création entraîne l'arrêt de la réplication (c'est-à-dire en cas de basculement/failover).
    recovery.signal est uniquement 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 via 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 commande 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 serveur principal peut être utilisé normalement pour accepter les données de mesure provenant des collecteurs. L'interface web 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 le fonctionnement du script est précédé de l'adresse IP de l'hôte sur lequel la tâche est en cours d'exécution.

Une fois l'exécution de la commande terminée, 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 désormais lancée et, à partir de maintenant, toutes les requêtes de base de données exécutées sur le serveur principal sont immédiatement répliquées vers le serveur de secours.