Bonjour,
La BDD liée à l’application s’arrête et l’application continue d’essayer d’envoyer les requêtes ce qui a pour effet de spam les logs qui remonte des erreurs. Est ce que c’est un fonctionnement normal du côté applicatif?
Le première fois que nous avons observé l’erreur c’était à cause d’une saturation d’espace disque côté BDD.
Bonjour
L’application ne peut fonctionner que si la base de données est accessible.
Si celle-ci ne l’est pas il est donc logique d’avoir des logs d’erreur indiquant que les requêtes ne peuvent pas aboutir. Et ce tant que la base est inaccessible.
Je ne vois pas trop ce que vous souhaiteriez que l’application fasse d’autre dans un tel cas…
Je pense que vous devriez gérer l’inaccessibilité de la base à un niveau exploitation = via de la supervision, afin de prendre les actions qui vous semblent adaptées.
Par exemple: sur détection d’inaccessibilité de la base vous arrêtez/suspendez le serveur applicatif et basculez au niveau de votre reverse proxy sur une page “service indisponible” (HTTP 503) et vous le redémarrez une fois que vous détectez que la base est à nouveau accessible
NB: l’application expose des endpoints de supervision : /ping (health check basique OK/KO) et /health (donnant des informations plus détaillées) permettant de faire une supervision niveau application, en cas d’inaccessibilité de la base ces endpoints renvoient une erreur, ça peut être une manière indirecte de superviser la base
Est ce qu’il aurait une configuration à faire ou autre pour stipuler l’arrêt des requêtes lors de pertes de connexion vers la BDD?
Sans accès à la base de données la plateforme ne fonctionne pas, le mieux est sans aucun doute de l’arreter en attendant que la base soit à nouveau accessible. Si des requêtes en base, en particulier les requêtes au méta modèle, sont en échec l’état de la plateforme est imprévisible.
Vouloir limiter les logs indiquant des erreurs d’accès à la base c’est prendre le problème à l’envers = vouloir supprimer le symptôme au lieu de gérer la cause.
Eventuellement on pourrait voir comment positionner un flag global rendant l’accès à la UI et aux API totalement inactifs en cas de détection d’un problème de connexion à la base : soit définitivement, soit temporairement en mettant en place un processus permettant de repartir “à vide” (= cache méta modèle vidé + sessions utilisateur invalidées) une fois la connexion à nouveau accessible mais ça revient clairement à faire (potentiellement mal) au niveau applicatif ce qui devrait logiquement être fait (bien) au niveau de la supervision de l’infrastructure.
En outre ça ne résoudrait pas le pb dans le cas d’une base souffrant d’un file system full car je pense que celle-ci est alors encore capable de répondre aux select mais pas aux updates…