- क्यू1. क्या पीजी में किसी रिश्ते को कैश/वार्म करने की क्षमता है?
- क्यू2. क्या रखरखाव के कारण डेटाबेस सर्वर को बंद करने से पहले कैश की पूर्व स्थिति में वापस आना संभव है जहां इसे छोड़ा गया था?
पोस्टग्रेएसक्यूएल के पहले के रिलीज में, रिश्ते को गर्म करने या कैश स्टेट्स को स्टोर करने की कोई संभावना नहीं है, लेकिन पोस्टग्रेएसक्यूएल 9.4 से ऊपर के प्रत्येक प्रश्न (क्यू 1, क्यू 2) को दो कॉन्ट्रिब मॉड्यूल के साथ संबोधित किया गया है pg_prewarm और pg_hibernator . इस तथ्य के बावजूद कि वे व्यावहारिकता में विशिष्ट हैं, हालांकि संयोजन भविष्य में डीबीए के लिए बेहद व्यवहार्य और उपयोगी प्रतीत होता है। संक्षेप में योगदान के बारे में:
<ब्लॉकक्वॉट>pg_prewarm कॉन्ट्रिब (लेखक:रॉबर्ट हास), ओएस बफर कैश या पीजी बफर कैश में संबंध डेटा लोड करने की क्षमता प्रदान करता है। इसमें प्रीवार्म करने के लिए पहले या आखिरी ब्लॉक नंबर की कार्यक्षमता है। (नोट:कैशे बेदखली से पूर्व-गर्म डेटा पर इसकी कोई विशेष सुरक्षा नहीं है और यह भी कि यदि डेटाबेस इंस्टेंस को फिर से शुरू किया जाता है तो संबंधों पर फिर से गर्म करने की आवश्यकता होती है)।
<ब्लॉकक्वॉट>pg_hibernator कॉन्ट्रिब (लेखक:गुरजीत सिंह), डेटाबेस शटडाउन पर डिस्क पर साझा बफर सामग्री की सूची को स्वचालित रूप से सहेजने की क्षमता प्रदान करता है, और स्वचालित रूप से डेटाबेस स्टार्टअप पर बफ़र्स को पुनर्स्थापित करता है, जो कि शेयर्ड_बफ़र्स के स्नैपशॉट को सहेजने / पुनर्स्थापित करने के समान है। यह "पृष्ठभूमि कार्यकर्ता प्रक्रिया" को पंजीकृत करने के लिए पीजी 9.3 मॉड्यूल का उपयोग करता है और दो प्रक्रियाओं "बफर सेवर", "बफर रीडर" को बचाने / पुनर्स्थापित करने के लिए उत्पन्न करता है। दिलचस्प बात यह है कि एक छोटे से हैक के साथ, pg_hibernator स्टैंडबाय स्लेव को मास्टर की समान सामग्री के साथ पूरी गति से प्रश्नों की सेवा शुरू करने की अनुमति दे सकता है, इसे एक मिनट में देख लेंगे :)।
अंत में, हमें चाहिए pg_buffercache PostgreSQL साझा_बफ़र्स की वर्तमान सामग्री के अंदर देखने के लिए मॉड्यूल। यह मॉड्यूल यह समझने में मदद करता है कि संबंध द्वारा कितने प्रतिशत बफर का कब्जा है।
आइए इन सभी योगदानों को लागू करें और देखें कि वे कैसे दो प्रश्नों (Q1, Q2) के उद्देश्य की पूर्ति करते हैं। मैं अपने स्थानीय वीएम पर एक मानक pg_buffercache क्वेरी के साथ 885MB आकार की तालिका 'foo' का उपयोग करने जा रहा हूं।
SELECT c.relname,
count(*) AS buffers
FROM pg_class c
INNER JOIN pg_buffercache b ON b.relfilenode=c.relfilenode AND c.relname='foo'
INNER JOIN pg_database d ON (b.reldatabase=d.oid AND d.datname=current_database())
GROUP BY c.relname
ORDER BY 2 DESC LIMIT 10;
pg_prewarm contrib और वार्मिंग 'foo' टेबल का उपयोग।
postgres=# create extension pg_prewarm;
CREATE EXTENSION
postgres=# dt+
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------+----------+--------+-------------
public | foo | table | postgres | 885 MB |
(1 row)
postgres=# select pg_prewarm('foo');
pg_prewarm
------------
113278
(1 row)
--pg_buffercache query output
relname | buffers
---------+---------
foo | 113278
(1 row)
pg_prewarm . का बहुत ही सरल और सीधा उपयोग संबंध 'फू' के लिए साझा_बफ़र्स में गर्म किए गए ब्लॉक के आउटपुट के साथ। pg_buffercache . से क्वेरी आउटपुट हम इसका मूल्यांकन कर सकते हैं कि 113278 (113278 * 8/1024 =884MB) संबंध 'foo' के 8KB ब्लॉक आकार के बफर हैं जो pg_prewarm आउटपुट से मेल खाते हैं। यहां, अगर पोस्टग्रेज सर्वर किसी कारण से पुनरारंभ होता है, तो साझा_बफर खाली होते हैं और डीबीए को पिछले गर्म चरण में वापस आने के लिए फिर से गर्म करने की आवश्यकता होती है। एक टेबल के लिए, टेबल के समूह को छोड़कर इसकी पीड़ा को छोड़कर री-वार्म हमेशा आसान होता है।
इस बिंदु पर, हम pg_hibernator contrib का उपयोग कर सकते हैं, क्योंकि इसमें साझा_बफ़र की सामग्री को सहेजने और स्टार्टअप पर इसे वापस पुनर्स्थापित करने की सुविधा है। आइए pg_hibernator/pg_prewarm को एक साथ सक्षम करें और एक समान अभ्यास को केवल पुनरारंभ के एक चरण को शामिल करके चलाएं और देखें कि कैश स्थिति वापस आती है या नहीं। मैं pg_hibernator की स्थापना को कवर नहीं करने जा रहा हूं, क्योंकि git पर इसका बहुत अच्छी तरह से वर्णन किया गया है, हालाँकि मैं सीधे कार्यान्वयन भाग पर जाऊँगा और सर्वर को pg_hibernator से शुरू करूँगा।
postgres 24623 1 0 02:06 pts/4 00:00:00 /usr/local/pgpatch/pg/bin/postgres -D /usr/local/pgpatch/pg/data_10407
postgres 24627 24623 0 02:06 ? 00:00:00 postgres: logger process
postgres 24631 24623 0 02:06 ? 00:00:00 postgres: checkpointer process
postgres 24632 24623 0 02:06 ? 00:00:00 postgres: writer process
postgres 24633 24623 0 02:06 ? 00:00:00 postgres: wal writer process
postgres 24634 24623 0 02:06 ? 00:00:00 postgres: autovacuum launcher process
postgres 24635 24623 0 02:06 ? 00:00:00 postgres: archiver process
postgres 24636 24623 0 02:06 ? 00:00:00 postgres: stats collector process
postgres 24637 24623 0 02:06 ? 00:00:00 postgres: bgworker: Buffer Saver
postgres 24638 24623 11 02:06 ? 00:00:01 postgres: bgworker: Block Reader 2
In database server logs at startup time:
-bash-4.1$ more postgresql-2014-06-02_083033.log
LOG: database system was shut down at 2014-06-02 08:13:00 PDT
LOG: starting background worker process "Buffer Saver"
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
चूंकि, यह पहली बार खेल में pg_hibernator है, आप दो प्रक्रिया देख सकते हैं और "बफर सेवर" की शुरुआत के संबंध में कुछ जानकारी के साथ लॉग भी कर सकते हैं। अब, प्रीवार्म रिलेशन को 'फू' करते हैं और सर्वर को रीस्टार्ट करते हैं, बाद में बफर स्टेटस की जांच करते हैं कि क्या pg_hibernator ने बफर को वहीं से भर दिया है जहां इसे छोड़ा गया था।
-bash-4.1$ psql -p 10407
psql (9.4beta1)
Type "help" for help.
postgres=# select pg_prewarm('foo');
pg_prewarm
------------
113278
(1 row)
--pg_buffercache query output
relname | buffers
---------+---------
foo | 113278
(1 row)
postgres=# q
-bash-4.1$ /usr/local/pgpatch/pg/bin/pg_ctl -D /usr/local/pgpatch/pg/data_10407 stop
waiting for server to shut down.... done
server stopped
-bash-4.1$ ls -l $PGDATA/pg_hibernator/
total 12
-rw------- 1 postgres postgres 160 Jun 3 01:41 1.global.save
-rw------- 1 postgres postgres 915 Jun 3 01:41 2.postgres.save
-bash-4.1$ /usr/local/pgpatch/pg/bin/pg_ctl -D /usr/local/pgpatch/pg/data_10407 start
server starting
हमने डेटाबेस सर्वर को पुनरारंभ किया है, लॉग की जांच करने देता है
-bash-4.1$ more postgresql-2014-06-03_020601.log
LOG: database system was shut down at 2014-06-03 02:05:57 PDT
LOG: starting background worker process "Buffer Saver"
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: registering background worker "Block Reader 2"
LOG: starting background worker process "Block Reader 2"
LOG: Block Reader 2: restored 113433 blocks
LOG: Block Reader 2: all blocks read successfully
LOG: worker process: Block Reader 2 (PID 24638) exited with exit code 1
LOG: unregistering background worker "Block Reader 2"
LOG: registering background worker "Block Reader 1"
LOG: starting background worker process "Block Reader 1"
LOG: Block Reader 1: restored 20 blocks
LOG: Block Reader 1: all blocks read successfully
LOG: worker process: Block Reader 1 (PID 24664) exited with exit code 1
LOG: unregistering background worker "Block Reader 1"
तो, "बफर रीडर" ने 113433 + 20 के ब्लॉक को बहाल कर दिया है, जिसमें से 113278 संबंध 'फू' से संबंधित है। बढ़िया, आइए जुड़ते हैं और देखते हैं।
-bash-4.1$ psql -p 10407
psql (9.4beta1)
Type "help" for help.
--pg_buffercache query output
relname | buffers
---------+---------
foo | 113278
(1 row)
कूल… pg_hibernator ने DBA के हस्तक्षेप के बिना कैशे वार्म्ड अवस्था को वापस ला दिया है।
pg_hibernator के बारे में एक और अच्छी बात, एक नव निर्मित स्टैंडबाय में मास्टर के समान साझा बफर सामग्री हो सकती है, ताकि स्टैंडबाय पूरी गति से प्रश्नों की सेवा शुरू कर सके। इस अभ्यास को करने के लिए, $PGDATA निर्देशिका का बैकअप लेते समय, मैंने SIGTERM को "बफ़र सेवर" प्रक्रिया में पास कर दिया है ताकि यह डिस्क पर वर्तमान स्थिति साझा_बफ़र्स सामग्री लिख सके($PGDATA/pg_hibernator निर्देशिका) और फिर स्टैंडबाय सेटअप के साथ।
postgres 24637 24623 0 02:06 ? 00:00:00 postgres: bgworker: Buffer Saver
postgres 24653 15179 0 02:06 ? 00:00:01 postgres: wal receiver process streaming 1/6A000A10
postgres 24654 24623 0 02:06 ? 00:00:00 postgres: wal sender process postgres ::1(65011) streaming 1/6A000A10
सेटअप के बाद, मेरे दास ने प्राथमिक की समान सामग्री के साथ शुरुआत की
-bash-4.1$ psql -p 10477
psql (9.4beta1)
Type "help" for help.
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
t
(1 row)
--pg_buffercache query output
relname | buffers
---------+---------
foo | 113278
(1 row)
कैशिंग पर एक अद्भुत विस्तार के लिए दोनों लेखकों को धन्यवाद।
