Knex: obtenir « Knex : Délai d'expiration de l'acquisition d'une connexion. Le pool est probablement plein. » Erreur

Je suis également confronté à ce problème.

J'ai le même problème.

La solution est d'isoler la source et de la réparer. Il ne s'agit pas d'une erreur de "requête", mais plutôt d'un problème d'architecture d'application. L'erreur se produit lorsque knex est incapable d'acquérir une connexion dans les 60 secondes (par défaut) et la raison en est très probablement que le pool est plein.

En d'autres termes, il y a beaucoup de choses qui peuvent provoquer l'erreur. Deux des plus courants sont :

1. Vous oubliez de valider les transactions / oubliez d'appeler .transacing(trx) sur les générateurs de requêtes alors que vous êtes déjà au maximum du pool, ce qui non seulement provoque l'inactivité de la transaction, mais génère également l'erreur car aucune connexion n'a pu être acquise.
2. Le pool est continuellement occupé à sa capacité maximale pendant au moins (par défaut) 60 secondes non-stop, par exemple en raison d'un trafic intense ou de procédures longues.

Vous devriez examiner l'état de votre base de données lorsque cette erreur se produit - y a-t-il beaucoup de connexions inactives ? y a-t-il trop de connexions ? etc.

Je suis également confronté à cette erreur.

rejecter(new _bluebird2.default.TimeoutError('Knex: Timeout acquiring a connection. The pool is probably full. ' + 'Are you missing a .transacting(trx) call?')); ^ TimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?

Pendant que nous travaillons à creuser nos connexions d'architecture, existe-t-il un moyen d'empêcher cette erreur de faire planter l'application ? Ou du moins l'erreur pourrait-elle signaler la pile ?

@rsfernandes Tant que vous utilisez des gestionnaires catch sur vos constructeurs, je ne vois pas en quoi cette erreur ferait planter toute l'application.

Quant à la pile, je recommande longStackTraces . Il n'y a rien dans knex spécifiquement pour cette pile d'erreurs.

FWIW J'ai eu cette erreur avec un service de base de données AWS Aurora, et elle était causée par la fonction d'arrêt automatique qui met fin à la base de données après l'inactivité (le démarrage automatique de la base de données prend environ une minute, et cela a causé l'expiration de knex)

https://github.com/tgriesser/knex/issues/3159 Il existe une liste de suggestions de travail autour des aurores.

@wubzz

1. Le pool est continuellement occupé à sa capacité maximale pendant au moins (par défaut) 60 secondes non-stop, par exemple en raison d'un trafic intense ou de procédures longues.

Si tel est le problème, quelles sont les recommandations possibles à prendre si vous ne pouvez pas simplement faire moins de travail ? ??

Augmenter le délai d'attente ou la capacité maximale ?

Mon problème n'était pas avec knex mais plutôt avec la règle entrante du groupe de sécurité sur mon aws RDS. Il a été défini uniquement sur l'adresse IP de ma machine locale et je ne pouvais donc pas m'y connecter à partir de l'instance ec2. était frustrant parce que le message d'erreur n'était pas utile.
Si vous avez ce message d'erreur, cela peut être lié au fait que knex ne peut pas établir de connexion. alors vérifiez aussi vos réseaux !

Oui, je suppose que cela peut arriver si la connexion est complètement bloquée... peut-être que la configuration d'un délai d'expiration de connexion différent et d'un délai d'expiration d'acquittement pourrait faire la distinction entre ces deux cas.

J'ai résolu le problème avec ces versions:

"knex": "^0.21.1",
"objection": "^2.1.3",
"pg": "^8.0.3"

Vous devrez peut-être passer au nœud 12 PAS au nœud 14

J'avais une limite de pool de bases de données, je pouvais résoudre le problème en définissant min et max

J'ai eu le même problème sur mon mac. J'exécutais knex à partir du terminal de ligne de commande et j'ai soudainement commencé à voir ce problème Knex: Timeout.... J'ai compris que le problème était de passer à zsh shell au lieu de bash. J'utilise bash depuis longtemps et j'ai récemment essayé de passer à zsh conformément aux directives d'Apple. Dès que je suis retourné à bash, c'était réparé.

J'espère que ça aide quelqu'un.

Vous devrez peut-être passer au nœud 12 PAS au nœud 14

Cela a fonctionné pour moi sur mac docker-compose node:12 au lieu de node (v14). Merci.

J'essayais d'appliquer la version du nœud du serveur en utilisant nvm exec 12 node ./src/index... et j'avais l'erreur ci-dessus.

En lançant directement node, l'erreur a disparu et la connexion a été établie.

Assurez-vous donc que vous utilisez une configuration simple et normale et peut-être le nœud 12.

@batadamnjanovic vous m'avez sauvé après deux jours complets de recherche. TY !!