PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

मेरा PostgreSQL डेटाबेस डिस्क स्थान से बाहर है

डिस्क स्थान आजकल एक मांग वाला संसाधन है। आप आमतौर पर यथासंभव लंबे समय तक डेटा संग्रहीत करना चाहेंगे, लेकिन यह एक समस्या हो सकती है यदि आप संभावित "डिस्क स्थान से बाहर" समस्या को रोकने के लिए आवश्यक कार्रवाई नहीं करते हैं।

इस ब्लॉग में, हम देखेंगे कि कैसे हम PostgreSQL के लिए इस समस्या का पता लगा सकते हैं, इसे रोक सकते हैं, और यदि यह बहुत देर हो चुकी है, तो कुछ विकल्प जो शायद इसे ठीक करने में आपकी सहायता करेंगे।

PostgreSQL डिस्क स्थान समस्याओं की पहचान कैसे करें

दुर्भाग्यवश, यदि आप डिस्क स्थान से बाहर इस स्थिति में हैं, तो आप PostgreSQL डेटाबेस लॉग में कुछ त्रुटियां देख पाएंगे:

2020-02-20 19:18:18.131 UTC [4400] LOG:  could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on device

या आपके सिस्टम लॉग में भी:

Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]

PostgreSQL केवल-पढ़ने के लिए क्वेरी चलाने के लिए कुछ समय के लिए काम जारी रख सकता है, लेकिन अंततः, यह डिस्क पर लिखने का प्रयास करने में विफल हो जाएगा, फिर आप अपने क्लाइंट सत्र में कुछ इस तरह देखेंगे:

WARNING:  terminating connection because of crash of another server process

DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

HINT:  In a moment you should be able to reconnect to the database and repeat your command.

server closed the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

The connection to the server was lost. Attempting reset: Failed.

फिर, यदि आप डिस्क स्थान पर एक नज़र डालते हैं, तो आपके पास यह अवांछित आउटपुट होगा...

$ df -h

Filesystem                        Size Used Avail Use% Mounted on

/dev/mapper/pve-vm--125--disk--0   30G 30G 0 100% /

PostgreSQL डिस्क स्थान की समस्याओं को कैसे रोकें

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

और डेटाबेस के विकास के लिए भी ऐसा ही:

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

एक चेतावनी प्रणाली के बिना यह सब निगरानी प्रणाली का कोई मतलब नहीं है। जब आपको कार्रवाई करने की आवश्यकता हो:

PostgreSQL डिस्क स्थान की समस्याओं को कैसे ठीक करें

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

आपके डिस्क स्थान का उपभोग क्या कर रहा है?

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

डेटाबेस स्पेस उपयोग

आइए अब आपके डेटाबेस डिस्क स्थान उपयोग की जांच करने के लिए कुछ उपयोगी कमांड देखते हैं।

डेटाबेस स्थान उपयोग की जांच करने का एक मूल तरीका फाइल सिस्टम में डेटा निर्देशिका की जांच कर रहा है:

$ du -sh /var/lib/pgsql/11/data/

819M /var/lib/pgsql/11/data/

या यदि आपके पास अपनी डेटा निर्देशिका के लिए एक अलग विभाजन है, तो आप सीधे df -h का उपयोग कर सकते हैं।

PostgreSQL कमांड "\l+" आकार की जानकारी जोड़ने वाले डेटाबेस को सूचीबद्ध करता है:

$ postgres=# \l+

                                                               List of databases

   Name    | Owner   | Encoding | Collate | Ctype |   Access privileges | Size | Tablespace

|                Description

-----------+----------+-----------+---------+-------+-----------------------+---------+------------

+--------------------------------------------

 postgres  | postgres | SQL_ASCII | C       | C | | 7965 kB | pg_default

| default administrative connection database

 template0 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| unmodifiable empty database

           |          | |         | | postgres=CTc/postgres |         |

|

 template1 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| default template for new databases

           |          | |         | | postgres=CTc/postgres |         |

|

 world     | postgres | SQL_ASCII | C       | C | | 8629 kB | pg_default

|

(4 rows)

pg_database_size और डेटाबेस नाम का उपयोग करके आप डेटाबेस का आकार देख सकते हैं:

postgres=# SELECT pg_database_size('world');

 pg_database_size

------------------

          8835743

(1 row)

और इस मान को मानव-पठनीय तरीके से देखने के लिए pg_size_pretty का उपयोग करना और भी बेहतर हो सकता है:

postgres=# SELECT pg_size_pretty(pg_database_size('world'));

 pg_size_pretty

----------------

 8629 kB

(1 row)

जब आप जानते हैं कि स्थान कहां है, तो आप इसे ठीक करने के लिए संबंधित कार्रवाई कर सकते हैं। ध्यान रखें कि डिस्क स्थान को पुनर्प्राप्त करने के लिए केवल पंक्तियों को हटाना पर्याप्त नहीं है, आपको कार्य समाप्त करने के लिए एक VACUUM या VACUUM FULL चलाने की आवश्यकता होगी।

लॉग फ़ाइलें

डिस्क स्थान को पुनर्प्राप्त करने का सबसे आसान तरीका लॉग फ़ाइलों को हटाना है। आप यह सत्यापित करने के लिए PostgreSQL लॉग निर्देशिका या सिस्टम लॉग की जांच कर सकते हैं कि क्या आप वहां से कुछ स्थान प्राप्त कर सकते हैं। अगर आपके पास ऐसा कुछ है:

$ du -sh /var/lib/pgsql/11/data/log/

18G /var/lib/pgsql/11/data/log/

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

$ ls -lah /var/lib/pgsql/11/data/log/

total 18G

drwx------  2 postgres postgres 4.0K Feb 21 00:00 .

drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..

-rw-------  1 postgres postgres  18G Feb 21 14:46 postgresql-Fri.log

-rw-------  1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log

-rw-------  1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.log

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

$ tail -100 postgresql-Fri.log > /tmp/log_temp.log

और फिर:

$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.log

यदि आप इसे "आरएम" के साथ हटाते हैं और लॉग फ़ाइल का उपयोग पोस्टग्रेएसक्यूएल सर्वर (या अन्य सेवा) द्वारा किया जा रहा है, तो स्थान जारी नहीं किया जाएगा, इसलिए आपको इस बिल्ली का उपयोग करके इस फ़ाइल को छोटा करना चाहिए / इसके बजाय dev/null कमांड।

यह क्रिया केवल PostgreSQL और सिस्टम लॉग फ़ाइलों के लिए है। pg_wal सामग्री या किसी अन्य PostgreSQL फ़ाइल को न हटाएं क्योंकि इससे आपके डेटाबेस को गंभीर क्षति हो सकती है।

ब्लोट

एक सामान्य PostgreSQL ऑपरेशन में, अपडेट द्वारा हटाए गए या अप्रचलित टुपल्स को तालिका से भौतिक रूप से हटाया नहीं जाता है; वे तब तक मौजूद रहते हैं जब तक VACUUM का प्रदर्शन नहीं किया जाता। इसलिए, वैक्यूम को समय-समय पर (AUTOVACUUM) करना आवश्यक है, विशेष रूप से बार-बार अपडेट होने वाली तालिकाओं में।

यहाँ समस्या यह है कि केवल VACUUM का उपयोग करके ऑपरेटिंग सिस्टम में स्थान वापस नहीं किया जाता है, यह केवल उसी तालिका में उपयोग के लिए उपलब्ध है।

VACUUM FULL तालिका को एक नई डिस्क फ़ाइल में फिर से लिखता है, ऑपरेटिंग सिस्टम में अप्रयुक्त स्थान को लौटाता है। दुर्भाग्य से, इसे चलने के दौरान प्रत्येक टेबल पर एक विशेष लॉक की आवश्यकता होती है।

आपको यह देखने के लिए तालिकाओं की जांच करनी चाहिए कि क्या VACUUM (पूर्ण) प्रक्रिया की आवश्यकता है।

प्रतिकृति स्लॉट

यदि आप प्रतिकृति स्लॉट का उपयोग कर रहे हैं, और यह किसी कारण से सक्रिय नहीं है:

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;

 slot_name | slot_type | active

-----------+-----------+--------

 slot1     | physical  | f

(1 row)

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

इसे ठीक करने का तरीका प्रतिकृति को पुनर्प्राप्त करना (यदि संभव हो), या स्लॉट को हटाना है:

postgres=# SELECT pg_drop_replication_slot('slot1');

 pg_drop_replication_slot

--------------------------

(1 row)

इसलिए, WAL फ़ाइलों द्वारा उपयोग किया जाने वाला स्थान रिलीज़ हो जाएगा।

निष्कर्ष

जैसा कि हमने उल्लेख किया है, इस प्रकार के मुद्दों से बचने के लिए निगरानी और अलर्ट सिस्टम महत्वपूर्ण हैं। इस तरह, ClusterControl आपके सिस्टम को चालू रखने, जरूरत पड़ने पर आपको अलार्म भेजने या यहां तक ​​कि आपके डेटाबेस क्लस्टर को काम करने के लिए पुनर्प्राप्ति कार्रवाई करने में मदद कर सकता है। आप विभिन्न डेटाबेस तकनीकों को तैनात/आयात भी कर सकते हैं और यदि आवश्यक हो तो उन्हें बढ़ा सकते हैं।


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. postgresql में nth प्रतिशतक गणना

  2. पैटर्न मिलान का उपयोग करने में त्रुटि PostgreSQL में किसी की तरह नहीं

  3. PostgreSQL डेटाबेस मॉनिटरिंग:मॉनिटर करने के लिए टिप्स

  4. रिटर्निंग को तोड़े बिना ट्रिगर-आधारित इंसर्ट रीडायरेक्शन पोस्टग्रेज करता है

  5. pg_views . पर क्वेरी से अधूरी जानकारी