La base de données de secours et la copie pour les rapports (pour l'équipe Kaam360)
Ce guide s'adresse à l'équipe Kaam360 (le panneau de la plateforme). Les clients n'en ont pas besoin.
Ce qu'est la base de secours
Le site en production conserve ses données dans une base PostgreSQL sur le serveur. La base de secours est un second PostgreSQL sur le même serveur qui reçoit chaque modification au moment où elle se produit : elle n'a donc que quelques millisecondes de retard. Si la base en production tombe en panne, le site peut basculer sur la base de secours en environ deux minutes, au lieu de restaurer la sauvegarde de la nuit précédente. Elle ne remplace pas la sauvegarde nocturne hors site, qui protège contre la perte du serveur entier : les deux sont nécessaires.
Tout se fait avec des boutons dans GitHub (Actions, PostgreSQL standby, Run workflow) : choisissez un mode, saisissez le même mot dans la case de confirmation, appuyez sur le bouton vert. La procédure écrite se trouve dans le fichier deploy/STANDBY.txt.
Voir si elle est en bonne santé
- Ouvrez le panneau de la plateforme et regardez Vue d'ensemble. La carte Base de données de secours indique Streaming (bon), En retard ou Non connecté, avec l'ampleur du retard.
- La même information se trouve à l'adresse /health du site, dans la partie « standby ».
- Dans GitHub, le mode status affiche une page complète : le service Windows, l'état de la réplication, les octets et secondes de retard, la taille de la copie. Il ne modifie rien.
- Lorsque la base de secours est absente ou en retard depuis dix minutes, l'équipe reçoit un e-mail (à l'adresse de support définie sous Paramètres et équipe, sinon à chaque administrateur de la plateforme), répété au plus toutes les six heures. Le journal Activité de la plateforme reçoit une ligne lorsque le problème survient et lorsque tout redevient normal.
La configurer ou la réparer
Lancez le mode setup. Le site en production n'est pas arrêté. Il crée les utilisateurs de base de données (mots de passe conservés uniquement sur le serveur), fait une copie complète, démarre la copie en tant que base de secours, enregistre le service Windows, bloque son port depuis l'extérieur, et en informe le site. Une base de secours en bonne santé est laissée telle quelle : le relancer est donc toujours sans risque. Si une étape échoue, le script indique laquelle et pourquoi, et rien ne change sur le site en production.
Basculer sur la base de secours
Lancez le mode failover lorsque la base en production est en panne et que la base de secours va bien. Le site affiche une page « mise à jour en cours » pendant environ deux minutes. La base de secours devient la base en production, le site est redirigé vers elle, et les réglages précédents sont conservés dans appsettings.local.json.before-failover. Le script indique ensuite la marche à suivre : utiliser le site normalement, conserver pour l'instant l'ancien dossier de la base, et lancer setup quand le serveur est calme pour créer une nouvelle base de secours. Une copie promue ne redevient jamais une base de secours ; une nouvelle est créée à partir d'une copie fraîche.
Les rapports lourds lisent la copie
Lorsque la base de secours se réplique et a moins de quelques minutes de retard, le générateur de rapports, les e-mails de rapports programmés, les téléchargements CSV et Excel, le portefeuille, les rapports de projet et le téléchargement complet des données la lisent au lieu de la base en production : un gros rapport ne ralentit donc jamais les personnes qui travaillent. Un tel rapport affiche Données au suivi de l'heure de la dernière modification présente dans la copie. Lorsque la copie est absente, injoignable ou a plus de quelques minutes de retard, les rapports utilisent la base en production, sans que personne n'ait rien à faire. Rien n'est jamais écrit dans la copie, et chaque rapport ne voit que les données de sa propre organisation, exactement comme sur la base en production. L'adresse /health indique si les rapports sont servis depuis la copie (« reports »).
La retirer
Lancez le mode remove. Il arrête et supprime la base de secours et la retire des réglages du site. La base en production n'est pas touchée. Setup peut être relancé à tout moment.
Lire la suite
- Créer vos propres tableaux de bord dans Power BIConnectez Power BI Desktop et le service Power BI à vos propres données Kaam360 avec une clé de flux en lecture seule, puis actualisez-les selon un calendrier.
- Applications connectées : permettre à d'autres applications d'utiliser votre compte Kaam360Autorisez une application mobile, un agenda ou un outil de reporting à travailler avec votre compte, voyez ce qu'il peut faire, et déconnectez-le à tout moment.
- Connecter d'autres programmes : API, webhooks et alertes Slack ou TeamsPermettez à d'autres programmes de lire vos données, et envoyez des alertes à Slack, Teams ou un autre programme quand des événements se produisent.
Toujours bloqué ? Passez par Aide & support dans l'application et nous vous aiderons.