सहकर्मी द्वारा डॉकर झुंड डेटाबेस कनेक्शन रीसेट

हिंदी
#1

मैं डॉकर झुंड के साथ एक स्प्रिंग बूट एप्लिकेशन चला रहा हूं और मैं डेटाबेस के लिए पोस्टग्रेज का उपयोग करता हूं । जब मैं दोनों को डॉकर सेवा के रूप में चलाता हूं, तो डेटाबेस कनेक्शन लगातार और बेतरतीब ढंग से विफल हो जाता है (जैसा कि आप टाइमस्टैम्प पर देख सकते हैं) जैसा कि लॉग कहता है:

2017-10-26T17:14:15.200415747Z एप्लिकेशन-db.1.1ayo6h8ro1og@scw-c2964a / लॉग: क्लाइंट से डेटा प्राप्त नहीं कर सका: सहकर्मी द्वारा कनेक्शन रीसेट

2017-10-26T17:43:36.481718562Z एप्लिकेशन-db.1.1ayo6h8ro1og@scw-c2964a / लॉग: क्लाइंट से डेटा प्राप्त नहीं कर सका: सहकर्मी द्वारा कनेक्शन रीसेट

2017-10-26T17:43:56.954152654Z एप्लिकेशन-db.1.1ayo6h8ro1og@scw-c2964a / लॉग: क्लाइंट से डेटा प्राप्त नहीं कर सका: सहकर्मी द्वारा कनेक्शन रीसेट

2017-10-26T17:44:17.434171472Z एप्लिकेशन-db.1.1ayo6h8ro1og@scw-c2964a / लॉग: क्लाइंट से डेटा प्राप्त नहीं कर सका: सहकर्मी द्वारा कनेक्शन रीसेट

2017-10-26T17:49:04.154174253Z एप्लिकेशन-db.1.1ayo6h8ro1og@scw-c2964a / लॉग: क्लाइंट से डेटा प्राप्त नहीं कर सका: सहकर्मी द्वारा कनेक्शन रीसेट

मैं इसका कारण समझ या खोज नहीं सका । मैं किसी भी विचार की सराहना करता हूं ।

संपादित करें:

हमने महसूस किया कि, एप्लिकेशन का परीक्षण करते समय, यह इस तरह की त्रुटि भी फेंकता है:

एसक्यूएलट्रांसिएंट कनेक्शन अपवाद: हिकारिपूल -1-कनेक्शन उपलब्ध नहीं है, अनुरोध 937517 एमएमएस के बाद समय समाप्त हो गया है

धन्यवाद ।

#2

मुझे स्प्रिंग बूट ऐप और पोस्टग्रेएसक्यूएल के डॉकर झुंड स्टैक को तैनात करने में एक ही त्रुटि मिली है । लगभग एक सप्ताह तक इससे जूझने के बाद, मुझे पता चला है कि निष्क्रियता के कारण कंटेनरों के बीच फ़ायरवॉल छोड़ने वाले कनेक्शन में समस्या थी । त्वरित उत्तर, लिनक्स मशीन पर सीएमडी के बाद चलाएं:

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

साथ ही, मैंने निम्नलिखित टॉमकैट कनेक्शन पूल गुणों को शामिल किया है:

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

समाधान से आया इस blogpost: के साथ काम NODENOTAVAILABLE में अपवाद ELASTICSEARCH

#3

निष्क्रिय कनेक्शन को बंद करने से रोकने का एक और तरीका है । समस्या डिफ़ॉल्ट झुंड सेवा खोज से संबंधित है जो 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