हमेशा अप-टू-डेट पढ़ने/लिखने के परीक्षण सर्वर को बनाए रखने के लिए PostgreSQL तार्किक प्रतिकृति का उपयोग करना

इस ब्लॉग प्रविष्टि में हम PostgreSQL में तार्किक प्रतिकृति के बारे में बात करेंगे:इसके उपयोग के मामले, इस तकनीक की स्थिति पर सामान्य जानकारी, और विशेष रूप से प्राथमिक सर्वर के ग्राहक (प्रतिकृति) नोड को क्रम में कैसे सेट करें, इस पर एक विशेष उपयोग का मामला। परीक्षण वातावरण के लिए डेटाबेस सर्वर के रूप में कार्य करने के लिए, और चुनौतियों का सामना करना पड़ा।

परिचय

तार्किक प्रतिकृति, आधिकारिक तौर पर PostgreSQL 10 में पेश की गई, PostgreSQL समुदाय द्वारा पेश की गई नवीनतम प्रतिकृति तकनीक है। तार्किक प्रतिकृति भौतिक प्रतिकृति की विरासत की निरंतरता है जिसके साथ यह बहुत सारे विचार और कोड साझा करता है। तार्किक प्रतिकृति संस्करण या विशिष्ट वास्तुकला से स्वतंत्र तार्किक परिवर्तनों को रिकॉर्ड करने के लिए WAL का उपयोग करके भौतिक प्रतिकृति की तरह काम करती है। मूल पेशकश को तार्किक प्रतिकृति प्रदान करने में सक्षम होने के लिए PostgreSQL समुदाय एक लंबा सफर तय कर चुका है।

प्रतिकृति के प्रकार और PostgreSQL प्रतिकृति का इतिहास

डेटाबेस में प्रतिकृति के प्रकारों को निम्नानुसार वर्गीकृत किया जा सकता है:

भौतिक (AKA बाइनरी) प्रतिकृति
- ऑपरेटिंग सिस्टम स्तर (vSphere प्रतिकृति)
- फ़ाइल सिस्टम स्तर (DRBD)
- डेटाबेस स्तर (वाल आधारित)
तार्किक प्रतिकृति (डेटाबेस स्तर)
- ट्रिगर आधारित (DBMirror, Slony)
- मिडलवेयर (pgpool)
- वाल आधारित (pgological, तार्किक प्रतिकृति)

आज के वाल आधारित तार्किक प्रतिकृति के लिए जो रोडमैप लाया गया वह था:

2001:डीबीमिरर (ट्रिगर आधारित)
2004:Slony1 (ट्रिगर आधारित), pgpool (मिडलवेयर)
2005:PITR (वाल आधारित) PostgreSQL 8.0 में पेश किया गया
2006:PostgreSQL 8.2 में वार्म स्टैंडबाय
2010:भौतिक स्ट्रीमिंग प्रतिकृति, PostgreSQL 9.0 में हॉट स्टैंडबाय
2011:PostgreSQL 9.1 में सिंक्रोनस स्ट्रीमिंग प्रतिकृति
2012:PostgreSQL 9.2 में कैस्केडिंग स्ट्रीमिंग प्रतिकृति
2013:PostgreSQL 9.3 में बैकग्राउंड वर्कर
2014:लॉजिकल डिकोडिंग एपीआई, प्रतिकृति स्लॉट। (फाउंडेशन फॉर लॉजिकल रेप्लिकेशन) PostgreSQL 9.4 में
2015:दूसरा चतुर्थांश pglogic, पूर्वज या तार्किक प्रतिकृति का परिचय देता है
2017:कोर पोस्टग्रेएसक्यूएल 10 में तार्किक प्रतिकृति!

जैसा कि हम देख सकते हैं कि तार्किक प्रतिकृति को एक वास्तविकता बनाने के लिए बहुत सी तकनीकों ने सहयोग किया है:वाल संग्रह, गर्म/गर्म स्टैंडबाय, भौतिक वाल प्रतिकृति, पृष्ठभूमि कार्यकर्ता, तार्किक डिकोडिंग। यह मानते हुए कि पाठक भौतिक प्रतिकृति की अधिकांश धारणाओं से परिचित है, हम तार्किक प्रतिकृति के मूल घटकों के बारे में बात करेंगे।

PostgreSQL तार्किक प्रतिकृति बुनियादी अवधारणाएँ

कुछ शब्दावली:

प्रकाशन: भौतिक प्रतिकृति प्राथमिक सर्वर पर एक विशिष्ट डेटाबेस में परिभाषित तालिकाओं के एक सेट से परिवर्तन का एक सेट। एक प्रकाशन सभी या कुछ को संभाल सकता है:INSERT, DELETE, UPDATE, TRUNCATE।
प्रकाशक नोड: सर्वर जहां प्रकाशन रहता है।
प्रतिकृति पहचान: अद्यतन और DELETEs के लिए ग्राहक पक्ष पर पंक्ति की पहचान करने का एक तरीका।
सदस्यता: एक प्रकाशक नोड और उसमें एक या अधिक प्रकाशनों का कनेक्शन। एक सदस्यता प्रकाशक पर प्रतिकृति के लिए एक समर्पित प्रतिकृति स्लॉट का उपयोग करती है। प्रारंभिक सिंक्रनाइज़ेशन चरण के लिए अतिरिक्त प्रतिकृति स्लॉट का उपयोग किया जा सकता है।
सदस्य नोड: सर्वर जहां सदस्यता रहती है।

तार्किक प्रतिकृति एक प्रकाशित/सदस्यता मॉडल का अनुसरण करती है। एक या अधिक ग्राहक प्रकाशक नोड पर एक या अधिक प्रकाशनों की सदस्यता ले सकते हैं। कैस्केडिंग प्रतिकृति की अनुमति देने के लिए सदस्य पुन:प्रकाशित कर सकते हैं। तालिका की तार्किक प्रतिकृति में दो चरण होते हैं:

प्रकाशक पर तालिका का स्नैपशॉट लेना और ग्राहक को उसकी प्रतिलिपि बनाना
सभी परिवर्तन (स्नैपशॉट के बाद से) एक ही क्रम में लागू करना

तार्किक प्रतिकृति लेन-देन है और गारंटी देता है कि ग्राहक पर लागू होने वाले परिवर्तनों का क्रम प्रकाशक के समान ही रहता है। तार्किक प्रतिकृति भौतिक (बाइनरी) प्रतिकृति की तुलना में बहुत अधिक स्वतंत्रता देती है, इसलिए इसका अधिक तरीकों से उपयोग किया जा सकता है:

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

चेतावनी और प्रतिबंध

तार्किक प्रतिकृति का उपयोग करते समय हमें कुछ बातों का ध्यान रखना चाहिए, उनमें से कुछ कुछ डिज़ाइन निर्णयों को प्रभावित कर सकती हैं लेकिन अन्य महत्वपूर्ण घटनाओं को जन्म दे सकती हैं।

प्रतिबंध

केवल डीएमएल संचालन समर्थित हैं। कोई डीडीएल नहीं। स्कीमा को पहले से परिभाषित करना होगा
अनुक्रम दोहराया नहीं जाता
बड़ी वस्तुओं को दोहराया नहीं जाता है
केवल प्लेन बेस टेबल समर्थित हैं (भौतिक दृश्य, विभाजन रूट टेबल, विदेशी टेबल समर्थित नहीं हैं)

चेतावनी

तार्किक प्रतिकृति का उपयोग करते समय जल्द या बाद में हमें जिस मूल समस्या का सामना करना पड़ेगा, वह है सब्सक्राइबर पर टकराव। सब्सक्राइबर एक सामान्य रीड/राइट सर्वर है जो भौतिक प्रतिकृति सेटअप में प्राथमिक के रूप में कार्य कर सकता है, या यहां तक कि कैस्केडिंग लॉजिकल प्रतिकृति सेटअप में प्रकाशक के रूप में भी कार्य कर सकता है। जब तक सब्स्क्राइब्ड टेबल पर लिखा जाता है तब तक संघर्ष . हो सकता है . एक विरोध तब उत्पन्न होता है जब दोहराया गया डेटा उस तालिका पर एक बाधा का उल्लंघन करता है जिस पर उन्हें लागू किया जाता है। आमतौर पर, इसका कारण बनने वाला ऑपरेशन INSERT, DELETES या UPDATES होता है जिसका कोई प्रभाव नहीं होता है क्योंकि लापता पंक्तियों के कारण कोई विरोध नहीं होगा। जब कोई विरोध उत्पन्न होता है तो प्रतिकृति बंद हो जाती है। तार्किक पृष्ठभूमि कार्यकर्ता को निर्दिष्ट अंतराल (wal_retrieve_retry_interval) में फिर से शुरू किया जाएगा, हालांकि, विरोध का कारण हल होने तक प्रतिकृति फिर से विफल हो जाएगी। यह एक गंभीर स्थिति है जिससे तुरंत निपटा जाना चाहिए। ऐसा न करने पर प्रतिकृति स्लॉट अटक जाएगा अपनी वर्तमान स्थिति में, प्रकाशक नोड WAL को जमा करना शुरू कर देगा और अनिवार्य रूप से प्रकाशक नोड डिस्क स्थान से बाहर चला जाएगा . एक संघर्ष सबसे आम कारण है कि प्रतिकृति क्यों रुक सकती है लेकिन किसी भी अन्य गलत स्थिति का एक ही प्रभाव होगा:उदा। हमने सब्स्क्राइब्ड टेबल पर एक नया NOT NULL कॉलम जोड़ा, लेकिन एक डिफ़ॉल्ट मान को परिभाषित करना भूल गए, या एक प्रकाशित टेबल पर एक कॉलम जोड़ा, लेकिन इसे सब्स्क्राइब्ड टेबल पर परिभाषित करना भूल गए, या इसके प्रकार पर गलती की और दो प्रकार नहीं हैं अनुकूल। वे सभी त्रुटियां प्रतिकृति को रोक देंगी। विरोध को हल करने के दो तरीके हैं:

वास्तविक समस्या का समाधान करें
pg_replication_origin_advance पर कॉल करके असफल लेन-देन को छोड़ें

समाधान बी. जैसा कि यहां दिखाया गया है खतरनाक और मुश्किल हो सकता है क्योंकि यह मूल रूप से एक परीक्षण और त्रुटि प्रक्रिया है, और यदि कोई प्रकाशक पर वर्तमान एलएसएन चुनता है तो वह आसानी से एक टूटी हुई प्रतिकृति प्रणाली के साथ समाप्त हो सकता है क्योंकि समस्याग्रस्त एलएसएन के बीच संचालन हो सकता है और वर्तमान एलएसएन जिसे हम रखना चाहेंगे। तो सबसे अच्छा तरीका यह है कि वास्तव में ग्राहक पक्ष की समस्या का समाधान किया जाए। उदा. यदि कोई UNIQUE KEY उल्लंघन होता है तो हम ग्राहक के डेटा को अपडेट कर सकते हैं या केवल पंक्ति को हटा सकते हैं। उत्पादन परिवेश में, यह सब स्वचालित या कम से कम अर्ध स्वचालित होना चाहिए।

प्रकाशक और ग्राहक नोड सेट करना

व्यवहार में तार्किक प्रतिकृति के सामान्य अवलोकन के लिए कृपया इस ब्लॉग को पढ़ें।

तार्किक प्रतिकृति के लिए प्रासंगिक पैरामीटर हैं:

प्रकाशक पक्ष
- wal_level>="तार्किक"
- max_replication_slots>=#सदस्यता + प्रारंभिक तालिका सिंक्रनाइज़ेशन
- max_wal_senders>=max_replication_slots + other_physical_standbys
सदस्य पक्ष
- max_replication_slots>=#सदस्यता
- max_logical_replication_workers>=#सदस्यता + प्रारंभिक तालिका सिंक्रनाइज़ेशन
- max_worker_processes>=max_logical_replication_workers + 1 + max_parallel_workers

हम उन विशेष विचारों पर ध्यान केंद्रित करेंगे जो हमारे विशेष उद्देश्य से उत्पन्न होते हैं जिन्हें प्राप्त करने के लिए हमें तार्किक प्रतिकृति की आवश्यकता होती है:परीक्षण विभाग द्वारा उपयोग के लिए एक परीक्षण डेटाबेस क्लस्टर बनाएं . प्रकाशन को या तो सभी तालिकाओं या तालिका दर तालिका के लिए परिभाषित किया जा सकता है। मैं तालिका दृष्टिकोण से तालिका का सुझाव देता हूं क्योंकि यह हमें अधिकतम लचीलापन देता है। सामान्य चरणों को संक्षेप में निम्नानुसार किया जा सकता है:

ग्राहक नोड पर एक नया initdb प्रदर्शन करें
प्रकाशक क्लस्टर के स्कीमा को डंप करें और सब्सक्राइबर नोड में कॉपी करें
ग्राहक पर स्कीमा बनाएं
तय करें कि आपको किन तालिकाओं की आवश्यकता है और जिनकी आपको आवश्यकता नहीं है।

उपरोक्त बुलेट के संबंध में, दो कारण हैं कि आपको प्रतिकृति के लिए तालिका की आवश्यकता नहीं हो सकती है या प्रतिकृति के लिए सेटअप की आवश्यकता नहीं हो सकती है:

यह एक डमी तालिका है जिसका कोई महत्व नहीं है (और शायद आपको इसे उत्पादन से भी हटा देना चाहिए)
उत्पादन वातावरण के लिए एक स्थानीय तालिका है, जिसका अर्थ है कि यह सही समझ में आता है कि परीक्षण (ग्राहक) वातावरण में एक ही तालिका का अपना डेटा है

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

रिप्लिका पहचान के लिए कोई स्पष्ट उम्मीदवार के साथ तालिकाएं खोजें

select table_schema||'.'||table_name from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name NOT IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY','UNIQUE')) AND table_schema NOT IN ('information_schema','pg_catalog') ;

बिना प्राथमिक कुंजी वाली टेबल ढूंढें, लेकिन एक अद्वितीय इंडेक्स के साथ

select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'UNIQUE' EXCEPT select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'PRIMARY KEY';

उपरोक्त सूचियों को देखें और तय करें कि प्रत्येक तालिका के साथ क्या करना है

उन तालिकाओं के साथ प्रकाशन बनाएं जिनके लिए PK मौजूद है

select 'CREATE PUBLICATION data_for_testdb_pub FOR TABLE ONLY ' || string_agg(qry.tblname,', ONLY ') FROM (select table_schema||'.'||quote_ident(table_name) as tblname from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY')) AND table_schema NOT IN( 'information_schema','pg_catalog')  ORDER BY 1) as qry;
\gexec

फिर सब्सक्रिप्शन नोड पर सब्सक्रिप्शन बनाएं
```
create subscription data_for_testdb_pub CONNECTION 'dbname=yourdb host=yourdbhost user=repmgr' PUBLICATION data_for_testdb_pub ;
```
उपरोक्त डेटा को भी कॉपी करेगा।
अपनी इच्छित तालिकाएं जोड़ें जिनमें एक अद्वितीय अनुक्रमणिका हो
प्रकाशक और ग्राहक दोनों नोड्स में चलाएँ, उदा.:
```
ALTER TABLE someschema.yourtable REPLICA IDENTITY USING INDEX yourindex_ukey;
```
प्रकाशक पर:
```
ALTER PUBLICATION data_for_testdb_pub ADD TABLE ONLY someschema.yourtable;
```
सब्सक्राइबर पर:
```
ALTER SUBSCRIPTION data_for_testdb_pub REFRESH PUBLICATION WITH ( COPY_DATA );
```
इस बिंदु पर (सिंक्रनाइज़ेशन) आपको हमेशा सब्सक्राइबर नोड पर PostgreSQL लॉग पर नज़र रखनी चाहिए। आप कोई त्रुटि या कुछ भी (समयबाह्य) नहीं चाहते हैं जो तार्किक प्रतिकृति की निरंतरता को प्रतिबंधित करता है। किसी भी त्रुटि का तुरंत समाधान करें , या प्रकाशक WAL फ़ाइलों को pg_wal में जमा करता रहेगा और अंततः स्थान समाप्त हो जाएगा। तो आपको
- सभी त्रुटियाँ या तार्किक कार्यकर्ता के संबंध में कोई संदेश जिसके परिणामस्वरूप बाहर निकलना होता है
- इसका भी ध्यान रखें
  - wal_receiver_timeout
  - wal_sender_timeout

सभी समस्याओं को हल करने के बाद आपको अपने ग्राहक नोड को खुशी से चलाना चाहिए। तो अगला सवाल यह है कि इसे टेस्ट डेटाबेस सर्वर के रूप में कैसे उपयोग किया जाए। आपको उन समस्याओं/मुद्दों से निपटना होगा:

अनामकरण
प्राथमिक कुंजियाँ और अद्वितीय कुंजियाँ जो अनुक्रम उल्लंघनों पर आधारित हैं
अच्छे अभ्यासों का एक सामान्य सेट
निगरानी

अनामकरण

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

अनुक्रम वाली प्राथमिक कुंजियां

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

शुक्रवार दोपहर को आप कुछ तालिका में एक नई पंक्ति डालने वाले ग्राहक डेटाबेस पर कुछ परीक्षण करते हैं। यह एक आईडी के रूप में अनुक्रम द्वारा उत्पन्न अगला मान होगा।
आप सप्ताहांत के लिए घर जाते हैं।
कुछ उत्पादन उपयोगकर्ता प्रकाशक डेटाबेस पर उसी तालिका में एक पंक्ति में प्रवेश करते हैं।
पंक्ति को ग्राहक नोड की प्रतिकृति पहचान के आधार पर दोहराया जाएगा लेकिन पीके उल्लंघन त्रुटि के कारण विफल हो जाएगा। तार्किक पृष्ठभूमि कार्यकर्ता बाहर निकलेगा और पुनः प्रयास करेगा। लेकिन जब तक समस्या बनी रहेगी तब तक असफल होते रहेंगे।
प्रतिकृति अटक जाएगी। प्रतिकृति स्लॉट WAL को जमा करना शुरू कर देगा।
प्रकाशक के पास डिस्क स्थान समाप्त हो गया है।
सप्ताहांत में आपको एक ईमेल मिलता है कि आपके प्राथमिक नोड ने पैनिक किया है!

तो, अनुक्रम समस्या को हल करने के लिए आप निम्न दृष्टिकोण अपना सकते हैं:

select 'SELECT setval(''' || seqrelid::regclass||''','||CASE WHEN seqincrement <0 THEN -214748364 ELSE 214748364 END||');' from pg_sequence where seqtypid=20;
\gexec

उपरोक्त क्या करता है अनुक्रमों को एक बड़े पर्याप्त मूल्य पर सेट करना ताकि वे भविष्य में एक काफी बड़ी विंडो के लिए ओवरलैप न हों, जिससे आपको एक समस्या-मुक्त परीक्षण सर्वर मिल सके।

अच्छे व्यवहारों का एक सेट

आपको वास्तव में अपने प्रोग्रामर को अपने परीक्षणों को लगातार बनाए रखने के लिए कहना चाहिए। इसलिए कोई भी परीक्षण पूरा होने के बाद डेटाबेस को उसी स्थिति में छोड़ देना चाहिए जैसा कि परीक्षण से पहले था। अनुक्रम-आधारित आईडी सम्मिलन के साथ यह कोई समस्या नहीं है, हमने पहले एक समाधान देखा था। लेकिन गैर-अनुक्रम (जैसे यौगिक) UNIQUE कुंजियों के साथ जो एक समस्या हो सकती है। इसलिए सदस्यता तालिका में समान मान वाली कुछ उत्पादन पंक्ति हिट होने से पहले उन परीक्षण डेटा को हटाना सबसे अच्छा है।

यहां हमें स्कीमा परिवर्तनों से निपटने को भी जोड़ना चाहिए। सभी स्कीमा परिवर्तन सब्सक्राइबर पर भी किए जाने चाहिए ताकि दोहराए गए डीएमएल ट्रैफ़िक को भंग न किया जा सके।

आज श्वेतपत्र डाउनलोड करें क्लस्टरकंट्रोल के साथ पोस्टग्रेएसक्यूएल प्रबंधन और स्वचालन इस बारे में जानें कि पोस्टग्रेएसक्यूएल को तैनात करने, मॉनिटर करने, प्रबंधित करने और स्केल करने के लिए आपको क्या जानना चाहिए। श्वेतपत्र डाउनलोड करें

निगरानी

आपको वास्तव में एक अच्छे निगरानी समाधान में निवेश करना चाहिए। आपको इसकी निगरानी करनी चाहिए...

सब्सक्राइबर पर:

ग्राहक के लॉग में सभी संदेश जो तार्किक कार्यकर्ता से बाहर निकलने के लिए प्रासंगिक हैं। एक उपकरण को tail_n_mail के रूप में स्थापित करने से वास्तव में इसमें मदद मिल सकती है। काम करने के लिए जाना जाने वाला कॉन्फ़िगरेशन:
```
INCLUDE: ERROR:  .*publisher.*
INCLUDE: ERROR:  .*exited with exit.*
INCLUDE: LOG:  .*exited with exit.*
INCLUDE: FATAL:  
INCLUDE: PANIC:
```
एक बार जब हमें tail_n_mail से अलर्ट आने की सूचना मिलती है तो हमें तुरंत समस्या का समाधान करना चाहिए।
pg_stat_subscription. पिड शून्य नहीं होना चाहिए। साथ ही अंतराल छोटा होना चाहिए।

प्रकाशक पर:

pg_stat_replication. इसमें उतनी ही पंक्तियाँ होनी चाहिए जितनी उन्हें होनी चाहिए:प्रत्येक कनेक्टेड स्ट्रीमिंग प्रतिकृति स्टैंडबाय के लिए एक (ग्राहक नोड्स और अन्य भौतिक स्टैंडबाय शामिल हैं)।
pg_replication_slots। यह सक्रिय होना चाहिए।

आम तौर पर, आपका आदर्श परीक्षण डेटाबेस सर्वर बिना किसी समस्या के चलने में कुछ समय लगता है, लेकिन एक बार जब आप उन सभी को हल कर लेते हैं, तो आपके प्रोग्रामर इसे रखने के लिए आपको धन्यवाद देंगे!