डेटाबेस के साथ काम करने के संबंध में आवेदन का अप्रत्याशित व्यवहार डीबीए और डेवलपर्स के बीच युद्ध की ओर जाता है: डीबीए चिल्लाता है: "आपका आवेदन डेटाबेस को गिरा देता है", डेवलपर्स - "लेकिन सब कुछ पहले काम किया है!" सबसे बुरी बात यह है कि डीबीए और डेवलपर्स एक-दूसरे की मदद नहीं कर सकते हैं: कुछ को एप्लिकेशन और ड्राइवर की बारीकियों के बारे में नहीं पता है, दूसरों को बुनियादी ढांचे से संबंधित सुविधाओं के बारे में नहीं पता है। ऐसी स्थिति से बचना अच्छा होगा।

आपको समझना होगा, यह अक्सर go-database-sql.org के माध्यम से देखने के लिए पर्याप्त नहीं है। अपने आप को अन्य लोगों के अनुभव के साथ बांटना बेहतर है। इससे भी बेहतर अगर यह रक्त और खोए हुए पैसे द्वारा प्राप्त किया गया अनुभव है।

मेरा नाम रायबिन्कोव आर्टेम है और यह लेख संता हाईलाड 2019 सम्मेलन से मेरी रिपोर्ट की एक मुक्त व्याख्या है।

उपकरण

आप गो- database-sql.org पर किसी भी SQL जैसे डेटाबेस के साथ काम करने के बारे में न्यूनतम आवश्यक जानकारी पा सकते हैं। यदि आपने इसे नहीं पढ़ा है, तो इसे पढ़ें।

sqlx

मेरी राय में, गो की शक्ति सरलता है। और यह व्यक्त किया जाता है, उदाहरण के लिए, इसमें गो टू नंगे एसक्यूएल में प्रश्न लिखने के लिए प्रथागत है (ORM सम्मान में नहीं है)। यह एक फायदा और अतिरिक्त कठिनाइयों का स्रोत है।

इसलिए, मानक database/sql भाषा पैकेज लेते हुए, आप इसके इंटरफेस का विस्तार करना चाहेंगे। एक बार ऐसा होने पर, github.com/jmoiron/sqlx पर एक नज़र डालें। मैं आपको कुछ उदाहरण दिखाता हूं कि यह विस्तार आपके जीवन को कैसे सरल बना सकता है।

स्ट्रक्चर्सस्कैन का उपयोग करने से स्तंभों से संरचना गुणों में डेटा को मैन्युअल रूप से स्थानांतरित करने की आवश्यकता समाप्त हो जाती है।

 type Place struct { Country string City sql.NullString TelephoneCode int `db:"telcode"` } var p Place err = rows.StructScan(&p) 

NamedQuery का उपयोग करने से आप किसी क्वेरी में प्लेसहोल्डर के रूप में संरचना गुणों का उपयोग कर सकते हैं।

 p := Place{Country: "South Africa"} sql := `.. WHERE country=:country` rows, err := db.NamedQuery(sql, p) 

गेट और सेलेक्ट का उपयोग करने से आप डेटाबेस से लाइनें प्राप्त करने वाले छोरों को मैन्युअल रूप से लिखने की आवश्यकता से छुटकारा पा सकते हैं।

 var p Place var pp []Place // Get   p     err = db.Get(&p, ".. LIMIT 1") // Select   pp   . err = db.Select(&pp, ".. WHERE telcode > ?", 50) 

ड्राइवरों

database/sql साथ काम करने के लिए इंटरफेस का एक सेट है, और sqlx उनका विस्तार है। काम करने के लिए इन इंटरफेस के लिए, उन्हें एक कार्यान्वयन की आवश्यकता है। ड्राइवर कार्यान्वयन के लिए जिम्मेदार हैं।

सबसे लोकप्रिय ड्राइवर:

• github.com/lib/pq - pure Go Postgres driver for database/sql. यह ड्राइवर लंबे समय से डिफ़ॉल्ट मानक बना हुआ है। लेकिन आज यह अपनी प्रासंगिकता खो चुका है और लेखक द्वारा विकसित नहीं किया जा रहा है।
• github.com/jackc/pgx - PostgreSQL driver and toolkit for Go. आज इस उपकरण को चुनना बेहतर है।

github.com/jackc/pgx - यह वह ड्राइवर है जिसे आप उपयोग करना चाहते हैं। क्यों?

• सक्रिय रूप से समर्थित और विकसित ।
• यदि database/sql इंटरफेस के बिना उपयोग किया जाता है तो यह अधिक उत्पादक हो सकता है।
• 60 से अधिक प्रकार के PostgreSQL के लिए समर्थन जो SQL मानक के बाहर PostgreSQL लागू करता है।
• ड्राइवर के अंदर क्या हो रहा है, इसे आसानी से लागू करने की क्षमता।
• pgx मानव-पठनीय त्रुटियां हैं , जबकि सिर्फ lib/pq पैनिक अटैक करता है। यदि आप एक आतंक नहीं पकड़ते हैं, तो प्रोग्राम क्रैश हो जाएगा। ( आपको गो में आतंक का उपयोग नहीं करना चाहिए, यह अपवाद के समान नहीं है। )
• pgx साथ, हमारे पास प्रत्येक कनेक्शन को स्वतंत्र रूप से कॉन्फ़िगर करने की क्षमता है।
• PostgreSQL तार्किक प्रतिकृति प्रोटोकॉल के लिए समर्थन है ।

4KB

आमतौर पर, हम डेटाबेस से डेटा प्राप्त करने के लिए इस लूप को लिखते हैं:

 rows, err := s.db.QueryContext(ctx, sql) for rows.Next() { err = rows.Scan(...) } 

ड्राइवर के अंदर, हमें एक 4KB बफर में स्टोर करके डेटा मिलता है। rows.Next() एक नेटवर्क यात्रा को जन्म देती है और बफर को भरती है। यदि बफर पर्याप्त नहीं है, तो हम शेष डेटा के लिए नेटवर्क पर जाते हैं। अधिक नेटवर्क का दौरा - कम प्रसंस्करण गति। दूसरी ओर, चूंकि बफर सीमा 4KB है, चलो पूरी प्रक्रिया मेमोरी को नहीं भूलना चाहिए।

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

 $ go test -v -run=XXX -bench=. -benchmem goos: linux goarch: amd64 pkg: github.com/furdarius/pgxexperiments/bufsize BenchmarkBufferSize/4KB 5 315763978 ns/op 53112832 B/op 12967 allocs/op BenchmarkBufferSize/8KB 5 300140961 ns/op 53082521 B/op 6479 allocs/op BenchmarkBufferSize/16KB 5 298477972 ns/op 52910489 B/op 3229 allocs/op BenchmarkBufferSize/1MB 5 299602670 ns/op 52848230 B/op 50 allocs/op PASS ok github.com/furdarius/pgxexperiments/bufsize 10.964s 

यह देखा जा सकता है कि प्रसंस्करण की गति में कोई बड़ा अंतर नहीं है। ऐसा क्यों?

यह पता चला है कि हम पोस्टग्रेज के अंदर डेटा भेजने के लिए बफर के आकार तक सीमित हैं। इस बफ़र का आकार 8KB है । strace का उपयोग करते हुए strace आप देख सकते हैं कि ओएस रीड सिस्टम कॉल में 8192 बाइट देता है। और tcpdump पैकेट के आकार के साथ इसकी पुष्टि करता है।

टॉम लेन ( पोस्टग्रेज कर्नेल के मुख्य डेवलपर्स में से एक ) इस तरह से टिप्पणी करता है :

परंपरागत रूप से, कम से कम, यह यूनिक्स मशीनों में पाइप बफ़र्स के आकार का था, इसलिए सिद्धांत रूप में यह यूनिक्स सॉकेट में डेटा भेजने के लिए सबसे इष्टतम चंक आकार है।

एंड्रेस फ्रुंड ( एंटरप्राइजडीबी से पोस्टग्रेजुएट डेवलपर ) का मानना ​​है कि 8KB बफर आज तक का सबसे अच्छा कार्यान्वयन विकल्प नहीं है, और आपको विभिन्न आकारों पर और एक अलग सॉकेट कॉन्फ़िगरेशन के साथ व्यवहार का परीक्षण करने की आवश्यकता है।

हमें यह भी याद रखना चाहिए कि PgBouncer में एक बफर भी है और इसका आकार pkt_buf पैरामीटर के साथ कॉन्फ़िगर किया जा सकता है।

OIDs

Pgx ( v3 ) ड्राइवर की एक और विशेषता: प्रत्येक कनेक्शन के लिए, यह ऑब्जेक्ट आईडी ( OID ) के बारे में जानकारी प्राप्त करने के लिए डेटाबेस से अनुरोध करता है।

इन पहचानकर्ताओं को आंतरिक वस्तुओं को विशिष्ट रूप से पहचानने के लिए पोस्टग्रेज में जोड़ा गया: पंक्तियाँ, टेबल, फ़ंक्शंस इत्यादि।

ड्राइवर डेटा को जोड़ने के लिए किस डेटाबेस कॉलम में भाषा को समझने के लिए OIDs ज्ञान का उपयोग करता है। इसके लिए, pgx ऐसी तालिका का समर्थन करता है ( कुंजी प्रकार नाम है, मान ऑब्जेक्ट आईडी है )

 map[string]Value{ "_aclitem": 2, "_bool": 3, "_int4": 4, "_int8": 55, ... } 

यह कार्यान्वयन इस तथ्य की ओर जाता है कि डेटाबेस के साथ प्रत्येक स्थापित कनेक्शन के लिए ड्राइवर Object ID साथ तालिका बनाने के लिए लगभग तीन अनुरोध करता है। डेटाबेस और एप्लिकेशन के संचालन के सामान्य मोड में, गो में कनेक्शन पूल आपको डेटाबेस में नए कनेक्शन उत्पन्न नहीं करने देता है। लेकिन डेटाबेस की थोड़ी गिरावट पर, आवेदन पक्ष पर कनेक्शन का पूल समाप्त हो जाता है और प्रति यूनिट समय पर उत्पन्न कनेक्शन की संख्या में काफी वृद्धि होती है। OIDs लिए अनुरोध काफी भारी हैं, परिणामस्वरूप, चालक डेटाबेस को एक महत्वपूर्ण स्थिति में ला सकता है।

यहां वह क्षण है जब इस तरह के अनुरोध हमारे डेटाबेस में से एक पर डाले गए थे:

सामान्य मोड में प्रति मिनट 15 लेनदेन , गिरावट के दौरान 6500 तक का लेनदेन ।

क्या करें?

सबसे पहले और सबसे ऊपर, अपने पूल के आकार को ऊपर से सीमित करें।

database/sql यह DB.SetMaxOpenConns फ़ंक्शन के साथ किया जा सकता है। यदि आप database/sql इंटरफेस को छोड़ देते हैं और pgx.ConnPool ( ड्राइवर द्वारा लागू किया गया कनेक्शन पूल ) का उपयोग करते हैं, तो आप MaxConnections निर्दिष्ट कर सकते हैं ( डिफ़ॉल्ट 5 है )।

वैसे, pgx.ConnPool का उपयोग करते pgx.ConnPool चालक प्राप्त pgx.ConnPool बारे में जानकारी का पुन: उपयोग करेगा और हर नए कनेक्शन के लिए डेटाबेस से प्रश्न नहीं करेगा।

यदि आप database/sql को मना नहीं करना चाहते हैं, तो आप स्वयं OIDs बारे में जानकारी कैश कर सकते हैं।

 github.com/jackc/pgx/stdlib.OpenDB(pgx.ConnConfig{ CustomConnInfo: func(c *pgx.Conn) (*pgtype.ConnInfo, error) { cachedOids = //  OIDs   . info := pgtype.NewConnInfo() info.InitializeDataTypes(cachedOids) return info, nil } }) 

यह एक काम करने का तरीका है, लेकिन इसका इस्तेमाल करना दो परिस्थितियों में खतरनाक हो सकता है:

• आप Postgres में Enum या डोमेन प्रकार का उपयोग करते हैं;
• यदि विज़ार्ड विफल हो जाता है, तो आप एप्लिकेशन को प्रतिकृति पर स्विच करते हैं, जिसे तार्किक प्रतिकृति द्वारा डाला जाता है।

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

Postgres दुनिया में, भौतिक प्रतिकृति का उपयोग आमतौर पर उच्च उपलब्धता को व्यवस्थित करने के लिए किया जाता है, जो डेटाबेस के उदाहरणों को थोड़ा-थोड़ा करके कॉपी करता है, इसलिए OIDs कैशिंग के साथ समस्याएं शायद ही कभी जंगली में देखी जाती हैं। ( लेकिन आपके DBA के साथ यह जांचना बेहतर है कि आपके लिए कितना स्टैंडबाय काम करता है )।

pgx ड्राइवर के अगले प्रमुख संस्करण - v4 , pgx लिए कोई अभियान नहीं होगा । अब ड्राइवर केवल OIDs की सूची पर भरोसा करेगा जो कोड में OIDs हैं। कस्टम प्रकारों के लिए, आपको अपने एप्लिकेशन पक्ष पर डीसेरलाइज़ेशन को नियंत्रित करने की आवश्यकता होगी: ड्राइवर बस बाइट्स की एक सरणी के रूप में स्मृति का एक टुकड़ा छोड़ देगा।

लॉगिंग और मॉनिटरिंग

आधार क्रैश होने से पहले निगरानी और लॉगिंग से समस्याओं को नोटिस करने में मदद मिलेगी।

database/sql DB.Stats () विधि प्रदान करता है। लौटा हुआ स्टेटस स्नैपशॉट आपको ड्राइवर के अंदर क्या चल रहा है, इसका अंदाजा लगाएगा।

 type DBStats struct { MaxOpenConnections int // Pool State OpenConnections int InUse int Idle int // Counters WaitCount int64 WaitDuration time.Duration MaxIdleClosed int64 MaxLifetimeClosed int64 } 

यदि आप सीधे pgx में पूल का उपयोग करते हैं, तो ConnPool.Stat () विधि आपको इसी तरह की जानकारी देगी:

 type ConnPoolStat struct { MaxConnections int CurrentConnections int AvailableConnections int } 

लॉगिंग समान रूप से महत्वपूर्ण है, और pgx आपको ऐसा करने की अनुमति देता है। ड्राइवर Logger इंटरफ़ेस को स्वीकार करता है, जिसे लागू करने से, आपको ड्राइवर के अंदर होने वाली सभी घटनाएं मिलती हैं।

 type Logger interface { // Log a message at the given level with data key/value pairs. // data may be nil. Log(level LogLevel, msg string, data map[string]interface{}) } 

सबसे अधिक संभावना है, आपको इस इंटरफ़ेस को स्वयं लागू करने की आवश्यकता नहीं है। बॉक्स के बाहर pgx में सबसे लोकप्रिय लॉगर के लिए एडेप्टर का एक सेट है , उदाहरण के लिए, uber-go / zap , sirupsen / logrus , rs / zerolog ।

आधारभूत संरचना

लगभग हमेशा Postgres साथ काम करते समय आप कनेक्शन पूलर का उपयोग करेंगे, और यह PgBouncer ( या ओडिसी - यदि आप यांडेक्स हैं )।

ऐसा क्यों, आप उत्कृष्ट लेख brandur.org/postgres-connections में पढ़ सकते हैं। संक्षेप में, जब ग्राहकों की संख्या 100 से अधिक हो जाती है, तो प्रसंस्करण अनुरोधों की गति कम होने लगती है। यह स्वयं पोस्टग्रेज के कार्यान्वयन की सुविधाओं के कारण होता है: प्रत्येक कनेक्शन के लिए एक अलग प्रक्रिया का शुभारंभ, स्नैपशॉट को हटाने के लिए तंत्र और बातचीत के लिए साझा मेमोरी का उपयोग - यह सब प्रभावित करता है।

यहाँ विभिन्न कनेक्शन पूलर कार्यान्वयन का बेंचमार्क है :

और PgBouncer के साथ और बिना बेंचमार्क बैंडविड्थ।

नतीजतन, आपका बुनियादी ढांचा इस तरह दिखेगा:

जहां Server वह प्रक्रिया है जो उपयोगकर्ता के अनुरोध को संसाधित करता है। यह प्रक्रिया 3 प्रतियों ( कम से कम ) में kubernetes में घूमती है। अलग से, एक लोहे के सर्वर पर, Postgres , जिसे PgBouncer' द्वारा कवर किया गया है। PgBouncer स्वयं सिंगल-थ्रेडेड है, इसलिए हम कई बाउंसर लॉन्च करते हैं, जिसके लिए हम HAProxy का उपयोग करके ट्रैफ़िक को संतुलित करते हैं। परिणामस्वरूप, हमें डेटाबेस में क्वेरी निष्पादन की ऐसी श्रृंखला मिलती है: → HAProxy → PgBouncer → Postgres ।

PgBouncer तीन मोड में काम कर सकता है:

• सत्र पूलिंग - प्रत्येक सत्र के लिए, एक कनेक्शन जारी किया जाता है और इसे पूरे जीवन समय के लिए सौंपा जाता है।
• लेन- देन चल रहा है - लेन-देन पूलिंग - कनेक्शन रहता है। जैसे ही लेन-देन पूरा हो जाता है, PgBouncer इस कनेक्शन को लेता है और इसे दूसरे लेनदेन को वापस देता है। यह मोड यौगिकों के बहुत अच्छे निपटान की अनुमति देता है।
• स्टेटमेंट पूलिंग - पदावनत मोड। यह केवल पीएल / प्रॉक्सी का समर्थन करने के लिए बनाया गया था।

आप देख सकते हैं कि प्रत्येक मोड में क्या गुण उपलब्ध हैं। हम Transaction Pooling चुनते हैं, लेकिन इसमें Prepared Statements साथ काम करने की सीमाएँ हैं।

लेन-देन पूलिंग + तैयार कथन

आइए कल्पना करें कि हम एक अनुरोध तैयार करना चाहते हैं और फिर उसे निष्पादित करते हैं। कुछ बिंदु पर, हम एक लेनदेन शुरू करते हैं जिसमें हम एक तैयार अनुरोध भेजते हैं, और हमें डेटाबेस से तैयार अनुरोध की आईडी मिलती है।

बाद में, किसी अन्य समय में, हम एक और लेनदेन उत्पन्न करते हैं। इसमें, हम डेटाबेस की ओर मुड़ते हैं और निर्दिष्ट मापदंडों के साथ पहचानकर्ता का उपयोग करके अनुरोध को पूरा करना चाहते हैं।

लेन-देन पूलिंग मोड में, दो लेन-देन अलग-अलग कनेक्शनों में निष्पादित किए जा सकते हैं, लेकिन स्टेटमेंट आईडी केवल एक कनेक्शन के भीतर मान्य है। किसी अनुरोध को निष्पादित करने का प्रयास करते समय हमें एक prepared statement does not exist ।

सबसे अप्रिय: चूंकि विकास और परीक्षण के दौरान लोड छोटा है, PgBouncer अक्सर एक ही कनेक्शन जारी करता है और सब कुछ सही ढंग से काम करता है। लेकिन जैसे ही हम ठेस पहुंचते हैं, अनुरोध एक त्रुटि के साथ शुरू होते हैं।

अब इस कोड में Prepared Statements खोजें:

 sql := `select * from places where city = ?` rows, err := s.db.Query(sql, city) 

आप उसे नहीं देखेंगे! क्वेरी तैयारी अव्यवस्थित रूप से Query() अंदर होगी। उसी समय, अनुरोध की तैयारी और निष्पादन विभिन्न लेनदेन में होगा और हम पूरी तरह से उन सभी को प्राप्त करेंगे जो मैंने ऊपर वर्णित किया था।

क्या करें?

पहला, सबसे आसान विकल्प Session pooling लिए PgBouncer स्विच PgBouncer है । एक कनेक्शन सत्र के लिए आवंटित किया जाता है, सभी लेनदेन इस संबंध में जाने लगते हैं और तैयार अनुरोध सही तरीके से काम करते हैं। लेकिन इस मोड में, यौगिकों के उपयोग की दक्षता वांछित होने के लिए बहुत कुछ छोड़ देती है। इसलिए, इस विकल्प पर विचार नहीं किया जाता है।

दूसरा विकल्प क्लाइंट पक्ष पर एक अनुरोध तैयार करना है । मैं दो कारणों से ऐसा नहीं करना चाहता:

• संभावित SQL कमजोरियाँ। डेवलपर भूल सकता है या गलत तरीके से बच सकता है।
• हर बार आपको अपने हाथों से लिखने के लिए क्वेरी मापदंडों से बचना होगा।

एक अन्य विकल्प लेन-देन में प्रत्येक अनुरोध को स्पष्ट रूप से लपेटना है । आखिरकार, जब तक लेन-देन रहता है, PgBouncer कनेक्शन नहीं PgBouncer है। यह काम करता है, लेकिन, हमारे कोड में वर्बोसिटी के अलावा, हमें अधिक नेटवर्क कॉल भी मिलते हैं: आरंभ, तैयार, निष्पादित, प्रतिबद्ध। प्रति अनुरोध कुल 4 नेटवर्क कॉल। विलंबता बढ़ रही है।

लेकिन मैं इसे सुरक्षित और सुविधाजनक और कुशलता से चाहता हूं। और ऐसा एक विकल्प है! आप ड्राइवर को स्पष्ट रूप से बता सकते हैं कि आप सरल क्वेरी मोड का उपयोग करना चाहते हैं। इस मोड में, कोई तैयारी नहीं होगी और पूरा अनुरोध एक नेटवर्क कॉल में पास होगा। इस स्थिति में, चालक प्रत्येक पैरामीटर को स्वयं बना देगा ( standard_conforming_strings को बेस स्तर पर या कनेक्शन स्थापित करते समय सक्रिय किया जाना चाहिए )।

 cfg := pgx.ConnConfig{ ... RuntimeParams: map[string]string{ "standard_conforming_strings": "on", }, PreferSimpleProtocol: true, } 

अनुरोध रद्द करें

निम्नलिखित मुद्दे आवेदन पक्ष में अनुरोधों को रद्द करने से संबंधित हैं।

इस कोड पर एक नज़र डालें। नुकसान कहाँ हैं?

 rows, err := s.db.QueryContext(ctx, ...) 

जाओ कार्यक्रम निष्पादन के प्रवाह को नियंत्रित करने के लिए एक विधि है - संदर्भ । संदर्भ । इस कोड में, हम ड्राइवर ctx पास करते हैं ताकि जब संदर्भ बंद हो जाए, तो ड्राइवर डेटाबेस स्तर पर अनुरोध को रद्द कर दे।

इसी समय, यह उम्मीद की जाती है कि हम उन अनुरोधों को रद्द करके संसाधनों को बचाएंगे जिनके लिए कोई इंतजार नहीं कर रहा है। लेकिन एक अनुरोध को रद्द करते समय, PgBouncer संस्करण 1.7 कनेक्शन को सूचना भेजता है कि यह कनेक्शन उपयोग के लिए तैयार है, और उसके बाद इसे पूल में लौटाता है। PgBouncer' का यह व्यवहार ड्राइवर को गुमराह कर रहा है, जो अगला अनुरोध भेजने पर तुरंत प्रतिक्रिया में ReadyForQuery प्राप्त करता है। अंत में, हम अप्रत्याशित ReadyForQuery त्रुटियों को पकड़ते हैं ।

PgBouncer संस्करण 1.8 से शुरू करते PgBouncer , यह व्यवहार तय किया गया है । PgBouncer के वर्तमान संस्करण का उपयोग करें।

और, हालांकि, इस मामले में, त्रुटियां गायब हो जाएंगी - दिलचस्प व्यवहार बना रहेगा। कुछ मामलों में, हमारे आवेदन को इसके अनुरोध का जवाब नहीं मिल सकता है, लेकिन पड़ोसी को (मुख्य बात यह है कि अनुरोध अनुरोध किए गए डेटा के प्रकार और आदेश से मेल खाते हैं)। उदाहरण के लिए, उस क्वेरी के लिए where user_id = 2 , उस क्वेरी की प्रतिक्रिया where user_id = 42 वापस आएगी। यह विभिन्न स्तरों पर अनुरोधों को रद्द करने की प्रक्रिया के कारण है: ड्राइवर पूल और बाउंसर पूल के स्तर पर।

विलंबित रद्दीकरण

अनुरोध को रद्द करने के लिए, हमें डेटाबेस के लिए एक नया कनेक्शन बनाने और रद्द करने का अनुरोध करने की आवश्यकता है। Postgres प्रत्येक कनेक्शन के लिए एक अलग प्रक्रिया बनाता है। हम एक विशिष्ट प्रक्रिया में वर्तमान अनुरोध को रद्द करने के लिए एक आदेश भेजते हैं। ऐसा करने के लिए, एक नया कनेक्शन बनाएं और इसमें ब्याज की प्रक्रिया आईडी (पीआईडी) हमें स्थानांतरित करें। लेकिन जब रद्द आदेश आधार के लिए उड़ान भरता है, तो रद्द अनुरोध अपने आप समाप्त हो सकता है।

Postgres कमांड निष्पादित करेंगे और दी गई प्रक्रिया में वर्तमान अनुरोध को रद्द कर देंगे। लेकिन वर्तमान अनुरोध वह नहीं होगा जिसे हम शुरू में रद्द करना चाहते थे। इस व्यवहार के कारण जब Postgres साथ PgBouncer साथ काम करते हैं PgBouncer ड्राइवर स्तर पर अनुरोध को रद्द नहीं करना सुरक्षित है। ऐसा करने के लिए, आप CustomCancel सेट कर सकते हैं, जो context.Context रद्द नहीं करेगा, भले ही context.Context ।

 cfg := pgx.ConnConfig{ ... CustomCancel: func(_ *pgx.Conn) error { return nil }, } 

चेकलिस्ट पोस्ट करता है

निष्कर्ष के बजाय, मैंने पोस्टग्रेज के साथ काम करने के लिए एक चेकलिस्ट बनाने का फैसला किया। इससे लेख को मेरे सिर में फिट होने में मदद मिलेगी।

• Postgres के साथ काम करने के लिए ड्राइवर के रूप में github.com/jackc/pgx का उपयोग करें।
• ऊपर से कनेक्शन पूल का आकार सीमित करें।
• यदि आप pgx संस्करण 3 के साथ काम कर रहे हैं तो CID OIDs या pgx.ConnPool का उपयोग करें।
• DB.Stats () या ConnPool.Stat () का उपयोग करके कनेक्शन पूल से मैट्रिक्स एकत्र करें।
• लॉग इन करें कि ड्राइवर में क्या हो रहा है।
• PgBouncer लेन-देन मोड में क्वेरी तैयारी के साथ समस्याओं से बचने के लिए सरल क्वेरी मोड का उपयोग करें।
• PgBouncer को नवीनतम संस्करण में अपडेट करें।
• आवेदन से अनुरोधों को रद्द करने से सावधान रहें।