Knex: obtendo "Knex: Tempo limite adquirindo uma conexão. O pool provavelmente está cheio." erro

Também estou enfrentando esse problema.

Eu tenho o mesmo problema.

A solução é isolar a fonte e corrigi-la. Este não é um erro de "consulta", mas sim um problema de arquitetura do aplicativo. O erro ocorre quando o knex não consegue adquirir uma conexão em (padrão) 60 segundos, e provavelmente o motivo disso é que o pool está cheio.

Em outras palavras, há muitas coisas que podem causar o erro. Dois dos mais comuns são:

1. Você esquece de confirmar transações / esquece de chamar .transacing(trx) nos construtores de consultas enquanto já está no pool máximo, o que não apenas faz com que a transação fique ociosa, mas também gera o erro, pois nenhuma conexão pode ser adquirida.
2. O pool é mantido continuamente ocupado na capacidade máxima por pelo menos (padrão) 60 segundos sem parar, por exemplo, devido a tráfego intenso ou procedimentos de longa duração.

Você deve examinar o estado do banco de dados quando esse erro ocorrer - há muitas conexões ociosas? há muitas conexões? etc.

Também estou enfrentando esse erro.

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?

Enquanto estamos trabalhando para cavar nossas conexões de arquitetura, existe uma maneira de evitar que esse erro trave o aplicativo? Ou pelo menos o erro poderia apontar a pilha?

@rsfernandes Contanto que você use manipuladores catch em seus construtores, não vejo como esse erro travaria todo o aplicativo.

Quanto à pilha, recomendo longStackTraces . Não há nada embutido no knex especificamente para esta pilha de erros.

FWIW, recebi esse erro com um serviço de banco de dados do AWS Aurora e foi causado pelo recurso de desligamento automático que encerra o banco de dados após a inatividade (a inicialização automática do banco de dados leva cerca de um minuto e isso causou o tempo limite do knex)

https://github.com/tgriesser/knex/issues/3159 Há uma lista de algumas sugestões de trabalho para aurora.

@wubzz

1. O pool é mantido continuamente ocupado na capacidade máxima por pelo menos (padrão) 60 segundos sem parar, por exemplo, devido a tráfego intenso ou procedimentos de longa duração.

Se este for o problema, quais são as recomendações possíveis a serem tomadas se não puder simplesmente fazer menos trabalho? 😅

Aumentar o tempo limite ou a capacidade máxima?

Meu problema não era com o knex, mas sim com a regra de entrada do grupo de segurança no meu aws RDS. Ele foi definido apenas para o endereço IP da minha máquina local e, portanto, não consegui me conectar a ele a partir da instância ec2. foi frustrante porque a mensagem de erro não foi útil.
Se você tiver esta mensagem de erro, pode estar relacionada ao fato de que o knex não pode estabelecer uma conexão. então verifique suas redes também!

Sim, suponho que isso pode acontecer se a conexão for bloqueada completamente ... talvez configurar um tempo limite de conexão diferente e um tempo limite de aquisição possa distinguir entre esses dois casos.

Resolvi o problema com estas versões:

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

Você pode ter que mudar para o Node 12 NOT Node 14

Eu tinha um limite de pool de banco de dados, eu poderia corrigir o problema definindo min e max

Eu tive o mesmo problema no meu mac. eu estava executando o knex do terminal de linha de comando e de repente comecei a ver este problema Knex: Timeout.... Descobri que o problema estava se movendo para o shell zsh em vez do bash. Estou usando o bash há muito tempo e recentemente tentei mudar para zsh de acordo com as diretrizes da Apple. Assim que voltei ao bash, foi corrigido.

Espero que ajude alguém.

Você pode ter que mudar para o Node 12 NOT Node 14

Isso funcionou para mim no mac docker-compose node:12 em vez de node (v14). Obrigado.

Eu estava tentando aplicar usando a versão do nó do servidor usando nvm exec 12 node ./src/index... e estava tendo o erro acima.

Ao iniciar o nó diretamente, o erro desapareceu e a conexão foi estabelecida.

Portanto, certifique-se de estar usando uma configuração simples e normal e talvez o nó 12.

@batadamnjanovic você me salvou depois de dois dias inteiros de pesquisa. TA!!