docker swarm database connection redefinido pelo peer

Question

Eu estou executando um aplicativo de inicialização de mola com enxame docker e eu uso postgres para banco de dados. Quando executo os dois como serviço docker, a conexão com o banco de dados falha de forma consistente e aleatória (como você pode ver no registro de data e hora) conforme o log informa:

2017-10-26T 17:14:15 .200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: não pôde receber dados do cliente: Conexão redefinida pelo peer

2017-10-26T 17:43:36 .481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: não pôde receber dados do cliente: Conexão redefinida pelo peer

2017-10-26T 17:43:56 .954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: não pôde receber dados do cliente: Conexão redefinida pelo peer

2017-10-26T 17:44:17 .434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: não pôde receber dados do cliente: Conexão redefinida pelo peer

2017-10-26T 17:49:04 .154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: não pôde receber dados do cliente: Conexão redefinida pelo peer

Eu não consegui entender ou descobrir o motivo disso. Eu apreciaria quaisquer ideias.

editar:

percebemos que, ao testar o aplicativo, ele também gera um erro como este:

SQLTransientConnectionException: HikariPool-1 - A conexão não está disponível, a solicitação expirou após 937517ms

Obrigado.

    

Answer 1

Eu tenho o mesmo erro ao implantar a pilha Docker Swarm do aplicativo Spring Boot e do PostgreSQL. Depois de lutar com isso por cerca de uma semana, descobri que o problema estava no firewall perdendo conexões entre os contêineres por causa da inatividade. Resposta rápida, execute o seguinte cmd na máquina linux:

sudo sysctl -w \
net.ipv4.tcp_keepalive_time=600 \
net.ipv4.tcp_keepalive_intvl=60 \
net.ipv4.tcp_keepalive_probes=3

Além disso, incluí as seguintes propriedades do pool de conexões do tomcat:

tomcat:
  max-active: 10
  initial-size: 5
  max-idle: 8
  min-idle: 5
  test-on-borrow: true
  test-while-idle: true
  test-on-return: false
  test-on-connect: true
  validation-query: SELECT 1
  validation-interval: 30000
  max-wait: 30000
  min-evictable-idle-time-millis: 60000
  time-between-eviction-runs-millis: 5000
  remove-abandoned: true
  remove-abandoned-timeout: 60

A solução veio desta postagem do blog: LIDANDO COM EXCEÇÕES NODENOTAVAILABLE EM ELASTICSEARCH