पिछली बार, हम साझा मेमोरी, बफर कैश की महत्वपूर्ण वस्तुओं में से एक के डिवाइस से मिले थे। रैम से जानकारी खोने की संभावना विफलता से उबरने की आवश्यकता का मुख्य कारण है। आज हम इन उपकरणों के बारे में बात करेंगे।

पत्रिका

काश, चमत्कार नहीं होता: रैम में सूचना के नुकसान से बचने के लिए, एक डिस्क (या अन्य गैर-वाष्पशील उपकरण) को समय पर ढंग से लिखने के लिए आवश्यक सब कुछ लिखा जाना चाहिए।

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

इस काम के लिए, जर्नल प्रविष्टि को आवश्यक रूप से संशोधित पेज पर जाने से पहले डिस्क पर जाना चाहिए। इसलिए नाम: राइट-फॉरवर्ड लॉग।

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

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

आपको सभी ऑपरेशनों को लॉग करने की आवश्यकता है, जिसके दौरान विफलता की स्थिति में डिस्क पर असंगति का खतरा होता है। विशेष रूप से, निम्न क्रियाएं लॉग होती हैं:

• बफ़र कैश में पृष्ठ बदलना (एक नियम के रूप में, ये टेबल और इंडेक्स पेज हैं) - चूंकि परिवर्तित पृष्ठ तुरंत डिस्क पर नहीं जाता है;
• लेनदेन करना और रद्द करना - XACT बफ़र्स में स्थिति परिवर्तन होता है और डिस्क तक तुरंत नहीं पहुंचता है;
• फ़ाइल संचालन (फ़ाइलों और निर्देशिकाओं को बनाना और हटाना, उदाहरण के लिए, तालिका बनाते समय फ़ाइलें बनाना) - चूंकि ये ऑपरेशन डेटा परिवर्तनों के साथ एक साथ होने चाहिए।

लॉग नहीं किया गया:

• गैर-जर्नलिज्ड (अनलॉग्ड) तालिकाओं के साथ संचालन - उनका नाम खुद के लिए बोलता है;
• अस्थायी तालिकाओं के साथ संचालन - इसका कोई मतलब नहीं है, क्योंकि ऐसी तालिकाओं का जीवनकाल उस सत्र के जीवनकाल से अधिक नहीं है जो उन्हें बनाया था।

PostgreSQL 10 से पहले, हैश इंडेक्स लॉग नहीं किए गए थे (वे केवल विभिन्न डेटा प्रकारों के लिए हैश फ़ंक्शन को मैप करने के लिए परोसे गए थे ), लेकिन अब यह तय हो गया है।

तार्किक उपकरण

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

• लेनदेन संख्या जिस पर रिकॉर्ड है।
• संसाधन प्रबंधक - रिकॉर्डिंग के लिए जिम्मेदार प्रणाली का घटक;
• चेकसम (सीआरसी) - आपको डेटा भ्रष्टाचार का निर्धारण करने की अनुमति देता है;
• रिकॉर्ड लंबाई और पिछले रिकॉर्ड के लिए लिंक।

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

pg_waldump -r list 

भौतिक उपकरण

डिस्क पर, लॉग को $ PGDATA / pg_wal निर्देशिका में फ़ाइलों के रूप में संग्रहीत किया जाता है। प्रत्येक फ़ाइल 16 एमबी तक डिफॉल्ट करती है। एक निर्देशिका में बड़ी संख्या में फ़ाइलों से बचने के लिए आकार बढ़ाया जा सकता है। PostgreSQL 11 से पहले, यह केवल स्रोत कोड संकलित करते समय किया जा सकता था, लेकिन अब आप क्लस्टर को निर्दिष्ट करते समय आकार निर्दिष्ट कर सकते हैं ( --wal-segsize )।

लॉग प्रविष्टियाँ वर्तमान फ़ाइल में उपयोग में आती हैं; जब यह समाप्त होता है, तो अगले का उपयोग किया जाना शुरू हो जाता है।

सर्वर की साझा मेमोरी में लॉग के लिए विशेष बफ़र आवंटित किए जाते हैं। पत्रिका कैश का आकार Wal_buffers पैरामीटर द्वारा निर्धारित किया जाता है (डिफ़ॉल्ट मान का तात्पर्य स्वचालित कॉन्फ़िगरेशन: बफर कैश का 1/32 आवंटित किया जाता है)।

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

रिकॉर्डिंग ("पूंछ") और सम्मिलन ("सिर") पद क्रमशः pg_current_wal_lsn और pg_current_wal_insert lsn को दर्शाते हैं:

 => SELECT pg_current_wal_lsn(), pg_current_wal_insert_lsn(); 

  pg_current_wal_lsn | pg_current_wal_insert_lsn --------------------+--------------------------- 0/331E4E64 | 0/331E4EA0 (1 row) 

एक विशिष्ट रिकॉर्ड को संदर्भित करने के लिए, डेटा प्रकार pg_lsn (LSN = लॉग अनुक्रम संख्या) का उपयोग किया जाता है - यह 64-बिट संख्या है जो लॉग की शुरुआत के सापेक्ष रिकॉर्ड से पहले बाइट ऑफसेट का प्रतिनिधित्व करता है। LSN हेक्साडेसिमल नोटेशन में दो 32-बिट संख्या के रूप में आउटपुट है।

आप यह पता कर सकते हैं कि हमें किस फ़ाइल में वांछित स्थिति मिलेगी, और फ़ाइल की शुरुआत से क्या ऑफसेट है:

 => SELECT file_name, upper(to_hex(file_offset)) file_offset FROM pg_walfile_name_offset('0/331E4E64'); 

  file_name | file_offset --------------------------+------------- 000000010000000000000033 | 1E4E64 \ /\ /  0/331E4E64  

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

लॉग फ़ाइलों को $ PGDATA / pg_wal / निर्देशिका में फ़ाइल सिस्टम पर देखा जा सकता है, लेकिन PostgreSQL 10 से शुरू करके उन्हें एक विशेष फ़ंक्शन के साथ भी देखा जा सकता है:

 => SELECT * FROM pg_ls_waldir() WHERE name = '000000010000000000000033'; 

  name | size | modification --------------------------+----------+------------------------ 000000010000000000000033 | 16777216 | 2019-07-08 20:24:13+03 (1 row) 

फॉरवर्ड लिखो

आइए देखें कि जर्नलिंग कैसे होती है और प्रोएक्टिव रिकॉर्डिंग कैसे प्रदान की जाती है। एक तालिका बनाएँ:

 => CREATE TABLE wal(id integer); => INSERT INTO wal VALUES (1); 

हम टेबल पेज के हेडर को देखेंगे। ऐसा करने के लिए, हमें पहले से ही परिचित एक्सटेंशन की आवश्यकता है:

 => CREATE EXTENSION pageinspect; 

आइए लेन-देन शुरू करें और लॉग में प्रविष्टि की स्थिति याद रखें:

 => BEGIN; => SELECT pg_current_wal_insert_lsn(); 

  pg_current_wal_insert_lsn --------------------------- 0/331F377C (1 row) 

अब कुछ ऑपरेशन करते हैं, उदाहरण के लिए, लाइन को अपडेट करें:

 => UPDATE wal set id = id + 1; 

यह परिवर्तन लॉग में दर्ज किया गया था, प्रविष्टि की स्थिति बदल गई है:

 => SELECT pg_current_wal_insert_lsn(); 

  pg_current_wal_insert_lsn --------------------------- 0/331F37C4 (1 row) 

यह सुनिश्चित करने के लिए कि संशोधित डेटा पृष्ठ को जर्नल प्रविष्टि से पहले डिस्क में धकेल नहीं दिया गया है, इस पृष्ठ से संबंधित अंतिम जर्नल प्रविष्टि का LSN पृष्ठ शीर्षक में संग्रहीत है:

 => SELECT lsn FROM page_header(get_raw_page('wal',0)); 

  lsn ------------ 0/331F37C4 (1 row) 

ध्यान रखें कि जर्नल पूरे क्लस्टर के लिए सामान्य है, और नई प्रविष्टियाँ हर समय इसमें आती हैं। इसलिए, पृष्ठ पर LSN उस मान से कम हो सकता है जो pg_current_wal_insert_lsn फ़ंक्शन अभी लौटा है। लेकिन हमारे सिस्टम में ऐसा कुछ नहीं होता है, इसलिए संख्या समान है।

अब लेन-देन पूरा करें।

 => COMMIT; 

प्रतिबद्ध रिकॉर्ड लॉग में भी जाता है, और स्थिति फिर से बदल जाती है:

 => SELECT pg_current_wal_insert_lsn(); 

  pg_current_wal_insert_lsn --------------------------- 0/331F37E8 (1 row) 

प्रतिबद्ध XACT नामक संरचना में लेनदेन की स्थिति में परिवर्तन करता है (हमने पहले से ही इसके बारे में बात की है )। स्टेटस को फाइलों में संग्रहीत किया जाता है, लेकिन वे अपने स्वयं के कैश का भी उपयोग करते हैं, जो साझा मेमोरी में 128 पृष्ठों पर कब्जा कर लेता है। इसलिए, XACT पृष्ठों के लिए, अंतिम जर्नल प्रविष्टि के LSN को ट्रैक करना होगा। लेकिन यह जानकारी पृष्ठ में ही संग्रहीत नहीं है, बल्कि रैम में है।

कुछ बिंदु पर, बनाई गई जर्नल प्रविष्टियों को डिस्क पर लिखा जाएगा। जिसमें एक - हम दूसरी बार बात करेंगे, लेकिन हमारे मामले में यह पहले ही हो चुका है:

 => SELECT pg_current_wal_lsn(), pg_current_wal_insert_lsn(); 

  pg_current_wal_lsn | pg_current_wal_insert_lsn --------------------+--------------------------- 0/331F37E8 | 0/331F37E8 (1 row) 

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

दो एलएसएन पदों को जानने के बाद, आप उनके बीच (बाइट्स में) जर्नल प्रविष्टियों का आकार प्राप्त कर सकते हैं, बस एक स्थिति को दूसरे से घटाकर। आपको बस पदों को pg_lsn टाइप करने की आवश्यकता है:

 => SELECT '0/331F37E8'::pg_lsn - '0/331F377C'::pg_lsn; 

  ?column? ---------- 108 (1 row) 

इस स्थिति में, लाइन अद्यतन और लॉग में आवश्यक 108 बाइट्स की आवश्यकता होती है।

उसी तरह, आप यह अनुमान लगा सकते हैं कि एक निश्चित लोड पर सर्वर की प्रति यूनिट समय में कितनी जर्नल प्रविष्टियाँ बनती हैं। यह महत्वपूर्ण जानकारी है जो सेटअप के दौरान आवश्यक होगी (जो हम अगली बार के बारे में बात करेंगे)।

अब हम बनाए गए लॉग प्रविष्टियों को देखने के लिए pg_waldump उपयोगिता का उपयोग करेंगे।

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

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/331F377C -e 0/331F37E8 000000010000000000000033 

 rmgr: Heap len (rec/tot): 69/ 69, tx: 101085, lsn: 0/331F377C, prev 0/331F3014, desc: HOT_UPDATE off 1 xmax 101085 ; new off 2 xmax 0, blkref #0: rel 1663/16386/33081 blk 0 

 rmgr: Transaction len (rec/tot): 34/ 34, tx: 101085, lsn: 0/331F37C4, prev 0/331F377C, desc: COMMIT 2019-07-08 20:24:13.945435 MSK 

यहाँ हम दो प्रविष्टियों के हेडर देखते हैं।

पहला है HOT_UPDATE ऑपरेशन, हीप रिसोर्स मैनेजर से संबंधित है। फ़ाइल का नाम और पृष्ठ संख्या blkref फ़ील्ड में दर्शाई गई है और अद्यतन तालिका पृष्ठ से मेल खाती है:

 => SELECT pg_relation_filepath('wal'); 

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

दूसरी प्रविष्टि COMMIT है, जो लेन-देन संसाधन प्रबंधक से संबंधित है।

सबसे पठनीय प्रारूप नहीं, लेकिन यदि आवश्यक हो तो आप इसका पता लगा सकते हैं।

वसूली

जब हम सर्वर शुरू करते हैं, तो पोस्टमास्टर प्रक्रिया पहले शुरू होती है, और यह बदले में, स्टार्टअप प्रक्रिया शुरू करता है, जिसमें से एक विफलता होने पर पुनर्प्राप्ति सुनिश्चित करने का कार्य है।

यह निर्धारित करने के लिए कि पुनर्प्राप्ति की आवश्यकता है, स्टार्टअप विशेष नियंत्रण फ़ाइल $ PGDATA / वैश्विक / pg_control में दिखता है और क्लस्टर स्थिति को देखता है। हम स्वयं pg_controldata उपयोगिता का उपयोग करके स्थिति की जाँच कर सकते हैं:

 postgres$ /usr/lib/postgresql/11/bin/pg_controldata -D /var/lib/postgresql/11/main | grep state 

 Database cluster state: in production 

बड़े करीने से बंद सर्वर की स्थिति "बंद" होगी। यदि सर्वर काम नहीं करता है, और स्थिति "उत्पादन" में रहती है, तो इसका मतलब है कि DBMS गिर गया है और फिर वसूली स्वचालित रूप से की जाएगी।

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

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

पुनर्प्राप्ति के दौरान पृष्ठों को बदलना बफ़र कैश में होता है, जैसे कि सामान्य कार्य के दौरान - इसके लिए पोस्टमास्टर आवश्यक पृष्ठभूमि प्रक्रियाओं को शुरू करता है।

इसी तरह, जर्नल प्रविष्टियाँ फ़ाइलों पर लागू होती हैं: उदाहरण के लिए, यदि कोई रिकॉर्ड कहता है कि फ़ाइल मौजूद होनी चाहिए, लेकिन यह मौजूद नहीं है, फ़ाइल बनाई गई है।

ठीक है, ठीक होने की प्रक्रिया के अंत में, सभी गैर-मेज़ों की तालिकाओं को उनकी इनिट परतों से "डमीज़" के साथ ओवरराइट किया जाता है।

यह एल्गोरिथ्म की एक बहुत ही सरल प्रस्तुति है। विशेष रूप से, हमने कुछ भी नहीं कहा है कि जर्नल प्रविष्टियों को पढ़ना कहां शुरू किया जाए (यह बातचीत तब तक स्थगित करनी होगी जब तक कि चेकपॉइंट नहीं माना जाता है)।

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

जारी रखा जाए ।