Knex: "Knex: Timeout beim Herstellen einer Verbindung. Der Pool ist wahrscheinlich voll." Error

ich stehe auch vor diesem Problem.

Ich habe das gleiche Problem.

Die Lösung besteht darin, die Quelle zu isolieren und zu beheben. Dies ist kein "Abfragefehler", sondern ein Problem mit der Anwendungsarchitektur. Der Fehler tritt auf, wenn Knex innerhalb von (Standard) 60 Sekunden keine Verbindung herstellen kann, und wahrscheinlich ist der Grund dafür, dass der Pool voll ist.

Mit anderen Worten, es gibt viele Dinge, die den Fehler verursachen können. Zwei der häufigsten sind:

1. Sie vergessen, Transaktionen festzuschreiben / vergessen, .transacing(trx) für Abfrage-Builder aufzurufen, während Sie bereits bei maximalem Pool sind, was nicht nur dazu führt, dass die Transaktion inaktiv wird, sondern auch den Fehler auslöst, da keine Verbindung hergestellt werden konnte.
2. Der Pool wird kontinuierlich mit maximaler Kapazität für mindestens (Standard) 60 Sekunden nonstop beschäftigt, zum Beispiel aufgrund von starkem Verkehr oder lang andauernden Verfahren.

Sie sollten Ihren Datenbankstatus überprüfen, wenn dieser Fehler auftritt. Gibt es viele Verbindungen im Leerlauf? Gibt es zu viele Verbindungen? etc.

Ich stehe auch vor diesem Fehler.

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?

Während wir daran arbeiten, unsere Architekturverbindungen zu graben, gibt es eine Möglichkeit, zu verhindern, dass dieser Fehler die Anwendung zum Absturz bringt? Oder könnte zumindest der Fehler auf den Stack hinweisen?

@rsfernandes Solange Sie catch -Handler für Ihre Builder verwenden, sehe ich nicht, wie dieser Fehler die gesamte Anwendung zum Absturz bringen würde.

Was den Stack angeht, empfehle ich longStackTraces . In Knex ist nichts speziell für diesen Fehlerstapel eingebaut.

FWIW Ich habe diesen Fehler bei einem AWS Aurora-Datenbankservice erhalten, und er wurde durch die Funktion zum automatischen Herunterfahren verursacht, die die Datenbank nach Inaktivität beendet (der automatische Start der Datenbank dauert etwa eine Minute, und dies führte zu einer Zeitüberschreitung bei Knex).

https://github.com/tgriesser/knex/issues/3159 Es gibt eine Liste mit Vorschlägen zur Umgehung von Aurora.

@wubzz

1. Der Pool wird kontinuierlich mit maximaler Kapazität für mindestens (Standard) 60 Sekunden nonstop beschäftigt, zum Beispiel aufgrund von starkem Verkehr oder lang andauernden Verfahren.

Wenn dies das Problem ist, was sind mögliche Empfehlungen, wenn Sie nicht einfach weniger Arbeit leisten können? 😅.

Timeout oder maximale Kapazität erhöhen?

Mein Problem war nicht mit Knex, sondern eher mit der Regel für eingehende Sicherheitsgruppen auf meinem AWS RDS. Es war nur auf die IP-Adresse meines lokalen Computers eingestellt und ich konnte keine Verbindung von der ec2-Instanz aus herstellen. war frustrierend, da die Fehlermeldung nicht hilfreich war.
Wenn Sie diese Fehlermeldung erhalten, kann dies damit zusammenhängen, dass Knex keine Verbindung herstellen kann. Überprüfen Sie also auch Ihre Netzwerke!

Ja, ich nehme an, das kann passieren, wenn die Verbindung vollständig blockiert wird ... vielleicht könnte das Einrichten unterschiedlicher Verbindungszeitüberschreitungen und freier Zeitüberschreitungen zwischen diesen beiden Fällen unterscheiden.

Ich habe das Problem mit diesen Versionen gelöst:

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

Möglicherweise müssen Sie zu Knoten 12, NICHT zu Knoten 14 wechseln

Ich hatte ein Datenbank-Pool-Limit, ich konnte das Problem beheben, indem ich Min und Max festlegte

Ich hatte das gleiche Problem auf meinem Mac. Ich habe Knex über das Befehlszeilenterminal ausgeführt und plötzlich dieses Problem mit Knex: Timeout ... gesehen. Ich fand heraus, dass das Problem darin bestand, auf die zsh-Shell anstelle von bash zu wechseln. Ich benutze bash schon lange und habe kürzlich versucht, gemäß den Apple-Richtlinien auf zsh umzusteigen. Sobald ich zurück zur Bash ging, war es behoben.

Hoffe es hilft jemandem.

Möglicherweise müssen Sie zu Knoten 12, NICHT zu Knoten 14 wechseln

Dies funktionierte für mich auf dem Mac docker-compose node:12 anstelle von node (v14). Danke.

Ich habe versucht, die Verwendung der Knotenversion des Servers mit nvm exec 12 node ./src/index... zu erzwingen, und hatte den obigen Fehler.

Durch den direkten Start von node verschwand der Fehler und die Verbindung wurde hergestellt.

Stellen Sie also sicher, dass Sie ein einfaches, normales Setup und möglicherweise Knoten 12 verwenden.

@batadamnjanovic du hast mich nach zwei vollen Tagen Recherche gerettet. TY!!