15 votes

torost avatar

Docker essaim réinitialiser la connexion à la base de données par pair

Demandé el 26 de Octobre, 2017
Quand la question a-t-elle été
5703 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je lance une application Spring Boot avec Docker Swarm et j'utilise postgres comme base de données. Lorsque je les exécute tous les deux en tant que service docker, la connexion à la base de données échoue de manière constante et aléatoire (comme vous pouvez le voir sur l'horodatage) comme le dit le journal :

2017-10-26T17:14:15.200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: could not receive data from client: Connection reset by peer

2017-10-26T17:43:36.481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: could not receive data from client: Connection reset by peer

2017-10-26T17:43:56.954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: could not receive data from client: Connection reset by peer

2017-10-26T17:44:17.434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: could not receive data from client: Connection reset by peer

2017-10-26T17:49:04.154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: could not receive data from client: Connection reset by peer

Je n'ai pas compris ou découvert la raison de cela. Je serais reconnaissant pour toutes les idées.

edit:

nous avons réalisé que, lors des tests de l'application, il lance également des erreurs comme celle-ci :

SQLTransientConnectionException: HikariPool-1 - La connexion n'est pas disponible, la demande a expiré après 937517ms

Merci.

Demandé el 26 de Octobre, 2017 par torost

Réponses

Trop de publicités?

11voto

Utilisateur non enregistré avatar
Utilisateur non enregistré Points 0

J'ai rencontré la même erreur en déployant une pile Docker Swarm d'une application Spring Boot et PostgreSQL. Après avoir lutté avec cela pendant environ une semaine, j'ai compris que le problème était dû au pare-feu qui abandonnait les connexions entre les conteneurs en raison de l'inactivité. La réponse rapide est d'exécuter la commande suivante sur une machine Linux :

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

De plus, j'ai inclus les propriétés suivantes du pool de connexions 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 solution provient de cet article de blog : GÉRER LES EXCEPTIONS NODENOTAVAILABLE DANS ELASTICSEARCH

Répondu el 26 de Novembre, 2017 par Utilisateur non enregistré (0 Points )

6voto

Daniel T. avatar
Daniel T. Points 11250

Il existe une autre manière d'empêcher la fermeture de la connexion inactive. Le problème est lié à la découverte de service en mode essaim par défaut qui ferme la connexion inactive après 15 minutes.
La spécification explicite du mode de point de terminaison dnsrr résout le problème, par exemple :

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
Répondu el 18 de Février, 2019 par Daniel T. (11250 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X