PostgreSQL 9 में प्रतिकृति के लिए वॉचडॉग

नमस्ते। मैं एक स्व-निर्मित बैसाखी साझा करना चाहता हूं, शायद कोई उपयोगी होगा।

मुख्य बात के बारे में संक्षेप में

हम स्थिति का अनुकरण करते हैं: पोस्टग्रेएसक्यूएल-सर्वर का एक क्लस्टर है - एक मास्टर और एन-प्रतिकृतियां। एक बारिश का दिन आता है और एक (या कई) प्रतिकृतियां गिरती हैं। कारण महत्वहीन हैं - लोहे का टुकड़ा मर गया, क्लीनर ने एक एमओपी के साथ तार को तोड़ दिया या यूएफओ ने अस्थायी रूप से सर्वर को बर्बाद कर दिया। परिणाम एक है - यदि प्रतिकृति लंबे समय तक लेटी रहती है, तो वह खुद कभी भी पकड़ नहीं पाएगी।

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

cp %p /var/lib/postgresql/9.0/main/archive/%f

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

यह कैसे काम करता है

master01:~# ps aux|grep postg|grep sender
postgres 26132 0.0 0.0 6518660 3052 ? Ss 20:21 0:01 postgres: wal sender process postgres 192.168.12.1(36254) streaming 153/ED957E68
postgres 26133 0.0 0.0 6518660 3056 ? Ss 20:21 0:01 postgres: wal sender process postgres 192.168.12.2(51907) streaming 153/ED957E68
postgres 26135 0.0 0.0 6518660 3060 ? Ss 20:21 0:01 postgres: wal sender process postgres 192.168.12.3(39404) streaming 153/ED957E68
postgres 29142 0.0 0.0 6518724 3084 ? Ss 20:44 0:01 postgres: wal sender process postgres 192.168.12.4(51897) streaming 153/ED957E68
postgres 29320 0.0 0.0 6518724 3084 ? Ss 20:45 0:01 postgres: wal sender process postgres 192.168.12.5(49234) streaming 153/ED957E68
postgres 29453 0.0 0.0 6518724 3084 ? Ss 20:46 0:01 postgres: wal sender process postgres 192.168.12.6(35519) streaming 153/ED957E68


जैसा कि हम इस सरल आदेश से देख सकते हैं - प्रक्रियाओं की सूची में आप पा सकते हैं:
1. जुड़े हुए प्रतिकृतियों की संख्या, उनके आईपी-पते को दर्शाता है।
2. XLOG का एक टुकड़ा जिसे वे वर्तमान में प्रोसेस कर रहे हैं।

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

और प्रक्रियाओं की सूची में आप यह पा सकते हैं:

master01:~# ps aux|grep postg|grep arch
postgres 556 0.0 0.0 66184 1668 ? Ss Oct11 0:23 postgres: archiver process last was 0000000100000153000000EB

पंक्ति का अंतिम भाग वह फ़ाइल है जिसे संग्रहीत किया गया था। हम अंतिम 13 अक्षर लेते हैं, उन्हें एक पंक्ति में 6 शून्य से हटाते हैं। 153EB प्राप्त करें।

हम प्राप्त संख्याओं को दशमलव (स्पष्टता के लिए) में बदल देते हैं, हमें 87021 और 87019 मिलते हैं। इन दोनों संख्याओं की तुलना करने पर, हमें पता चलता है कि प्रतिकृति एक लॉग का उपयोग करती है, जो कि पिछले संग्रहित से 2 कदम पुराना है - इसलिए, हम सुरक्षित रूप से एक टुकड़े कर सकते हैं।

इन सरल जोड़तोड़ों के आधार पर, मेरी स्क्रिप्ट काम करती है:

1. व्यवस्थापक /etc/postgresql/9.0/main/slaves.list में प्रतिकृतियों की एक सूची (प्रति पंक्ति) जोड़ता है।
2. स्क्रिप्ट PostgreSQL कॉन्फिगरेशन में आर्काइव_कमांड के रूप में फिट होती है।
3. जब आप XLOG के एक टुकड़े को संग्रहीत करने का प्रयास करते हैं, तो निम्न होता है:
3.1। यह जाँच की जाती है कि कनेक्टेड प्रतिकृतियों की संख्या विन्यास में निर्दिष्ट संख्या से मेल खाती है या नहीं।
3.2। यदि सब कुछ ठीक है, तो हम यह देखना चाहते हैं कि होस्ट कॉन्फ़िगर में निर्दिष्ट लोगों के अनुरूप हैं या नहीं (यदि हम क्लस्टर का विस्तार करते समय कॉन्फ़िगरेशन के लिए एक नया प्रतिकृति लिखना भूल जाते हैं)।
3.3। हम प्रतिकृतियों के बीच न्यूनतम XLOG स्थिति की गणना करते हैं (हम सबसे ज्यादा पिछड़ रहे हैं)।
3.4। फ़ाइल के नाम से प्राप्त संख्याओं की तुलना करें और पिछले पैराग्राफ की संख्या से।

यदि सभी शर्तें पूरी हो जाती हैं - फ़ाइल को संग्रह में कॉपी करें और 0. वापस करें। यदि कुछ गलत हुआ है - तो एक लौटाएं - PostgreSQL प्रयास को असफल मान लेगा और थोड़ी देर बाद अगले को ले जाएगा। आप /var/log/postgresql/9.0/watchdog.log में प्रक्रिया की निगरानी कर सकते हैं

आक्टंग! यह समझा जाता है कि प्रतिकृतियों की सूची मौजूदा DNS रिकॉर्ड (व्यक्तिगत सुविधा के लिए बनाई गई), या स्थानीय रूप से / etc / होस्ट्स में निर्दिष्ट नामों को इंगित करेगी। इसे अक्षम करने के लिए, आपको 55 के माध्यम से 47 लाइनों पर टिप्पणी करने की आवश्यकता है।