restablecimiento de la conexión de la base de datos docker swarm por pares

español
#1

Estoy ejecutando una aplicación spring boot con docker swarm y uso postgres para la base de datos. Cuando ejecuto ambos como servicio docker, la conexión de la base de datos falla de manera consistente y aleatoria (como puede ver en la marca de tiempo) como dice el registro:

2017-10-26T17:14:15.200415747Z aplicación-db.1.1ayo6h8ro1og@scw-c2964a / LOG: no se pudieron recibir datos del cliente: restablecimiento de la conexión por parte del par

2017-10-26T17:43:36.481718562Z aplicación-db.1.1ayo6h8ro1og@scw-c2964a / LOG: no se pudieron recibir datos del cliente: restablecimiento de la conexión por parte del par

2017-10-26T17:43:56.954152654Z aplicación-db.1.1ayo6h8ro1og@scw-c2964a / LOG: no se pudieron recibir datos del cliente: restablecimiento de la conexión por parte del par

2017-10-26T17:44:17.434171472Z aplicación-db.1.1ayo6h8ro1og@scw-c2964a / LOG: no se pudieron recibir datos del cliente: restablecimiento de la conexión por parte del par

2017-10-26T17:49:04.154174253Z aplicación-db.1.1ayo6h8ro1og@scw-c2964a / LOG: no se pudieron recibir datos del cliente: restablecimiento de la conexión por parte del par

No pude entender ni descubrir la razón de esto. Agradecería cualquier idea.

editar:

nos dimos cuenta de que, al probar la aplicación, también arroja un error como este:

SQLTransientConnectionException: HikariPool-1 - La conexión no está disponible, la solicitud se agotó después de 937517 ms

Gracias.

#2

Tengo el mismo error al implementar la pila Docker Swarm de la aplicación Spring Boot y PostgreSQL. Después de luchar con esto durante aproximadamente una semana, descubrí que el problema estaba en el firewall que dejaba caer las conexiones entre contenedores debido a la inactividad. Respuesta rápida, ejecute el siguiente cmd en la máquina Linux:

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

Además, he incluido las siguientes propiedades del grupo de conexiones de 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 solución vino de esta publicación de blog: MANEJO DE EXCEPCIONES NODENOTAVAILABLE EN ELASTICSEARCH

#3

Hay otra forma de evitar el cierre de la conexión inactiva. El problema está relacionado con la detección predeterminada del servicio de enjambre, que cierra la conexión inactiva después de 15 minutos.
Especificó explícitamente el dnsrr modo de punto final resuelve el problema, p. ej.:

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