Docker swarm connessione al database ripristinata dal peer

12

Sto eseguendo un'applicazione di avvio a molla con Docker Swarm e utilizzo Postgres per il database. Quando li eseguo entrambi come servizio docker, la connessione al database non riesce in modo coerente e casuale (come puoi vedere sul timestamp) come dice il registro:

26-10-2017 17:14:15 .200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossibile ricevere dati dal client: connessione reimpostata dal peer

26-10-2017 17:43:36 .481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossibile ricevere dati dal client: connessione reimpostata dal peer

26-10-2017 17:43:56 .954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossibile ricevere dati dal client: connessione reimpostata dal peer

26-10-2017 17:44:17 .434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossibile ricevere dati dal client: connessione reimpostata dal peer

26-10-2017 17:49:04 .154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossibile ricevere dati dal client: connessione reimpostata dal peer

Non riuscivo a capire o scoprire il motivo di ciò. Gradirei qualsiasi idea.

modificare:

ci siamo resi conto che, durante il test dell'applicazione, genera anche errori come questo:

SQLTransientConnectionException: HikariPool-1 - Connessione non disponibile, richiesta scaduta dopo 937517ms

Grazie.

— Elifcan Çakmak
fonte

10

Ho lo stesso errore durante la distribuzione dello stack Docker Swarm dell'app Spring Boot e PostgreSQL. Dopo aver combattuto con questo per circa una settimana, ho capito che il problema era causato dal fatto che il firewall interrompeva le connessioni tra i contenitori a causa dell'inattività. Risposta rapida, esegui il seguente cmd su macchina linux:

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

Inoltre, ho incluso le seguenti proprietà del pool di connessioni 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

La soluzione è arrivata da questo post sul blog: AFFARE CON ECCEZIONI DISPONIBILI NODEN IN ELASTICSEARCH

— Aleksandr Kravets
fonte

Lo proverò al più presto. Grazie per il vostro aiuto!

— Elifcan Çakmak,

ciao, ho provato la soluzione e ho applicato solo la prima parte. è attivo da ieri e non è fallito. immagino che funzioni :) grazie mille!

— Elifcan Çakmak,

I contenitori che eseguono il kernel 4.13 o successivo non erediteranno più tcp_keepalive_timedall'host (fonte: success.docker.com/article/ipvs-connection-timeout-issue ), quindi questo approccio non funzionerà più con i contenitori più recenti. Tuttavia, a partire da Docker 19.03 esiste sysctlun'opzione che può essere fornita ai servizi (ad es. In un file di composizione). Questo può essere usato per impostare i flag sopra direttamente nei contenitori senza fare confusione con l'host. docs.docker.com/compose/compose-file/#sysctls

— avejidah

2

Esiste un altro modo per impedire la chiusura della connessione inattiva. Il problema è correlato all'individuazione del servizio swarm predefinito che chiude la connessione inattiva dopo 15 minuti.
Specificato esplicitamente la dnsrr modalità endpoint risolve il problema, ad esempio:

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