conexão de banco de dados docker swarm redefinida por peer

português
#1

Estou executando um aplicativo de inicialização do spring com docker swarm e uso postgres para banco de dados. Quando executo os dois como serviço docker, a conexão do banco de dados falha de forma consistente e Aleatória (como você pode ver no carimbo de data / hora), como diz O log:

2017-10-26T17:14:15.200415747z app-db.1.1ayo6h8ro1og@scw-c2964a / LOG: não foi possível receber dados do cliente: redefinição de conexão por peer

2017-10-26T17:43:36.481718562z app-db.1.1ayo6h8ro1og@scw-c2964a / LOG: não foi possível receber dados do cliente: redefinição de conexão por peer

2017-10-26T17:43:56.954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a / LOG: não foi possível receber dados do cliente: redefinição de conexão por peer

2017-10-26T17:44:17.434171472z app-db.1.1ayo6h8ro1og@scw-c2964a / LOG: não foi possível receber dados do cliente: redefinição de conexão por peer

2017-10-26T17:49:04.154174253z app-db.1.1ayo6h8ro1og@scw-c2964a / LOG: não foi possível receber dados do cliente: redefinição de conexão por peer

Eu não conseguia entender ou descobrir o motivo disso. Eu apreciaria qualquer ideia.

editar:

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

Sqltransientconnectionexception: HikariPool-1-A conexão não está disponível, o pedido expirou após 937517ms

Obrigado.

#2

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 descartando conexões entre 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

Também, incluí as seguintes propriedades do pool de conexão 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 deste blogpost: LIDANDO COM EXCEÇÕES NODENOTAVAILABLE NO ELASTICSEARCH

#3

Existe outra maneira de evitar o fechamento da conexão ociosa. O problema está relacionado à descoberta de Serviço padrão do swarm, que fecha a conexão ociosa após 15 minutos.
Explicit especificou o dnsrr modo endpoint resolve o problema, por exemplo.:

version: '3.3'services:  foo-service:    image: example/foo-service:latest    hostname: foo-service    networks:      - foo_network    deploy:      endpoint_mode: dnsrr      # ...networks:  foo_network:    external: true    driver: overlay