Concept de réplication de base de données

Architecture

Le SKOOR Engine utilise une base de données PostgreSQL pour stocker ses données de configuration ainsi que sa valeur historique et ses données d'historique. Il prend en charge l'utilisation d'une configuration primaire/de secours pour répliquer en continu le contenu de la base de données. Les propres méthodes de réplication de PostgreSQL sont utilisées, ce qui signifie qu'une copie exacte de la base de données sur le serveur principal est conservée sur le serveur de secours et que toutes les mises à jour de la base de données sur le server principal sont immédiatement répliquées sur le serveur de secours . Le server principal met en mémoire tampon les instructions SQL dans un journal binaire, le server de secours demande ces instructions au server .

Cela garantit des temps d'arrêt courts en cas de pannes matérielles. Cependant, il ne protégera PAS des erreurs du pilote telles que les instructions de suppression erronées qui seront immédiatement synchronisées avec le standby . La réplication ne remplace pas les sauvegardes régulières.

La figure suivante montre un exemple d'agencement de réplication standard.

En mode par défaut, le serveur principal transporte toute la charge, toutes les demandes des utilisateurs reçoivent une réponse du serveur Web Apache sur le serveur principal, les données de mesure sont fournies par les collecteurs au server principal actuel et stockées dans la base de données. Les services eranger- server , eranger- collecteur et eranger-report ne fonctionnent PAS sur le server de secours .

Principales caractéristiques de la configuration de la réplication

  • La réplication peut être mise en œuvre même avec collecteurs SKOOR externes.

  • Si une réplication a déjà été émise, une grande partie des fichiers de la base de données sera probablement déjà synchronisée. Le script ne transférera PAS les anciennes tables qui sont déjà synchronisées. Cela permet d'économiser de la bande passante réseau si une réinitialisation doit être émise.

  • Il n'y a pas de basculement automatique du primaire vers le redondant . Il a été conçu pour laisser cette décision à un humain. Cependant, le script supporte un mode non interactif qui permettrait d'émettre un basculement par un script. (option -f ).

  • Possibilité de surveiller le primaire depuis le standby (indépendant de SKOOR) en envoyant un e-mail dès qu'il détecte que le Engine SKOOR ne fonctionne plus sur le primaire actuel.

  • Possibilité d'exécuter des scripts ou des commandes personnalisés avant et/ou après le basculement des fonctions server (de secours à principal et vice versa).

Exigences

Pour configurer la réplication de la base de données, un deuxième server SKOOR est requis avec les mêmes spécifications de performances que le premier. Bien que cette veille soit en mode veille la plupart du temps, elle doit être capable de supporter la pleine charge lorsque sa fonction passe de veille à primaire .

Les prérequis suivants doivent être remplis :

  • La même version de SKOOR est installée sur le primaire et le standby .

  • (Facultatif) collecteurs externes sont configurés correctement et fonctionnent

    • Le server Le paramètre _address doit être défini sur la même adresse IP que le server principal

    • Collecteurs utilisant le protocole HTTP ne peuvent pas être commutés automatiquement

  • Le fichier /opt/eranger/bin/ server est identique sur le primaire , le standby et tous collecteurs . Cela signifie que tous les hôtes impliqués doivent avoir la même version de SKOOR installée.

  • Le fichier /etc/opt/eranger/eranger-replication.cfg est configuré correctement et est identique sur le primaire, le standby et tous collecteurs .

  • Connectivité réseau

    • Port TCP 22 (ssh) du primaire au standby , vice versa et du primaire et du standby à tous collecteurs externes.

    • Port TCP 50001 (livraison des données collecteur SKOOR) de tous collecteurs externes vers le primaire et le secours .