Knex: получение «Knex: тайм-аут при получении соединения. Пул, вероятно, полон». ошибка

Я также сталкиваюсь с этой проблемой.

У меня точно такая же проблема.

Решение состоит в том, чтобы изолировать источник и исправить его. Это не ошибка "запроса", а скорее проблема архитектуры приложения. Ошибка возникает, когда knex не может получить соединение в течение (по умолчанию) 60 секунд, и, скорее всего, причина этого в том, что пул заполнен.

Другими словами, есть много вещей, которые могут вызвать ошибку. Двумя наиболее распространенными являются:

1. Вы забываете фиксировать транзакции/забываете вызывать .transacing(trx) в построителях запросов, уже находясь в максимальном пуле, что не только приводит к бездействию транзакции, но и выдает ошибку, поскольку соединение не может быть установлено.
2. Пул постоянно остается занятым с максимальной емкостью в течение не менее (по умолчанию) 60 секунд без остановок, например, из-за интенсивного трафика или длительных процедур.

Вы должны проверить состояние вашей базы данных, когда возникает эта ошибка - много ли незанятых соединений? не слишком ли много соединений? и Т. Д.

Я также сталкиваюсь с этой ошибкой.

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?

Пока мы работаем над подключением к нашей архитектуре, есть ли способ предотвратить сбой приложения из-за этой ошибки? Или, по крайней мере, ошибка может указывать на стек?

@rsfernandes Пока вы используете обработчики catch в своих сборщиках, я не понимаю, как эта ошибка приведет к сбою всего приложения.

Что касается стека, я рекомендую longStackTraces . В knex нет ничего встроенного специально для этого стека ошибок.

FWIW Я получил эту ошибку со службой базы данных AWS Aurora, и она была вызвана функцией автоматического отключения, которая завершает работу базы данных после бездействия (автоматический запуск базы данных занимает примерно минуту или около того, и это привело к тайм-ауту knex)

https://github.com/tgriesser/knex/issues/3159 Существует список некоторых предложений по работе с северным сиянием.

@wubzz

1. Пул постоянно остается занятым с максимальной емкостью в течение не менее (по умолчанию) 60 секунд без остановок, например, из-за интенсивного трафика или длительных процедур.

Если проблема в этом, какие возможные рекомендации можно принять, если просто нельзя выполнять меньше работы? 😅

Увеличить время ожидания или максимальную емкость?

Моя проблема была не с knex, а скорее с правилом входящего трафика группы безопасности на моем aws RDS. Он был настроен только на IP-адрес моего локального компьютера, поэтому я не мог подключиться к нему из экземпляра ec2. было неприятно, потому что сообщение об ошибке не было полезным.
Если у вас есть это сообщение об ошибке, это может быть связано с тем, что knex не может установить соединение. так что проверьте свои сети тоже!

Да, я полагаю, что это может произойти, если соединение полностью заблокировано ... возможно, установка другого тайм-аута соединения и тайм-аута подтверждения могла бы различить эти два случая.

Я решил проблему с этими версиями:

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

Возможно, вам придется переключиться на Node 12, а не на Node 14.

У меня было ограничение на пул базы данных, я мог решить проблему, установив минимум и максимум

У меня была такая же проблема на моем Mac. я запускал knex из терминала командной строки и внезапно начал видеть эту проблему Knex: Timeout.... Я понял, что проблема заключалась в переходе на оболочку zsh вместо bash. Я давно использую bash и недавно попытался перейти на zsh в соответствии с рекомендациями Apple. Как только я вернулся к bash, это было исправлено.

Надеюсь, это поможет кому-то.

Возможно, вам придется переключиться на Node 12, а не на Node 14.

Это сработало для меня на mac docker-compose node:12 вместо node (v14). Спасибо.

Я пытался принудительно использовать версию узла сервера с помощью nvm exec 12 node ./src/index... и получил указанную выше ошибку.

Запустив узел напрямую, ошибка исчезла и соединение установилось.

Поэтому убедитесь, что вы используете простую, обычную настройку и, возможно, узел 12.

@batadamnjanovic , ты спас меня после двух полных дней исследований. ТЫ !!