resetowanie połączenia bazy danych roju dokerów przez użytkownika

12

Korzystam z aplikacji rozruchu wiosennego z dokiem roju i używam postgres do bazy danych. Po uruchomieniu obu z nich jako usługi dokowania połączenie z bazą danych nie jest spójne i losowe (jak widać na znaczniku czasu), ponieważ dziennik mówi:

2017-10-26T 17:14:15 .200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: nie można odebrać danych od klienta: połączenie zresetowane przez peer

2017-10-26T 17:43:36 .481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: nie można odebrać danych od klienta: resetowanie połączenia przez peer

2017-10-26T 17:43:56 .954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: nie można odebrać danych od klienta: połączenie zresetowane przez peer

2017-10-26T 17:44:17 .434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: nie można odebrać danych od klienta: połączenie zresetowane przez peer

2017-10-26T 17:49:04 .154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: nie można odebrać danych od klienta: połączenie zresetowane przez peer

Nie mogłem zrozumieć ani odkryć przyczyny tego. Byłbym wdzięczny za wszelkie pomysły.

edytować:

zdaliśmy sobie sprawę, że podczas testowania aplikacji zgłasza również następujący błąd:

SQLTransientConnectionException: HikariPool-1 - Połączenie nie jest dostępne, żądanie przekroczyło limit czasu po 937517ms

Dzięki.

— Elifcan Çakmak
źródło

10

Mam ten sam błąd podczas wdrażania stosu Docker Swarm w aplikacji Spring Boot i PostgreSQL. Po około tygodniu walki z tym zorientowałem się, że problem polegał na tym, że zapora sieciowa zrywała połączenia między kontenerami z powodu braku aktywności. Szybka odpowiedź, uruchom następujące polecenie cmd na maszynie z systemem Linux:

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

Podałem również następujące właściwości puli połączeń 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

Rozwiązanie pochodzi z tego wpisu na blogu: ROZWIĄZYWANIE WYJĄTKOWYCH WYJĄTKÓW W ELASTICSEARCH

— Aleksandr Kravets
źródło

Spróbuję tego jak najszybciej. Dzięki za pomoc!

— Elifcan Çakmak

cześć, wypróbowałem rozwiązanie i zastosowałem tylko pierwszą część. od wczoraj działa i nie zawiodło. chyba to działa :) wielkie dzięki!

— Elifcan Çakmak

Kontenery z jądrem 4.13 lub nowszym nie będą już dziedziczyć tcp_keepalive_timepo hoście (źródło: success.docker.com/article/ipvs-connection-timeout-issue ), więc to podejście nie będzie działać z nowszymi kontenerami. Jednak od Docker 19.03 istnieje sysctlopcja, która może być dostarczana do usług (np. W pliku tworzenia). Można tego użyć do ustawienia powyższych flag bezpośrednio w kontenerach, bez bałagania z hostem. docs.docker.com/compose/compose-file/#sysctls

— avejidah

2

Istnieje inny sposób, aby zapobiec zamknięciu bezczynnego połączenia. Problem związany jest z domyślnym wykrywaniem usługi roju, która zamyka bezczynne połączenie po 15 minutach.
Wyraźny określony, dnsrr tryb końcowym rozwiązuje ten problem, na przykład:

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
źródło