restablecimiento de la conexión de la base de datos del enjambre de Docker

12

Estoy ejecutando una aplicación de arranque de primavera con Docker Swarm y uso postgres para la base de datos. Cuando ejecuto ambos como servicio acoplable, la conexión de la base de datos falla de manera consistente y aleatoria (como se puede ver en la marca de tiempo) como dice el registro:

2017-10-26T 17:14:15 .200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | REGISTRO: no se pudieron recibir datos del cliente: se restableció la conexión por igual

2017-10-26T 17:43:36 .481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | REGISTRO: no se pudieron recibir datos del cliente: se restableció la conexión por igual

2017-10-26T 17:43:56 .954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | REGISTRO: no se pudieron recibir datos del cliente: se restableció la conexión por igual

2017-10-26T 17:44:17 .434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | REGISTRO: no se pudieron recibir datos del cliente: se restableció la conexión por igual

2017-10-26T 17:49:04 .154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | REGISTRO: no se pudieron recibir datos del cliente: se restableció la conexión por igual

No pude entender o 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 expiró después de 937517 ms

Gracias.

— Elifcan Çakmak
fuente

10

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 cortafuegos que cortaba las conexiones entre los 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 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 : TRATANDO CON EXCEPCIONES NO DISPONIBLES EN LA BÚSQUEDA ELÁSTICA

— Aleksandr Kravets
fuente

Lo intentaré lo antes posible. ¡Gracias por su ayuda!

— Elifcan Çakmak

Hola, probé la solución y solo apliqué la primera parte. Ha estado funcionando desde ayer y no ha fallado. supongo que funciona :) muchas gracias!

— Elifcan Çakmak

Los contenedores que ejecutan el kernel 4.13 o posterior ya no heredarán tcp_keepalive_timedel host (fuente: success.docker.com/article/ipvs-connection-timeout-issue ), por lo que este enfoque ya no funcionará con contenedores más nuevos. Sin embargo, a partir de Docker 19.03 hay una sysctlopción que se puede suministrar a los servicios (por ejemplo, en un archivo de composición). Esto se puede utilizar para establecer los indicadores anteriores directamente en los contenedores sin interferir con el host. docs.docker.com/compose/compose-file/#sysctls

— avejidah

2

Hay otra forma de evitar el cierre de la conexión inactiva. El problema está relacionado con el descubrimiento predeterminado del servicio de enjambre que cierra la conexión inactiva después de 15 minutos.
Explícitamente especificado, el dnsrr modo de punto final resuelve el problema, por ejemplo:

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
fuente