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

12

Estou executando um aplicativo de inicialização com o docker swarm e uso o postgres no 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 carimbo de data / hora), conforme o log diz:

2017-10-26T 17: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 ponto

2017-10-26T 17: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 ponto

2017-10-26T 17: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 ponto

2017-10-26T 17: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 ponto

2017-10-26T 17: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 ponto

Eu não conseguia entender ou descobrir o motivo disso. Eu apreciaria todas as idéias.

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, a solicitação expirou após 937517ms

Obrigado.

— Elifcan Çakmak
fonte

10

Tenho o mesmo erro ao implantar a pilha Docker Swarm do aplicativo Spring Boot e do PostgreSQL. Depois de lutar por isso por cerca de uma semana, eu descobri que o problema era no firewall que derrubava conexões entre contêineres devido à 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 conjunto 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 INDENIZÁVEIS NA PESQUISA ELÁSTICA

— Aleksandr Kravets
fonte

Vou tentar isso o mais rápido possível.Obrigado pela sua ajuda!

— Elifcan Çakmak

oi, tentei a solução e apliquei apenas a primeira parte. está ativo desde ontem e não falhou. Eu acho que funciona :) muito obrigado!

— Elifcan Çakmak

Os contêineres executando o kernel 4.13 ou posterior não serão mais herdados tcp_keepalive_timedo host (fonte: success.docker.com/article/ipvs-connection-timeout-issue ), portanto, essa abordagem não funcionará mais com contêineres mais novos. No entanto, a partir do Docker 19.03, existe uma sysctlopção que pode ser fornecida aos serviços (por exemplo, em um arquivo de composição). Isso pode ser usado para definir os sinalizadores acima diretamente nos contêineres sem mexer com o host. docs.docker.com/compose/compose-file/#sysctls

— avejidah

2

Há outra maneira de impedir o fechamento da conexão inativa. O problema está relacionado à descoberta de serviço de enxame padrão, que fecha a conexão inativa após 15 minutos.
Explícito especificado, o dnsrr modo do nó de extremidade 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

— xxxception
fonte