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

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

लॉग स्तर

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

मिनिमल

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

आइए देखते हैं। सबसे पहले, आवश्यक स्तर निर्धारित करें (इसके लिए आपको एक और पैरामीटर बदलने की आवश्यकता होगी - max_wal_senders )।

=> ALTER SYSTEM SET wal_level = minimal; => ALTER SYSTEM SET max_wal_senders = 0;

 student$ sudo pg_ctlcluster 11 main restart

ध्यान दें कि स्तर को बदलने के लिए सर्वर पुनरारंभ की आवश्यकता होती है।

लॉग में वर्तमान स्थिति याद रखें:

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/353927BC (1 row)

अब टेबल बनाते हैं (क्रिएट टेबल एएस सेलेक्ट) और लॉग में स्थिति फिर से लिखें। सेलेक्ट स्टेटमेंट द्वारा चुने गए डेटा की मात्रा इस मामले में मायने नहीं रखती है, इसलिए हम खुद को एक सीमा तक सीमित कर लेंगे।

 => CREATE TABLE wallevel AS SELECT 1 AS n; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/353A7DFC (1 row)

परिचित pg_waldump उपयोगिता के साथ, आइए लॉग प्रविष्टियों को देखें।

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/353927BC -e 0/353A7DFC

कुछ विवरण, निश्चित रूप से लॉन्च से लॉन्च तक भिन्न हो सकते हैं, लेकिन इस मामले में, ऐसा ही हुआ। Heap2 प्रबंधक प्रविष्टि सफाई को संदर्भित करती है, यहाँ यह सिस्टम कैटलॉग में तालिकाओं में से एक की सफाई पर पृष्ठ की सफाई है (सिस्टम ऑब्जेक्ट आसानी से "शॉर्ट" संख्या द्वारा रिले में नग्न आंखों के साथ प्रतिष्ठित हैं):

 rmgr: Heap2 len (rec/tot): 59/ 7587, tx: 0, lsn: 0/353927BC, prev 0/35392788, desc: CLEAN remxid 101126, blkref #0: rel 1663/16386/1247 blk 8 FPW

फिर उस तालिका के लिए अगला OID प्राप्त करने के बारे में एक रिकॉर्ड है जिसे हम बनाने जा रहे हैं:

 rmgr: XLOG len (rec/tot): 30/ 30, tx: 0, lsn: 0/35394574, prev 0/353927BC, desc: NEXTOID 82295

अब तालिका का वास्तविक निर्माण:

 rmgr: Storage len (rec/tot): 42/ 42, tx: 0, lsn: 0/35394594, prev 0/35394574, desc: CREATE base/16386/74103

हालाँकि, किसी तालिका में डेटा सम्मिलित नहीं किया गया है। फिर अलग-अलग टेबल और इंडेक्स में पंक्तियाँ डालने के बारे में कई प्रविष्टियाँ हैं - यह PostgreSQL सिस्टम निर्देशिका में बनाई गई तालिका को पंजीकृत करता है (मैं इसे संक्षिप्त रूप में देता हूं):

 rmgr: Heap len (rec/tot): 203/ 203, tx: 101127, lsn: 0/353945C0, prev 0/35394594, desc: INSERT off 71, blkref #0: rel 1663/16386/1247 blk 8 rmgr: Btree len (rec/tot): 53/ 685, tx: 101127, lsn: 0/3539468C, prev 0/353945C0, desc: INSERT_LEAF off 37, blkref #0: rel 1663/16386/2703 blk 2 FPW ... rmgr: Btree len (rec/tot): 53/ 2393, tx: 101127, lsn: 0/353A747C, prev 0/353A6788, desc: INSERT_LEAF off 10, blkref #0: rel 1664/0/1233 blk 1 FPW

और अंत में, लेनदेन निर्धारण:

 rmgr: Transaction len (rec/tot): 34/ 34, tx: 101127, lsn: 0/353A7DD8, prev 0/353A747C, desc: COMMIT 2019-07-23 18:59:34.923124 MSK

प्रतिकृति

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

प्रतिकृति के लिए भी यही सच है - जो कुछ भी लॉग नहीं किया गया है उसे प्रतिकृति में स्थानांतरित नहीं किया जाएगा और पुन: प्रस्तुत नहीं किया जाएगा। लेकिन, अगर हम किसी प्रतिकृति पर अनुरोधों को निष्पादित करना चाहते हैं, तो यह अभी भी जटिल है।

सबसे पहले, हमें प्राथमिक सर्वर पर होने वाले अनन्य ताले के बारे में जानकारी चाहिए, क्योंकि वे प्रतिकृति पर अनुरोधों के साथ संघर्ष कर सकते हैं। ऐसे ताले लॉग और प्रतिकृति (स्टार्टअप प्रक्रिया की ओर से) पर लागू होते हैं।

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

लॉग स्तर, जो बैकअप से पुनर्प्राप्त करने की क्षमता और भौतिक प्रतिकृति की संभावना दोनों की गारंटी देता है, मान wal_level = प्रतिकृति द्वारा निर्धारित किया जाता है। (संस्करण 9.6 से पहले, दो अलग-अलग स्तर के संग्रह और hot_standby थे, लेकिन फिर उन्हें एक आम में जोड़ दिया गया)।

PostgreSQL 10 के साथ शुरू करना, यह यह स्तर है जो डिफ़ॉल्ट रूप से सेट किया गया है (और इससे पहले यह न्यूनतम था)। इसलिए, डिफ़ॉल्ट मानों के लिए पैरामीटर को रीसेट करें:

 => ALTER SYSTEM RESET wal_level; => ALTER SYSTEM RESET max_wal_senders;

 student$ sudo pg_ctlcluster 11 main restart

हम तालिका को हटाते हैं और पिछली बार की कार्रवाई के समान क्रम को दोहराते हैं:

 => DROP TABLE wallevel; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/353AF21C (1 row)

 => CREATE TABLE wallevel AS SELECT 1 AS n; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/353BE51C (1 row)

अब जर्नल प्रविष्टियों की जांच करें।

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/353AF21C -e 0/353BE51C

सफाई करना, ओआईडी प्राप्त करना, एक टेबल बनाना और सिस्टम डायरेक्टरी में पंजीकरण करना - अभी के लिए, सब कुछ वैसा ही है:

 rmgr: Heap2 len (rec/tot): 58/ 58, tx: 0, lsn: 0/353AF21C, prev 0/353AF044, desc: CLEAN remxid 101128, blkref #0: rel 1663/16386/1247 blk 8 rmgr: XLOG len (rec/tot): 30/ 30, tx: 0, lsn: 0/353AF258, prev 0/353AF21C, desc: NEXTOID 82298 rmgr: Storage len (rec/tot): 42/ 42, tx: 0, lsn: 0/353AF278, prev 0/353AF258, desc: CREATE base/16386/74106 rmgr: Heap len (rec/tot): 203/ 203, tx: 101129, lsn: 0/353AF2A4, prev 0/353AF278, desc: INSERT off 73, blkref #0: rel 1663/16386/1247 blk 8 rmgr: Btree len (rec/tot): 53/ 717, tx: 101129, lsn: 0/353AF370, prev 0/353AF2A4, … rmgr: Btree len (rec/tot): 53/ 2413, tx: 101129, lsn: 0/353BD954, prev 0/353BCC44, desc: INSERT_LEAF off 10, blkref #0: rel 1664/0/1233 blk 1 FPW

लेकिन कुछ नया। स्टैंडबाय प्रबंधक से संबंधित एक अनन्य लॉक का रिकॉर्ड - इस मामले में, यह लेनदेन संख्या को अवरुद्ध कर रहा है (इसकी आवश्यकता क्यों है, हम लेखों की अगली श्रृंखला में विस्तार से बात करेंगे):

 rmgr: Standby len (rec/tot): 42/ 42, tx: 101129, lsn: 0/353BE2D8, prev 0/353BD954, desc: LOCK xid 101129 db 16386 rel 74106

और यह हमारी तालिका में पंक्तियाँ डालने के बारे में एक रिकॉर्ड है (क्रिएट रिकॉर्ड में ऊपर बताए गए फ़ाइल के साथ संबंधित फ़ाइल संख्या की तुलना करें):

 rmgr: Heap len (rec/tot): 59/ 59, tx: 101129, lsn: 0/353BE304, prev 0/353BE2D8, desc: INSERT+INIT off 1, blkref #0: rel 1663/16386/74106 blk 0

प्रतिबद्ध रिकॉर्ड:

 rmgr: Transaction len (rec/tot): 421/ 421, tx: 101129, lsn: 0/353BE340, prev 0/353BE304, desc: COMMIT 2019-07-23 18:59:37.870333 MSK; inval msgs: catcache 74 catcache 73 catcache 74 catcache 73 catcache 50 catcache 49 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 relcache 74106 snapshot 1214

और एक अन्य रिकॉर्ड, जो समय-समय पर होता है और पूर्ण लेनदेन से जुड़ा नहीं होता है, स्टैंडबाय प्रबंधक को संदर्भित करता है और वर्तमान में चल रहे लेनदेन पर रिपोर्ट करता है:

 rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/353BE4E8, prev 0/353BE340, desc: RUNNING_XACTS nextXid 101130 latestCompletedXid 101129 oldestRunningXid 101130

तार्किक

अंत में, अंतिम स्तर पैरामीटर wal_level = तार्किक के मान से निर्धारित होता है और तार्किक डिकोडिंग और तार्किक प्रतिकृति की संभावना प्रदान करता है। यह प्रकाशन सर्वर पर सक्षम होना चाहिए।

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

अब हम बैकअप और प्रतिकृति के संचालन के विवरण में नहीं जाएंगे - लेखों की एक अलग श्रृंखला के लिए यह एक बड़ा विषय है।

रिकॉर्ड विश्वसनीयता

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

कैशिंग

गैर-वाष्पशील भंडारण (जैसे हार्ड डिस्क ड्राइव) के डेटा पथ पर कई कैश हैं।

जब कोई प्रोग्राम (कोई भी, लेकिन हमारे मामले में PostgreSQL) ऑपरेटिंग सिस्टम को डिस्क पर कुछ लिखने के लिए कहता है, तो ऑपरेटिंग सिस्टम रैम में डेटा को उसके कैश में स्थानांतरित करता है। वास्तविक रिकॉर्डिंग ऑपरेटिंग सिस्टम के I / O अनुसूचक की सेटिंग्स के आधार पर, अतुल्यकालिक रूप से होती है।

जब ओएस डेटा लिखने का फैसला करता है, तो वे ड्राइव (हार्ड डिस्क) के कैश में गिर जाते हैं। ड्राइव इलेक्ट्रॉनिक्स भी रिकॉर्डिंग में देरी कर सकते हैं, उदाहरण के लिए, उन समूहों में डेटा एकत्र करना जो एक ही समय में रिकॉर्ड करने के लिए अधिक लाभदायक हैं। और अगर एक RAID नियंत्रक का उपयोग किया जाता है, तो ओएस और ड्राइव के बीच कैशिंग का एक और स्तर दिखाई देता है।

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

ऑपरेटिंग सिस्टम ऐसे उपकरण प्रदान करता है जो गैर-वाष्पशील मेमोरी में डेटा के तत्काल लेखन की गारंटी देते हैं। कई विकल्प हैं, लेकिन वे दो मुख्य लोगों के लिए नीचे आते हैं: या तो एक सिंक्रनाइज़ेशन कमांड रिकॉर्डिंग (fsync, fdatasync) के बाद दिया जाता है, या जब एक फ़ाइल खोलना (या इसे लिखना), तो एक विशेष ध्वज को सिंक्रनाइज़ेशन या प्रत्यक्ष रिकॉर्डिंग के लिए इंगित किया जाता है, जो ओएस कैश को दरकिनार करता है।

लॉग के लिए के रूप में, pg_test_fsync उपयोगिता आपको एक विशिष्ट OS और एक विशिष्ट फ़ाइल सिस्टम के लिए सबसे उपयुक्त विधि चुनने की अनुमति देती है, और इसे wal_sync_method कॉन्फ़िगरेशन पैरामीटर में स्थापित किया जाता है। नियमित फ़ाइलें हमेशा fsync का उपयोग करके सिंक्रनाइज़ की जाती हैं।

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

प्रलेखन में इस विषय पर कई विवरण हैं।

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

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

डेटा भ्रष्टाचार

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

समय में समस्या का पता लगाने के लिए, जर्नल प्रविष्टियों को हमेशा चेकसम के साथ प्रदान किया जाता है।

डेटा पेज को चेकसम के साथ भी संरक्षित किया जा सकता है। अभी के लिए, यह केवल तब किया जा सकता है जब क्लस्टर को प्रारंभ किया जाता है, लेकिन PostgreSQL 12 में pg_checksums उपयोगिता का उपयोग करके उन्हें चालू और बंद करना संभव होगा (हालांकि अभी तक मक्खी पर नहीं है, लेकिन केवल तभी जब सर्वर बंद हो जाता है)।

उत्पादन के माहौल में, उनकी गणना और नियंत्रण के ओवरहेड होने के बावजूद चेकसम को शामिल किया जाना चाहिए। यह इस संभावना को कम कर देता है कि समय पर विफलता का पता नहीं चलेगा।

कम करता है, लेकिन खत्म नहीं करता है।
सबसे पहले, चेकसम को केवल पृष्ठ तक पहुंचते समय ही चेक किया जाता है - इसलिए, नुकसान तब तक किसी का ध्यान नहीं जा सकता जब तक कि यह सभी बैकअप में नहीं जाता। यही कारण है कि pg_probackup बैकअप के दौरान क्लस्टर के सभी पृष्ठों के चेकसम के लिए जाँच करता है।
दूसरे, शून्य से भरा एक पृष्ठ सही माना जाता है - यदि फ़ाइल सिस्टम गलती से फ़ाइल को "शून्य" कर देता है, तो यह किसी का ध्यान नहीं जा सकता है।
तीसरे, चेकसम केवल डेटा फ़ाइलों की मुख्य परत की रक्षा करते हैं। शेष परतें और अन्य फाइलें (उदाहरण के लिए, XACT लेनदेन की स्थिति) कुछ भी संरक्षित नहीं हैं।
अफसोस।

आइए देखें कि यह कैसे काम करता है। सबसे पहले, सुनिश्चित करें कि चेकसम सक्षम हैं (ध्यान रखें कि डेबियन जैसी प्रणालियों पर पैकेज स्थापित करते समय यह मामला नहीं है):

 => SHOW data_checksums;

  data_checksums ---------------- on (1 row)

Data_checksums पैरामीटर केवल-पढ़ने के लिए है।

यहाँ वह फ़ाइल है जिसमें हमारी तालिका स्थित है:

 => SELECT pg_relation_filepath('wallevel');

  pg_relation_filepath ---------------------- base/16386/24890 (1 row)

सर्वर को बंद करें और शून्य पृष्ठ में कुछ बाइट्स बदलें, उदाहरण के लिए, एलएसएन हेडर से अंतिम लॉग प्रविष्टि को हटा दें।

 student$ sudo pg_ctlcluster 11 main stop

 postgres$ dd if=/dev/zero of=/var/lib/postgresql/11/main/base/16386/24890 oflag=dsync conv=notrunc bs=1 count=8

 8+0 records in 8+0 records out 8 bytes copied, 0,0083022 s, 1,0 kB/s

सिद्धांत रूप में, सर्वर को रोका नहीं जा सकता था। यह पर्याप्त है कि पृष्ठ को डिस्क पर लिखा गया था और कैश से बाहर कर दिया गया था (अन्यथा सर्वर कैश से पृष्ठ के साथ काम करेगा)। लेकिन ऐसे परिदृश्य को पुन: पेश करना अधिक कठिन है।

अब हम सर्वर शुरू करते हैं और तालिका को पढ़ने की कोशिश करते हैं।

 student$ sudo pg_ctlcluster 11 main start

 => SELECT * FROM wallevel;

 WARNING: page verification failed, calculated checksum 23222 but expected 50884 ERROR: invalid page in block 0 of relation base/16386/24890

लेकिन क्या होगा यदि डेटा बैकअप से बहाल नहीं किया जा सकता है? Ign_checksum_failure पैरामीटर आपको विकृत डेटा प्राप्त करने के जोखिम के साथ, स्वाभाविक रूप से तालिका को पढ़ने की कोशिश करने की अनुमति देता है।

 => SET ignore_checksum_failure = on; => SELECT * FROM wallevel;

 WARNING: page verification failed, calculated checksum 23222 but expected 50884 n --- 1 (1 row)

बेशक, इस मामले में, सबकुछ ठीक हो जाता है, क्योंकि हमने केवल पृष्ठ का शीर्षक गड़बड़ कर दिया है, और डेटा ही नहीं।

और एक बात। जब चेकसम चालू होते हैं, तो संकेत के बिट्स लॉग में लिखे जाते हैं (हमने पहले उनकी जांच की ), चूंकि किसी भी परिवर्तन, यहां तक कि गैर-आवश्यक, बिट भी चेकसम में परिवर्तन की ओर जाता है। जब चेकसम बंद हो जाते हैं, तो wal_log_hints पैरामीटर लॉग में संकेत बिट्स लिखने के लिए जिम्मेदार होता है।

टूलटिप बिट्स में परिवर्तन हमेशा एक पूर्ण पृष्ठ छवि (FPI, पूर्ण पृष्ठ छवि) के रूप में लॉग इन किया जाता है, जो क्रम में लॉग के आकार को बढ़ाता है। इस मामले में, यह वाल_कंपिशन पैरामीटर का उपयोग करके पूर्ण छवियों के संपीड़न को सक्षम करने के लिए समझ में आता है (यह पैरामीटर 9.5 संस्करण में दिखाई दिया)। नीचे हम विशिष्ट संख्याओं को देखते हैं।

परमाणु रिकॉर्ड

और अंत में, रिकॉर्ड की परमाणुता की समस्या है। एक डेटाबेस पृष्ठ में कम से कम 8 KB (यह 16 या 32 KB हो सकता है), और निम्न स्तर पर, रिकॉर्डिंग उन ब्लॉकों में होती है जो आमतौर पर छोटे होते हैं (आमतौर पर 512 बाइट्स या 4 KB)। इसलिए, बिजली की विफलता की स्थिति में, डेटा पृष्ठ आंशिक रूप से दर्ज किया जा सकता है। यह स्पष्ट है कि पुनर्प्राप्ति के दौरान इस तरह के पृष्ठ पर साधारण जर्नल प्रविष्टियों को लागू करने का कोई मतलब नहीं है।

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

यदि एक लॉग में बहाली के दौरान एक पृष्ठ छवि का सामना किया जाता है, तो यह बिना शर्त (एलएसएन चेकिंग के बिना) डिस्क पर लिखा जाता है: इसमें अधिक विश्वास है, क्योंकि किसी भी लॉग रिकॉर्ड की तरह, यह एक चेकसम द्वारा संरक्षित है। और पहले से ही नियमित जर्नल प्रविष्टियाँ इस गारंटीकृत सही छवि पर लागू होती हैं।

यद्यपि PostgreSQL पूर्ण पृष्ठ छवि (हमने पहले ब्लॉक संरचना को देखा था ) से असंबद्ध स्थान को बाहर करता है, लेकिन उत्पन्न जर्नल प्रविष्टियों की मात्रा में काफी वृद्धि होती है। जैसा कि पहले ही उल्लेख किया गया है, पूर्ण छवियों ( Wal_compression पैरामीटर) को संकुचित करके स्थिति में सुधार किया जा सकता है।

किसी तरह लॉग के आकार में परिवर्तन महसूस करने के लिए, हम pgbench उपयोगिता का उपयोग करके एक सरल प्रयोग करेंगे। आइए आरंभ करते हैं:

 student$ pgbench -i test

 dropping old tables... creating tables... generating data... 100000 of 100000 tuples (100%) done (elapsed 0.15 s, remaining 0.00 s) vacuuming... creating primary keys... done.

Full_page_writes विकल्प सक्षम है:

 => SHOW full_page_writes;

  full_page_writes ------------------ on (1 row)

ब्रेकपॉइंट चलाएं और तुरंत 30 सेकंड के लिए परीक्षण चलाएं।

 => CHECKPOINT; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/38E04A08 (1 row)

 student$ pgbench -T 30 test

 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 30 s number of transactions actually processed: 26851 latency average = 1.117 ms tps = 895.006720 (including connections establishing) tps = 895.095229 (excluding connections establishing)

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3A69C478 (1 row)

लॉग आकार:

 => SELECT pg_size_pretty('0/3A69C478'::pg_lsn - '0/38E04A08'::pg_lsn);

  pg_size_pretty ---------------- 25 MB (1 row)

अब full_page_writes पैरामीटर बंद करें:

 => ALTER SYSTEM SET full_page_writes = off; => SELECT pg_reload_conf();

और प्रयोग को दोहराएं।

 => CHECKPOINT; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3A69C530 (1 row)

 student$ pgbench -T 30 test

 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 30 s number of transactions actually processed: 27234 latency average = 1.102 ms tps = 907.783080 (including connections establishing) tps = 907.895326 (excluding connections establishing)

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3BE87658 (1 row)

लॉग आकार:

 => SELECT pg_size_pretty('0/3BE87658'::pg_lsn - '0/3A69C530'::pg_lsn);

  pg_size_pretty ---------------- 24 MB (1 row)

हां, आकार में कमी आई है, लेकिन उतना महत्वपूर्ण नहीं है जितना कोई उम्मीद कर सकता है।

कारण यह है कि क्लस्टर को डेटा पृष्ठों में चेकसम के साथ आरंभीकृत किया जाता है, और इसलिए आपको टूलटिप बिट्स को बदलते समय लॉग को पूर्ण पृष्ठ छवियां लिखना होगा। ये डेटा (हमारे मामले में) कुल मात्रा का लगभग आधा है, जिसे आँकड़ों को देखकर देखा जा सकता है:

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump --stats -p /var/lib/postgresql/11/main/pg_wal -s 0/3A69C530 -e 0/3BE87658

 Type N (%) Record size (%) FPI size (%) ---- - --- ----------- --- -------- --- XLOG 1721 ( 1,03) 84329 ( 0,77) 13916104 (100,00) Transaction 27235 ( 16,32) 926070 ( 8,46) 0 ( 0,00) Storage 1 ( 0,00) 42 ( 0,00) 0 ( 0,00) CLOG 1 ( 0,00) 30 ( 0,00) 0 ( 0,00) Standby 4 ( 0,00) 240 ( 0,00) 0 ( 0,00) Heap2 27522 ( 16,49) 1726352 ( 15,76) 0 ( 0,00) Heap 109691 ( 65,71) 8169121 ( 74,59) 0 ( 0,00) Btree 756 ( 0,45) 45380 ( 0,41) 0 ( 0,00) -------- -------- -------- Total 166931 10951564 [44,04%] 13916104 [55,96%]

कॉम्पैक्टनेस के लिए, मैंने तालिका से शून्य पंक्तियों को हटा दिया। कुल लाइन (कुल) पर ध्यान दें और सामान्य रिकॉर्ड (रिकॉर्ड आकार) के आकार के साथ पूर्ण छवियों (एफपीआई आकार) के आकार की तुलना करें।

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

अब देखते हैं कि संपीड़न कैसे मदद करता है।

 => ALTER SYSTEM SET full_page_writes = on; => ALTER SYSTEM SET wal_compression = on; => SELECT pg_reload_conf();

उसी प्रयोग को दोहराएं।

 => CHECKPOINT; => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3BE87710 (1 row)

 student$ pgbench -T 30 test

 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 30 s number of transactions actually processed: 26833 latency average = 1.118 ms tps = 894.405027 (including connections establishing) tps = 894.516845 (excluding connections establishing)

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3CBD3EA8 (1 row)

लॉग आकार:

 => SELECT pg_size_pretty('0/3CBD3EA8'::pg_lsn - '0/3BE87710'::pg_lsn);

  pg_size_pretty ---------------- 13 MB (1 row)

निष्कर्ष: बड़ी संख्या में पूर्ण पृष्ठ छवियों (चेकसम या full_page_writes के कारण, अर्थात, लगभग हमेशा) की उपस्थिति में, यह सबसे अधिक संभावना इस तथ्य के बावजूद कि संपीड़न का उपयोग करने के लिए समझ में आता है कि यह प्रोसेसर को लोड करता है।

उत्पादकता

सामान्य सर्वर ऑपरेशन के दौरान, लॉग फ़ाइलों की एक निरंतर अनुक्रमिक रिकॉर्डिंग होती है। चूंकि कोई यादृच्छिक पहुँच नहीं है, इसलिए नियमित एचडीडी भी इस कार्य का सामना करते हैं। लेकिन लोड की यह प्रकृति डेटा फ़ाइलों तक पहुंचने के तरीके से काफी अलग है।

इसलिए, आमतौर पर लॉग को एक अलग भौतिक डिस्क (या डिस्क सरणी) पर सर्वर फ़ाइल सिस्टम पर माउंट करने के लिए लाभप्रद है। $ PGDATA / pg_wal निर्देशिका के बजाय, आपको संबंधित निर्देशिका के लिए एक प्रतीकात्मक लिंक बनाने की आवश्यकता है।

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

लॉगिंग एक दो मोड में होती है:

सिंक्रोनस - जब कोई लेनदेन किया जाता है, तब तक काम की निरंतरता असंभव है जब तक कि इस लेनदेन के बारे में सभी जर्नल प्रविष्टियां डिस्क पर न हों;
एसिंक्रोनस - लेनदेन तुरंत पूरा होता है, और लॉग पृष्ठभूमि में लिखा जाता है।

सिंक्रोनस मोड सिंक्रोनस_कमिट पैरामीटर द्वारा निर्धारित किया जाता है और डिफ़ॉल्ट रूप से सक्षम होता है।

चूंकि सिंक्रनाइज़ेशन वास्तविक (यानी, धीमा) I / O के साथ जुड़ा हुआ है, इसलिए इसे जितना संभव हो उतना कम प्रदर्शन करना फायदेमंद है। ऐसा करने के लिए, सर्विसिंग प्रक्रिया जो लेन-देन को पूरा करती है और एक लॉग लिखती है, एक छोटा विराम लेती है, जो कमेटी द्वारा निर्धारित किया जाता है। , commit_siblings . , . , , - .

commit_siblings = 5, commit_delay = 0, . commit_delay , OLTP-.

LSN ( , ). .

( D ACID) — , . , ( COMMIT ) .

, synchronous_commit = off ( local).

wal writer, ( wal_writer_delay = 200ms ).

, , WAL. , , , , . (, : , , .)

, ( ) — ?

, , .

— . : , 3 × wal_writer_delay ( ).

— — .

: ( fsync = off), . , , , .

synchronous_commit . , . , , .

. , WAL. , , .

- , , pgbench.

 => ALTER SYSTEM SET synchronous_commit = off; => SELECT pg_reload_conf();

 student$ pgbench -T 30 test

 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 30 s number of transactions actually processed: 45439 latency average = 0.660 ms tps = 1514.561710 (including connections establishing) tps = 1514.710558 (excluding connections establishing)

900 (tps), — 1500. , , , .

. - , . !

, .

PostgreSQL में चलें: 4. लॉग सेटअप

लॉग स्तर

मिनिमल

प्रतिकृति

तार्किक

रिकॉर्ड विश्वसनीयता

कैशिंग

डेटा भ्रष्टाचार

परमाणु रिकॉर्ड

उत्पादकता

More articles: