Mysql: मारे गए कनेक्शन पर अजीब त्रुटि

को निर्मित 5 दिस॰ 2013 · 25टिप्पणियाँ · स्रोत: go-sql-driver/mysql

जब मैं उन कनेक्शनों को मारता हूं जिनमें लंबे समय तक चलने वाले प्रश्न होते हैं, तो मुझे इस तरह की चीजें मिलती हैं:

[MySQL] 2013/12/05 22:17:19 packets.go:30: EOF
[MySQL] 2013/12/05 22:17:19 statement.go:24: Invalid Connection
[MySQL] 2013/12/05 22:17:27 packets.go:30: EOF
[MySQL] 2013/12/05 22:17:27 statement.go:24: Invalid Connection
[MySQL] 2013/12/05 22:17:39 packets.go:30: EOF
[MySQL] 2013/12/05 22:17:39 statement.go:24: Invalid Connection

मुझे इस त्रुटि को देखने की आदत है:

2013 (HY000) at line 1: Lost connection to MySQL server during query

जहाँ तक मुझे पता है, उस त्रुटि को वास्तव में नेटवर्क कनेक्शन पर उस क्लाइंट को वापस भेज दिया जाता है जो मारा गया। क्या यह ड्राइवर या डेटाबेस / एसक्यूएल में मास्क किया जा रहा है, या क्या यह प्रोटोकॉल के माध्यम से प्रसारित त्रुटि नहीं है जैसा कि मुझे लगता है? क्या हम यह स्पष्ट कर सकते हैं कि क्या हो रहा है, किसी तरह?

bug thinking

स्रोत

xaprb

सबसे उपयोगी टिप्पणी

मुझे लगता है कि यह समस्या है:

package main

import (
    "database/sql"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, _ := sql.Open("mysql", "/")
    defer db.Close()
    tx, err := db.Begin()
    if err != nil {
        panic(err)
    }
    defer tx.Commit()
    stmt1, err := tx.Prepare("SELECT 1")
    if err != nil {
        panic(err)
    }
    rows1, err := stmt1.Query()
    if err != nil {
        panic(err)
    }
    stmt2, err := tx.Prepare("SELECT 2")
    if err != nil {
        // rows1 is not closed -> triggers busy buffer because transaction is on one connection
        // and stmt1, stmt2 use the same one.
        // Move rows1.Close() in front of tx.Prepare and it disappears
        panic(err)
    }
    rows2, err := stmt2.Query()
    if err != nil {
        panic(err)
    }
    rows1.Close()
    rows2.Close()
    stmt1.Close()
    stmt2.Close()
}

arnehormann 26 सित॰ 2014

👍4

सभी 25 टिप्पणियाँ

नहीं, कोई त्रुटि प्रसारित नहीं है। त्रुटि वास्तव में यह है कि कुछ भी प्राप्त नहीं किया जा सकता है: पलक:
लेकिन EOF तुलना में अधिक वर्णनात्मक त्रुटि संदेश प्रिंट करना एक अच्छा विचार हो सकता है

julienschmidt 6 दिस॰ 2013

मुझे लगता है कि statement.go:24: Invalid Connection त्रुटियां http://golang.org/issue/5718 का परिणाम हैं
डेटाबेस / sql पैकेज में ऑटो-पुन: कनेक्ट करने का तर्क तय होने पर वे त्रुटियां गायब हो जानी चाहिए।

EOF सिर्फ io.EOF , मुझे यकीन नहीं है कि हमें फ़िल्टर करना चाहिए और इसे बदलना चाहिए। यह इस तरह के मामलों के लिए उपयोग करने के लिए एक गो मुहावरा की तरह है (जैसे कि शुद्ध पैकेज में, जहां यह त्रुटि उत्पन्न होती है)। लेकिन कम से कम अर्थ का कहीं दस्तावेज होना चाहिए।

क्या आपकी राय?

julienschmidt 8 दिस॰ 2013

मैं सुनना चाहता हूं कि @gkristic इस बारे में क्या सोचता है। वह इसका अध्ययन कर रहा है।

xaprb 8 दिस॰ 2013

मैंने डेटाबेस / एसक्यूएल में कोड का पालन किया। statement.go:24: Invalid Connection त्रुटियां http://golang.org/issue/5718 का परिणाम नहीं हैं, हालांकि मैं @julienschmidt से सहमत हूं कि पैकेज को फिर से प्रयास करना चाहिए। DB स्तर पर चलने पर Query() और Exec() कॉल के लिए दस प्रयास किए जा सकते हैं, लेकिन जब आप Stmt रिसीवर का उपयोग करते हैं तो कोई नहीं।

"अमान्य कनेक्शन" @xaprb ने देखा कि MySQL कनेक्शन के उपलब्ध नहीं होने के कारण जब Close() को तैयार कथन के लिए कहा जाता है, अर्थात stmt.mc.netConn यहाँ शून्य ErrBadConn वापस लौटते ही बंद हो जाएगा।

लेकिन यह एकमात्र संभावना नहीं है जिसे मैंने देखा है; डेटाबेस / एसक्यूएल (गो 1.2) में कुछ समसामयिक मुद्दे हो सकते हैं जो उस संदेश के साथ भी समाप्त हो सकते हैं। यदि एक ड्राइवर कनेक्शन का उपयोग करते समय (डेटाबेस / एसक्यूएल) स्टेटमेंट बंद हो जाता है, तो ड्राइवर का स्टेटमेंट अगले putConn() noteUnusedDriverStatement() । लेकिन putConn() removeOpenStmt() चलने से पहले चल सकता है ( (*Stmt) finalClose() )। यदि, लंबित onPut कार्यों को कॉल करने के बाद, कनेक्शन को निष्क्रिय कनेक्शन सीमा के कारण बंद कर दिया जाता है, तो पैकेज फिर से कथन को बंद करने का प्रयास करेगा, जिसके परिणामस्वरूप संदेश। यह एक बार फिर हानिरहित है, लेकिन फिर भी कष्टप्रद है।

IMHO गो के डेटाबेस / एसक्यूएल को कुछ सावधान फिर से सोचने की जरूरत है ...

gkristic 10 दिस॰ 2013

@gkristic क्या आप ड्राइवर में कोई बदलाव करने का सुझाव देते हैं?

डेटाबेस / sql पैकेज में कुछ खामियां हैं, मुझे उम्मीद है कि Go 1.3 के लिए कुछ सुधार किए जाएंगे। निर्भरता प्रबंधन पर दोबारा गौर करना मेरी सूची में एक आइटम है।

julienschmidt 11 दिस॰ 2013

यदि आप इस तरह के मुद्दों की खोज करते हैं, तो कृपया इसे https://code.google.com/p/go/issues/list पर रिपोर्ट

julienschmidt 11 दिस॰ 2013

यह देखते हुए कि इन शर्तों (अर्थात्, डेटाबेस / एसक्यूएल द्वारा कनेक्शन खो या डबल-क्लोज़्ड) हानिरहित हैं, मुझे उम्मीद है कि ड्राइवर "अमान्य कनेक्शन" संदेश को प्रिंट करने के बजाय, चुपचाप छोड़ देगा। मेरी राय में, बाद में या तो हो सकता है: डरावना, यदि आप नहीं जानते कि यह हानिरहित है; कष्टप्रद, एक बार जब आप करते हैं; लेकिन संभवतः भ्रामक, अगर वहाँ एक समान संदेश कहीं और (और लाइन नंबर को छोड़कर) छपा है, तो एक वास्तविक चेतावनी को छिपाते हुए आप आसानी से छोड़ सकते हैं। यदि या तो stmt.mc या stmt.mc.netConn कथन Close() फ़ंक्शन पर शून्य हैं, तो मैं आगे लॉगिंग किए बिना वापसी का पक्ष लूंगा। यह भी ध्यान दें कि driver.ErrBadConn वहाँ (जैसा कि 4d3764bbcbc17c31575642626beab1bcdc30c301 पर पेश किया गया है) बिल्कुल कोई प्रभाव नहीं पड़ता है, क्योंकि डेटाबेस / sql कभी भी स्टेटमेंट क्लोज़ के लिए रिटर्न कोड की जाँच नहीं करता है।

एक साइड नोट के रूप में, मैं शायद लकड़हारे को ट्विक करने के लिए एक फ़ंक्शन जोड़ूंगा। वर्तमान में, errLog पैकेज के अंदर आरंभिक है और निजी है। यह मानक त्रुटि के लिए प्रिंट करता है जो उपलब्ध हो सकता है या नहीं; यानी, अन्य कारणों से एक प्रक्रिया डिस्क्रिप्टर को बंद करने का विकल्प चुन सकती है। लेकिन अगर ऐसा नहीं भी होता है, तो उपयोगकर्ता को लॉगिंग के बारे में एक अलग विचार हो सकता है (फाइलों के बारे में, syslog, जो भी हो)। ड्राइवर यह डिफ़ॉल्ट लकड़हारा प्रदान कर सकता है, लेकिन शायद उपयोगकर्ता को दूसरा सेट करने की भी अनुमति दे।

जैसे ही मेरे पास कुछ खाली समय होगा, मैं उस मुद्दे के लिए एक छोटा सा उदाहरण तैयार करूंगा जिसका मैंने पहले उल्लेख किया था और एक रिपोर्ट लिखी थी।

धन्यवाद!

gkristic 11 दिस॰ 2013

लकड़हारे के विषय में https://github.com/go-sql-driver/mysql/pull/182 (एक सप्ताह पहले मास्टर में विलय)?

arnehormann 11 दिस॰ 2013

@arnehormann ओह, यार ... बिल्कुल यही। मैं v1.1 के साथ काम कर रहा हूँ। मैंने पोस्ट करने से पहले मास्टर पर अन्य सामान की जाँच की, लेकिन लॉगिंग की जांच करना भूल गया। क्षमा करें और धन्यवाद!

gkristic 11 दिस॰ 2013

@ विकट समस्या मुस्कराहट :

arnehormann 11 दिस॰ 2013

कोई परिवर्तन जो अगली रिलीज़ से पहले किया जाना चाहिए? पीआरएस का स्वागत है :)

julienschmidt 16 मई 2014

अरे दोस्तों, यहाँ गो-एसक्यूएल-ड्राइवर का नया उपयोगकर्ता। मैं इसी तरह के मुद्दों पर ध्यान नहीं दे रहा हूं, लेकिन सोच रहा था कि क्या कोई मुझे इस बात की पुष्टि करने में मदद कर सकता है? लंबे समय तक चलने वाले क्रोन में जो गोरोइटिन का उपयोग करते हैं, मैं नियमित रूप से निम्नलिखित प्राप्त कर रहा हूं।

[MySQL] 2014/05/14 20:33:05 packets.go:356: Busy buffer
[MySQL] 2014/05/14 20:33:05 packets.go:73: EOF
[MySQL] 2014/05/14 20:33:05 statement.go:24: Invalid Connection
[MySQL] 2014/05/14 20:33:05 connection.go:206: Invalid Connection

मैं यहां अपने हाथों को गंदा करने के लिए तैयार हूं, बस समस्या के बारे में कैसे मार्गदर्शन करना है, इसके बारे में कुछ मार्गदर्शन की तलाश में हूं। क्या यह "अमान्य कनेक्शन" त्रुटि कुछ परिस्थितियों में अनदेखी करने के लिए सुरक्षित है? क्या यह पता चलने पर किसी अन्य कनेक्शन को स्वचालित रूप से हथियाने का एक तरीका है?

rmulley 23 मई 2014

उह, ओह ... अब जब मैं देख रहा हूं, तो मैंने पिछले शुक्रवार से @julienschmidt की टिप्पणी को याद किया। (मैं जूलियन से माफी मांगता हूं।) @rmulley , ऐसा लगता है कि आपने वही समस्या बताई है जो मैं ऊपर इस टिप्पणी को देखें। बयान में "अमान्य कनेक्शन": 24 हानिरहित है। ड्राइवर को एक अलग कनेक्शन चुनकर उपयुक्त काम करना चाहिए। मैं हालांकि "व्यस्त बफर" के बारे में निश्चित नहीं हूं; मुझे याद नहीं है कि देखा है। जब से मैंने इस कोड की जाँच की है, तब तक काफी समय हो चुका है। मैं कुछ समय के लिए इसे फिर से देखने के लिए अलग रखूंगा और देखूंगा कि क्या मैं मदद कर सकता हूं। दुर्भाग्य से, यह अगले सप्ताह के अंत से पहले नहीं हो सकता है। लेकिन मैं तब तक आपके पास वापस आ जाऊंगा।

gkristic 23 मई 2014

@rmulley : मेरे लिए यह इस मुद्दे से असंबंधित लगता है।
यदि आपने go get (जो एक पुराना संस्करण है) द्वारा स्थापित संस्करण का उपयोग करने की स्थिति में इस त्रुटि को वर्तमान git मास्टर संस्करण के साथ पुन: उत्पन्न करने का प्रयास करें।
कृपया एक नया मुद्दा खोलें। इस त्रुटि को ट्रिगर करने वाला एक न्यूनतम कोड नमूना निश्चित रूप से मदद करेगा।

ऐसा लगता है जैसे (b *buffer) takeBuffer nil रिटर्न। ऐसा तभी लगता है जब b.length > 0 । इसका मतलब यह होगा कि किसी कारण से बफर में अपठित डेटा है।
मैंने पहले कभी इस त्रुटि को नहीं देखा है और मैंने केवल अतिरिक्त सुरक्षा के लिए इन अतिरिक्त जांचों को लागू किया है। मैं इस जंगली में इस त्रुटि पर विश्वास नहीं करता।

julienschmidt 23 मई 2014

# 206 के अनुसार यह त्रुटि वास्तव में चली जाती है जब टिप से चला जाता है। क्या वास्तव में ऐसा नहीं है?

carbocation 6 जून 2014

सबसे पहले, देर से प्रतिक्रिया के लिए खेद है कि मैं छुट्टी पर था और फिर अनुवर्ती भूल गया। मैंने सुनिश्चित किया कि मेरे पास MySQL ड्राइवर का नवीनतम संस्करण है और अब गो 1.3 के साथ परीक्षण कर रहा हूं। ऐसा लगता है कि मैं अब त्रुटि संदेश में अधिक विस्तार देख रहा हूं।

[MySQL] 2014/06/23 11:46:04 packets.go:356: Busy buffer
[MySQL] 2014/06/23 11:46:04 packets.go:73: read tcp xxx.xxx.xxx.xx:3306: connection reset by peer

क्या यह मेरे अंत पर एक MySQL मुद्दा है? (मुझे इस समस्या को हल करने के तरीके पर ऑनलाइन उपयोगी कुछ भी नहीं मिला है)
या यह कुछ ऐसा है जिसे मैं जांच सकता हूं और फिर किसी तरह अपने कोड में फिर से जोड़ सकता हूं?

rmulley 23 जून 2014

मैं rmulley वर्णित के रूप में एक ही समस्या का सामना करना पड़ा है। जो अलग था वह यह है कि "व्यस्त बफर" बेहद कम क्वेरी (1 क्वेरी + 2 एक्ज़ेक के रूप में छोटा) में दिखाई दिया।

मुझे लगता है कि समस्या तैयार कथनों से संबंधित है। मैंने पाया कि अगर मैंने लेन-देन में एक बयान तैयार किया है, जैसे

 stmt, err = tx.Prepare("SELECT ...")

इससे पहले कि मैं एक और बयान तैयार करूँ, या मुझे हर बार "व्यस्त बफर" का सामना करना पड़ेगा, मुझे इस stmt को बंद करना होगा। अगर मैं तैयार बयानों का उपयोग नहीं करता, उदाहरण के लिए सीधे tx की तरह कर रहा हूँ

 tx.Query("...")

या

tx.Exec("...")

, यह अच्छा था।

और, अगर मैं एक बयान तैयार करता हूं और फिर अन्य क्वेरी या Exec अन्य सामान निष्पादित करता हूं, तो यह भी ठीक है ... बस पिछले एक को बंद किए बिना एक और बयान तैयार न करें, और यह ठीक दिखता है।

आशा है कि यह वास्तव में जहां समस्या है।

धन्यवाद।

zelda81 18 सित॰ 2014

क्या आप शायद एक छोटा गो कार्यक्रम बना सकते हैं जिसके साथ त्रुटि को पुन: प्रस्तुत किया जा सकता है?
यह निश्चित रूप से चालक में एक बग प्रतीत होता है, लेकिन यहां बताए गए मूल मुद्दे से संबंधित नहीं है।
कृपया एक नया मुद्दा बनाएं।

julienschmidt 25 सित॰ 2014

मुझे लगता है कि यह समस्या है:

package main

import (
    "database/sql"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, _ := sql.Open("mysql", "/")
    defer db.Close()
    tx, err := db.Begin()
    if err != nil {
        panic(err)
    }
    defer tx.Commit()
    stmt1, err := tx.Prepare("SELECT 1")
    if err != nil {
        panic(err)
    }
    rows1, err := stmt1.Query()
    if err != nil {
        panic(err)
    }
    stmt2, err := tx.Prepare("SELECT 2")
    if err != nil {
        // rows1 is not closed -> triggers busy buffer because transaction is on one connection
        // and stmt1, stmt2 use the same one.
        // Move rows1.Close() in front of tx.Prepare and it disappears
        panic(err)
    }
    rows2, err := stmt2.Query()
    if err != nil {
        panic(err)
    }
    rows1.Close()
    rows2.Close()
    stmt1.Close()
    stmt2.Close()
}

arnehormann 26 सित॰ 2014

👍4

मैं बस एक समान व्यस्त बफर मुद्दे में भाग गया और यह पुष्टि कर सकता हूं कि

rmulley 7 अक्तू॰ 2014

👍1

हाय दोस्तों, मुझे नहीं पता कि यह किसी भी तरह से हल किया गया था। मैं इस मुद्दे को "Exec" -> के साथ प्रस्तुत किए गए संक्षिप्त आवेषण में देख रहा हूं

var sql = "टेबल में डालें (f1, f2 ... f25) मान (?,? ...?)?"
_, इरेट: = db.Exec (sql, ...)

लगभग 4000 के बाद, कभी-कभी 5000 आवेषण मुझे "अनपेक्षित ईओएफ" और "व्यस्त बफर" मिलते हैं।
आवेषण तंग हैं (लूप के लिए) लेकिन प्रत्येक के बीच एक आरईएसटी अनुरोध है, इसलिए, इतनी तेजी से आग नहीं; एक ही कनेक्शन संदर्भ। यह Go 1.3 है।

धन्यवाद,
नमक

salmagnone 1 जन॰ 2015

@ सैल - जब आप 1.4 का उपयोग करते हैं तो क्या होता है?

बुध पर, 31 दिसंबर, 2014 को प्रातः 10:11 बजे, Sal A. Magnone सूचनाएं @github.com
लिखा था:

हाय दोस्तों, मुझे नहीं पता कि यह किसी भी तरह से हल किया गया था। मैं यह देख रहा हूं
"आवेषण" -> के साथ प्रदर्शन किए गए छोटे आवेषण में समस्या
var sql = "टेबल में डालें (f1, f2 ... f25) मान (?,? ...?)?"
_, इरेट: = db.Exec (sql, ...)
लगभग 4000 के बाद, कभी-कभी 5000 आवेषण मुझे "अप्रत्याशित EOF" और "व्यस्त" मिलते हैं
बफर "।
आवेषण तंग हैं (लूप के लिए) लेकिन बीच में एक अनुरोध है
प्रत्येक, हां, इतनी तेज आग नहीं; एक ही कनेक्शन संदर्भ। यह Go 1.3 है।
धन्यवाद,
नमक
-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/go-sql-driver/mysql/issues/185#issuecomment -68479413।

carbocation 4 जन॰ 2015

आपके जवाब के लिए धन्यवाद।

१.४ - वही त्रुटि। लगभग 50 मिनट में 4205 आवेषण पर मर गया (प्रत्येक प्रविष्टि के बीच नेट और स्क्रीन i / o है)।

मैंने उस कोड को वैकल्पिक रूप से लेने के लिए वापस ले लिया है जहां पिछली बार इसे छोड़ा था। तो इस एप्लिकेशन के लिए महत्वपूर्ण नहीं है, लेकिन इस परियोजना में अन्य क्षुधा के लिए महत्वपूर्ण हो सकता है अगर यह एक संचयी अनुरोध समस्या है।

-साल

से: कार्बोकेशन [mailto: सूचनाएं@github.com]
प्रेषित: रविवार, ४ जनवरी २०१५ सुबह ९: ५० बजे
To: go-sql-driver / mysql
Cc: सैल ए। मैग्ने
विषय: पुन: [mysql] मारे गए कनेक्शन पर अजीब त्रुटि (# १ :५)

@ सैल - जब आप 1.4 का उपयोग करते हैं तो क्या होता है?

बुध 31 दिसंबर, 2014 पर 10:11 pm पर, साल ए Magnone < [email protected] [email protected] >
लिखा था:

हाय दोस्तों, मुझे नहीं पता कि यह किसी भी तरह से हल किया गया था। मैं यह देख रहा हूं
"आवेषण" -> के साथ प्रदर्शन किए गए छोटे आवेषण में समस्या
var sql = "टेबल में डालें (f1, f2 ... f25) मान (?,? ...?)?"
_, इरेट: = db.Exec (sql, ...)
लगभग 4000 के बाद, कभी-कभी 5000 आवेषण मुझे "अप्रत्याशित EOF" और "व्यस्त" मिलते हैं
बफर "।
आवेषण तंग हैं (लूप के लिए) लेकिन बीच में एक अनुरोध है
प्रत्येक, हां, इतनी तेज आग नहीं; एक ही कनेक्शन संदर्भ। यह Go 1.3 है।
धन्यवाद,
नमक
-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/go-sql-driver/mysql/issues/185#issuecomment -68479413।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub https://github.com/go-sql-driver/mysql/issues/185#issuecomment -68635254 पर https://github.com/notifications/beacon/AA4DdvfCFMdiqPlTZITEs9VrxyyJqqFQks5neUqigaJpZM4BSM1b.gif

salmagnone 5 जन॰ 2015

क्या यह धागा अब कुछ धागों में बदल रहा है? क्या सबसे हाल की टिप्पणियों को एक नए मुद्दे में डाल दिया जाना चाहिए और यह एक बंद हो गया?

xaprb 5 जन॰ 2015

@xaprb मैं सहमत हूं, मुझे लगता है कि अभी कुछ सूत्र चल रहे हैं। हम संभवतः इसे बंद कर सकते हैं और https://github.com/go-sql-driver/mysql/issues/185#issuecomment -68479413 से एक नए अंक में ले सकते हैं।

rmulley 5 जन॰ 2015

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Mysql: मारे गए कनेक्शन पर अजीब त्रुटि

सबसे उपयोगी टिप्पणी

सभी 25 टिप्पणियाँ

संबंधित मुद्दों