connexion de la base de données swarm docker réinitialisée par l'homologue

12

J'utilise une application Spring Boot avec Docker Swarm et j'utilise PostgreSQL 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 cohérente et aléatoire (comme vous pouvez le voir sur l'horodatage) comme le journal le dit:

2017-10-26T 17:14:15 .200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossible de recevoir des données du client: réinitialisation de la connexion par l'homologue

2017-10-26T 17:43:36 .481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossible de recevoir des données du client: réinitialisation de la connexion par l'homologue

2017-10-26T 17:43:56 .954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossible de recevoir des données du client: réinitialisation de la connexion par l'homologue

2017-10-26T 17:44:17 .434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossible de recevoir des données du client: réinitialisation de la connexion par l'homologue

2017-10-26T 17:49:04 .154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: impossible de recevoir des données du client: réinitialisation de la connexion par l'homologue

Je ne pouvais pas comprendre ou découvrir la raison de cela. J'apprécierais toutes les idées.

Éditer:

nous avons réalisé que lors du test de l'application, il génère également une erreur comme celle-ci:

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

Merci.

— Elifcan Çakmak
source

10

J'ai la même erreur lors du déploiement de la pile Docker Swarm de l'application Spring Boot et de PostgreSQL. Après avoir lutté avec cela pendant environ une semaine, j'ai compris que le problème venait du pare-feu qui interrompait les connexions entre les conteneurs en raison de l'inactivité. Réponse rapide, exécutez le cmd suivant 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 de pool de connexions tomcat suivantes:

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 est venue de ce blog: GÉRER LES EXCEPTIONS NODÉNOTAVAILABLE DANS ELASTICSEARCH

— Aleksandr Kravets
source

Je vais essayer cela dès que possible.Merci de votre aide!

— Elifcan Çakmak

salut, j'ai essayé la solution et je n'ai appliqué que la première partie. il a augmenté depuis hier et n'a pas échoué. je suppose que ça marche :) merci beaucoup!

— Elifcan Çakmak

Les conteneurs exécutant le noyau 4.13 ou version ultérieure n'hériteront plus tcp_keepalive_timede l'hôte (source: success.docker.com/article/ipvs-connection-timeout-issue ), cette approche ne fonctionnera donc plus avec les conteneurs plus récents. Cependant, à partir de Docker 19.03, une sysctloption peut être fournie aux services (par exemple dans un fichier de composition). Cela peut être utilisé pour définir les drapeaux ci-dessus directement dans les conteneurs sans déconner avec l'hôte. docs.docker.com/compose/compose-file/#sysctls

— avejidah

2

Il existe un autre moyen d'empêcher la fermeture de la connexion inactive. Le problème est lié à la découverte du service Swarm par défaut qui ferme la connexion inactive après 15 minutes.
Le dnsrr mode endpoint spécifié résout explicitement 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

— xxxception
source