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

अनसुलझे समस्या जो हमने पिछली बार रोक दी थी, यह ज्ञात नहीं है कि आप किस बिंदु पर पुनर्प्राप्ति के दौरान लॉग वापस खेलना शुरू कर सकते हैं। शुरुआत से शुरू, जैसा कि ऐलिस से राजा ने सलाह दी, काम नहीं करेगा: सर्वर प्रारंभ से सभी जर्नल प्रविष्टियों को संग्रहीत करना असंभव है - यह संभवतः एक बड़ी राशि है, और एक ही विशाल वसूली समय है। हमें धीरे-धीरे आगे बढ़ने वाले ऐसे बिंदु की आवश्यकता है जहां से हम पुनर्प्राप्ति शुरू कर सकें (और, तदनुसार, हम सभी पिछली जर्नल प्रविष्टियों को सुरक्षित रूप से हटा सकते हैं)। यह नियंत्रण बिंदु है जिस पर आज चर्चा की जाएगी।

नियंत्रण बिंदु

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

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

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

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

चेकपॉइंट एक विशेष पृष्ठभूमि चेकपॉइंट प्रक्रिया द्वारा नियंत्रित किया जाता है।

गंदे बफ़र्स की अवधि चेकपॉइंट_completion_target पैरामीटर के मान से निर्धारित होती है। यह दिखाता है कि रिकॉर्डिंग के दो आसन्न नियंत्रण बिंदुओं के बीच कितना समय होगा। डिफ़ॉल्ट मान 0.5 है (ऊपर दिए गए आंकड़ों के अनुसार), अर्थात, रिकॉर्डिंग नियंत्रण बिंदुओं के बीच आधा समय लेता है। आमतौर पर, अधिक से अधिक एकरूपता के लिए मान 1.0 तक बढ़ाया जाता है।

आइए अधिक विस्तार से विचार करें कि नियंत्रण बिंदु निष्पादित होने पर क्या होता है।

चेकपॉइंट प्रक्रिया पहले लेन-देन की स्थिति बफ़र्स (XACT) डिस्क पर फ़्लश करती है। चूंकि उनमें से कुछ हैं (कुल में 128), वे तुरंत दर्ज किए जाते हैं।

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

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

लेबल किए गए बफ़र्स को सर्वर प्रक्रियाओं द्वारा भी लिखा जा सकता है - यह निर्भर करता है कि पहले बफर में कौन जाता है। किसी भी स्थिति में, रिकॉर्डिंग करते समय पहले से सेट किया गया झंडा हटा दिया जाता है, इसलिए (चेकपॉइंट के उद्देश्य से) बफर केवल एक बार लिखा जाएगा।

स्वाभाविक रूप से, चेकपॉइंट के निष्पादन के दौरान, पृष्ठ बफर कैश में बदलते रहते हैं। लेकिन नए गंदे बफ़र्स को चिह्नित नहीं किया जाता है और चेकपॉइंट प्रक्रिया को उन्हें नहीं लिखना चाहिए।

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

इसके अलावा, $ PGDATA / वैश्विक / pg_control फ़ाइल अंतिम चेकपॉइंट के पारित होने के संकेत को अपडेट करती है। चेकपॉइंट पूरा होने से पहले, पिछले चेकपॉइंट पर pg_control पॉइंट।

चौकी के काम को देखने के लिए, कुछ तालिका बनाएं - इसके पृष्ठ बफर कैश में जाएंगे और यह गंदे हो जाएंगे:

=> CREATE TABLE chkpt AS SELECT * FROM generate_series(1,10000) AS g(n); => CREATE EXTENSION pg_buffercache; => SELECT count(*) FROM pg_buffercache WHERE isdirty;

  count ------- 78 (1 row)

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

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3514A048 (1 row)

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

 => CHECKPOINT; => SELECT count(*) FROM pg_buffercache WHERE isdirty;

  count ------- 0 (1 row)

आइए देखें कि लॉग में चौकी कैसे परिलक्षित हुई:

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3514A0E4 (1 row)

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/3514A048 -e 0/3514A0E4

 rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/3514A048, prev 0/35149CEC, desc: RUNNING_XACTS nextXid 101105 latestCompletedXid 101104 oldestRunningXid 101105

 rmgr: XLOG len (rec/tot): 102/ 102, tx: 0, lsn: 0/3514A07C, prev 0/3514A048, desc: CHECKPOINT_ONLINE redo 0/3514A048; tli 1; prev tli 1; fpw true; xid 0:101105; oid 74081; multi 1; offset 0; oldest xid 561 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 101105; online

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

हमें नियंत्रण फ़ाइल में समान जानकारी मिलेगी:

 postgres$ /usr/lib/postgresql/11/bin/pg_controldata -D /var/lib/postgresql/11/main | egrep 'Latest.*location'

 Latest checkpoint location: 0/3514A07C Latest checkpoint's REDO location: 0/3514A048

वसूली

अब हम पिछले लेख में उल्लिखित पुनर्प्राप्ति एल्गोरिथ्म को स्पष्ट करने के लिए तैयार हैं।

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

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

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

अंत में, सभी गैर-जर्नल तालिकाएँ init फ़ाइलों में छवियों का उपयोग करके ओवरराइट की जाती हैं।

इस बिंदु पर, स्टार्टअप प्रक्रिया समाप्त हो जाती है, और चेकपॉइंट प्रक्रिया तुरंत डिस्क पर पुनर्स्थापित स्थिति को ठीक करने के लिए एक चेकपॉइंट निष्पादित करती है।

आप तत्काल मोड में सर्वर को जबरन रोककर विफलता का अनुकरण कर सकते हैं।

 student$ sudo pg_ctlcluster 11 main stop -m immediate --skip-systemctl-redirect

(- --skip-systemctl-redirect key की यहाँ आवश्यकता है क्योंकि PostgreSQL उबंटू में पैकेज से स्थापित है। इसे pg_ctlcluster कमांड द्वारा नियंत्रित किया जाता है, जिसे वास्तव में systemctl कहते हैं, और यह पहले से ही pg_ctl को कॉल करता है। इन सभी आवरणों के साथ, मोड नाम। रास्ते में खो गया है, और --skip-systemctl-redirect आपको --skip-systemctl-redirect बिना करने और अन्य जानकारी को बचाने की अनुमति देता है।

क्लस्टर स्थिति की जाँच करें:

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

 Database cluster state: in production

स्टार्टअप पर, PostgreSQL समझता है कि एक विफलता हुई है और एक वसूली की आवश्यकता है।

 student$ sudo pg_ctlcluster 11 main start

 postgres$ tail -n 7 /var/log/postgresql/postgresql-11-main.log

 2019-07-17 15:27:49.441 MSK [8865] LOG: database system was interrupted; last known up at 2019-07-17 15:27:48 MSK 2019-07-17 15:27:49.801 MSK [8865] LOG: database system was not properly shut down; automatic recovery in progress 2019-07-17 15:27:49.804 MSK [8865] LOG: redo starts at 0/3514A048 2019-07-17 15:27:49.804 MSK [8865] LOG: invalid record length at 0/3514A0E4: wanted 24, got 0 2019-07-17 15:27:49.804 MSK [8865] LOG: redo done at 0/3514A07C 2019-07-17 15:27:49.824 MSK [8864] LOG: database system is ready to accept connections 2019-07-17 15:27:50.409 MSK [8872] [unknown]@[unknown] LOG: incomplete startup packet

संदेश लॉग में पुनर्प्राप्ति की आवश्यकता नोट की गई है: डेटाबेस सिस्टम को ठीक से बंद नहीं किया गया था; स्वचालित पुनर्प्राप्ति प्रगति पर है । फिर, जर्नल प्रविष्टियाँ "फिर से शुरू होता है" में चिह्नित स्थिति से खेलना शुरू करती हैं और तब तक जारी रहती हैं जब तक कि अगली जर्नल प्रविष्टियों को पुनर्प्राप्त नहीं किया जा सकता। यह "फिर से किया गया" स्थिति में पुनर्प्राप्ति को पूरा करता है और DBMS क्लाइंट के साथ काम करना शुरू कर देता है ( डेटाबेस सिस्टम कनेक्शन स्वीकार करने के लिए तैयार है )।

और एक सामान्य सर्वर शटडाउन के दौरान क्या होता है? गंदे पन्नों को डिस्क में फ्लश करने के लिए, PostgreSQL सभी क्लाइंट को डिस्कनेक्ट करता है और फिर अंतिम चेकपॉइंट चलाता है।

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

 => SELECT pg_current_wal_insert_lsn();

  pg_current_wal_insert_lsn --------------------------- 0/3514A14C (1 row)

अब सर्वर को धीरे से बंद करें:

 student$ sudo pg_ctlcluster 11 main stop

क्लस्टर स्थिति की जाँच करें:

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

 Database cluster state: shut down

और लॉग में हमें अंतिम नियंत्रण बिंदु (CHECKPOINT_SHUTDOWN) के बारे में एकमात्र रिकॉर्ड मिलता है:

 postgres$ /usr/lib/postgresql/11/bin/pg_waldump -p /var/lib/postgresql/11/main/pg_wal -s 0/3514A14C

 rmgr: XLOG len (rec/tot): 102/ 102, tx: 0, lsn: 0/3514A14C, prev 0/3514A0E4, desc: CHECKPOINT_SHUTDOWN redo 0/3514A14C; tli 1; prev tli 1; fpw true; xid 0:101105; oid 74081; multi 1; offset 0; oldest xid 561 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown

 pg_waldump: FATAL: error in WAL record at 0/3514A14C: invalid record length at 0/3514A1B4: wanted 24, got 0

(एक भयानक घातक संदेश में, pg_waldump केवल यह कहना चाहता है कि वह पत्रिका के अंत तक पढ़ता है।)

फिर से उदाहरण दें।

 student$ sudo pg_ctlcluster 11 main start

बैकग्राउंड रिकॉर्डिंग

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

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

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

यह "अगले शिकार" के लिए एक संकेतक का उपयोग नहीं करता है, लेकिन इसका अपना है। वह सूचक से आगे "शिकार" हो सकता है, लेकिन कभी भी उससे पीछे नहीं रहता।
जब भैंसों को ट्रेस किया जाता है, तो हिट काउंटर कम नहीं होता है।

बफ़र लिखे गए हैं जो एक साथ हैं:

परिवर्तित डेटा (गंदा),
निश्चित नहीं (पिन गणना = 0),
शून्य हिट (उपयोग गणना = 0)।

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

समायोजन

चेकपॉइंट प्रक्रिया आमतौर पर निम्नलिखित कारणों से कॉन्फ़िगर की जाती है।

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

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

यह समय नियंत्रण बिंदुओं के बीच हमारा सामान्य अंतराल होगा। हम इसे चेकपॉइंट_ टाइमआउट पैरामीटर में लिखते हैं। 5 मिनट का डिफ़ॉल्ट मूल्य स्पष्ट रूप से बहुत छोटा है, आमतौर पर समय बढ़ाया जाता है, कहते हैं, आधे घंटे तक। मैं दोहराता हूं: कम बार आप मील के पत्थर बर्दाश्त कर सकते हैं, बेहतर - यह ओवरहेड को कम करता है।

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

इस प्रकार, अधिकांश नियंत्रण बिंदु एक समय पर होते हैं: एक बार चेकपॉइंट_ टाइमआउट इकाइयों के अनुसार। लेकिन अधिक लोड के साथ, नियंत्रण बिंदु को अधिक बार कहा जाता है जब max_wal_size वॉल्यूम तक पहुंच जाता है ।

यह समझना महत्वपूर्ण है कि max_wal_size पैरामीटर डिस्क पर फ़ाइलों को लॉग करने वाली अधिकतम मात्रा को निर्धारित नहीं कर सकता है।

एक विफलता से उबरने के लिए, आपको उस पल से फ़ाइलों को संग्रहीत करने की आवश्यकता है जिस समय से अंतिम चेकपॉइंट पारित किया गया था, और वर्तमान चेकपॉइंट के संचालन के दौरान जमा हुई फाइलें। इसलिए, कुल मात्रा का अनुमान लगाया जा सकता है
(1 + checkpoint_completion_target ) × max_wal_size
संस्करण 11 से पहले, PostgreSQL ने दो-वर्षीय चेकपॉइंट के लिए फाइलें भी संग्रहीत की हैं, इसलिए उपरोक्त सूत्र में संस्करण 10 तक, आपको 1 के बजाय 2 सेट करना होगा।
Max_wal_size पैरामीटर केवल एक इच्छा है, लेकिन एक कठिन सीमा नहीं है। यह अधिक हो सकता है।
सर्वर को लॉग फ़ाइलों को मिटाने का अधिकार नहीं है जो अभी तक प्रतिकृति स्लॉट्स के माध्यम से स्थानांतरित नहीं किए गए हैं और जो अभी तक निरंतर संग्रह के दौरान संग्रहीत नहीं किए गए हैं। यदि इस कार्यक्षमता का उपयोग किया जाता है, तो निरंतर निगरानी आवश्यक है, क्योंकि सर्वर मेमोरी को ओवरफ्लो करना आसान है।

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

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

पृष्ठभूमि की रिकॉर्डिंग प्रक्रिया अधिकांश bgwriter_lru_maxpages पृष्ठों पर चक्रों में चलती है, bgwriter_delay पर चक्रों के बीच सो रही है।

कार्य के एक चक्र में दर्ज किए जाने वाले पृष्ठों की संख्या को उन बफ़रों की औसत संख्या से निर्धारित किया जाता है, जिन्हें अंतिम रन से सर्विसिंग प्रक्रियाओं द्वारा अनुरोध किया गया था (रन के बीच असमानता को शांत करने के लिए एक चलती औसत का उपयोग करते हुए, लेकिन एक लंबे इतिहास पर निर्भर नहीं)। बफ़र्स की परिकलित संख्या गुणांक bgwriter_lru_multiplier द्वारा गुणा की जाती है (लेकिन किसी भी स्थिति में यह bgwriter_lru_maxpages से अधिक नहीं होगी)।

डिफ़ॉल्ट मान: bgwriter_delay = 200ms (बहुत अधिक संभावना है, यह 1/5 सेकंड में बहुत पानी लीक करता है ), bgwriter_lru_maxpages = 100, bgwriter_lru_bultiplier = 2.0 (हम समय से पहले मांग का जवाब देने की कोशिश करते हैं)।

यदि प्रक्रिया गंदे बफ़र्स का पता नहीं लगाती है (जो कि सिस्टम में कुछ भी नहीं होता है), तो यह "हाइबरनेट्स" होता है, जिसमें से यह घटाया जाता है कि सर्वर प्रक्रिया बफर तक पहुंचती है। उसके बाद, प्रक्रिया जाग जाती है और फिर से सामान्य तरीके से काम करती है।

निगरानी

नियंत्रण बिंदु और पृष्ठभूमि रिकॉर्डिंग सेटिंग्स को मॉनिटरिंग से प्रतिक्रिया प्राप्त करते हुए, समायोजित किया जा सकता है और किया जाना चाहिए।

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

Log_checkpoint पैरामीटर (डिफ़ॉल्ट रूप से अक्षम) सर्वर संदेश लॉग में निष्पादित चौकियों के बारे में जानकारी प्राप्त करने की अनुमति देता है। इसे चालू करें।

 => ALTER SYSTEM SET log_checkpoints = on; => SELECT pg_reload_conf();

अब डेटा में कुछ बदलें और चेकपॉइंट को निष्पादित करें।

 => UPDATE chkpt SET n = n + 1; => CHECKPOINT;

संदेश लॉग में हम कुछ इस तरह देखेंगे:

 postgres$ tail -n 2 /var/log/postgresql/postgresql-11-main.log

 2019-07-17 15:27:55.248 MSK [8962] LOG: checkpoint starting: immediate force wait 2019-07-17 15:27:55.274 MSK [8962] LOG: checkpoint complete: wrote 79 buffers (0.5%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.013 s, total=0.025 s; sync files=2, longest=0.011 s, average=0.006 s; distance=1645 kB, estimate=1645 kB

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

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

 => SELECT * FROM pg_stat_bgwriter \gx

 -[ RECORD 1 ]---------+------------------------------ checkpoints_timed | 0 checkpoints_req | 1 checkpoint_write_time | 1 checkpoint_sync_time | 13 buffers_checkpoint | 79 buffers_clean | 0 maxwritten_clean | 0 buffers_backend | 42 buffers_backend_fsync | 0 buffers_alloc | 363 stats_reset | 2019-07-17 15:27:49.826414+03

यहां, अन्य बातों के अलावा, हम नियंत्रण बिंदुओं की संख्या को पूरा होते हुए देखते हैं:

चौकियों_तलाई - अनुसूची के अनुसार (चेकपॉइंट_ टाइमआउट पर पहुंचने पर),
चौकियों_रेक - ऑन डिमांड (अधिकतम_वाल_साइज तक पहुंचने सहित)।

चेकपॉइंट_रेक (चौकियों की तुलना में) का बड़ा मूल्य इंगित करता है कि नियंत्रण बिंदु अपेक्षा से अधिक बार होते हैं।

दर्ज पृष्ठों की संख्या के बारे में महत्वपूर्ण जानकारी:

बफ़र्स_चेकपॉइंट - चेकपॉइंट प्रक्रिया,
बफ़र्स_बैकेंड - सेवा प्रक्रियाओं द्वारा,
बफ़र्स_क्लीन - पृष्ठभूमि रिकॉर्डिंग प्रक्रिया।

एक सुव्यवस्थित प्रणाली पर, बफ़र्स_बैकेंड का मान बफ़र्स_चेकपॉइंट और बफ़र्स_क्लाइन के योग से काफी कम होना चाहिए।

साथ ही, बैकग्राउंड रिकॉर्डिंग स्थापित करने के लिए maxwritten_clean उपयोगी है - यह संख्या बताती है कि bgwriter_lru_maxpages से अधिक होने के कारण बैकग्राउंड रिकॉर्डिंग प्रक्रिया कितनी बार काम करना बंद कर देती है ।

आप निम्न कॉल का उपयोग करके संचित आंकड़ों को रीसेट कर सकते हैं:

 => SELECT pg_stat_reset_shared('bgwriter');

जारी रखा जाए ।

PostgreSQL में चलें: 3. चेकपॉइंट

नियंत्रण बिंदु

वसूली

बैकग्राउंड रिकॉर्डिंग

समायोजन

निगरानी

More articles: