Назад | Перейти на главную страницу

сброс соединения с базой данных docker swarm одноранговым узлом

Я запускаю приложение для весенней загрузки с docker swarm и использую postgres для базы данных. Когда я запускаю их обоих как службу докеров, соединение с базой данных прерывается последовательно и случайным образом (как вы можете видеть на метке времени), как говорится в журнале:

2017-10-26т17:14:15.200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | ЖУРНАЛ: не удалось получить данные от клиента: сброс соединения одноранговым узлом

2017-10-26т17:43:36.481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | ЖУРНАЛ: не удалось получить данные от клиента: сброс соединения одноранговым узлом

2017-10-26т17:43:56.954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | ЖУРНАЛ: не удалось получить данные от клиента: сброс соединения одноранговым узлом

2017-10-26т17:44:17.434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | ЖУРНАЛ: не удалось получить данные от клиента: сброс соединения одноранговым узлом

2017-10-26т17:49:04.154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | ЖУРНАЛ: не удалось получить данные от клиента: сброс соединения одноранговым узлом

Я не мог понять или обнаружить причину этого. Буду признателен за любые идеи.

редактировать:

мы поняли, что при тестировании приложения оно также выдает такую ​​ошибку:

SQLTransientConnectionException: HikariPool-1 - соединение недоступно, запрос истек через 937517 мс

Спасибо.

У меня такая же ошибка при развертывании стека Docker Swarm приложения Spring Boot и PostgreSQL. После того, как я боролся с этим около недели, я понял, что проблема заключалась в том, что брандмауэр разрывает соединения между контейнерами из-за бездействия. Быстрый ответ, запустите следующую команду на Linux-машине:

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

Кроме того, я включил следующие свойства пула соединений 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

Решение взято из этого сообщения в блоге: РАБОТА С НЕДОСТУПНЫМИ ИСКЛЮЧЕНИЯМИ В ELASTICSEARCH

Есть еще один способ предотвратить закрытие неактивного соединения. Проблема связана с обнаружением службы роя по умолчанию, которая закрывает бездействующее соединение через 15 минут.
Явно указал dnsrr режим конечной точки решает проблему, например:

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