अगर आपका पोस्टग्रेएसक्यूएल प्रतिकृति पिछड़ रहा है तो क्या देखना है

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

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

PostgreSQL में प्रतिकृति के प्रकार

विषय में गोता लगाने से पहले, आइए पहले देखें कि PostgreSQL में प्रतिकृति कैसे विकसित होती है क्योंकि प्रतिकृति से निपटने के लिए विभिन्न दृष्टिकोण और समाधान होते हैं।

पोस्टग्रेएसक्यूएल के लिए वार्म स्टैंडबाय संस्करण 8.2 (2006 में वापस) में लागू किया गया था और यह लॉग शिपिंग विधि पर आधारित था। इसका मतलब यह है कि WAL रिकॉर्ड्स को लागू करने के लिए सीधे एक डेटाबेस सर्वर से दूसरे डेटाबेस सर्वर पर ले जाया जाता है, या बस PITR के समान दृष्टिकोण, या बहुत कुछ वैसा ही जैसा आप rsync के साथ कर रहे हैं।

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

PostgreSQL संस्करण 9.0 में, स्ट्रीमिंग प्रतिकृति पेश की गई थी। फ़ाइल-आधारित लॉग शिपिंग की तुलना में इस सुविधा ने हमें अधिक अद्यतित रहने की अनुमति दी। इसका दृष्टिकोण एक मास्टर सर्वर और एक या कई स्टैंडबाय सर्वरों के बीच फ्लाई पर (केवल एक रिकॉर्ड आधारित लॉग शिपिंग) WAL रिकॉर्ड (एक WAL फ़ाइल WAL रिकॉर्ड से बना है) को स्थानांतरित करना है। फ़ाइल-आधारित लॉग शिपिंग के विपरीत, इस प्रोटोकॉल को WAL फ़ाइल के भरने की प्रतीक्षा करने की आवश्यकता नहीं है। व्यवहार में, स्टैंडबाय सर्वर पर चलने वाली WAL रिसीवर नामक एक प्रक्रिया, TCP/IP कनेक्शन का उपयोग करके प्राथमिक सर्वर से कनेक्ट होगी। प्राथमिक सर्वर में, एक अन्य प्रक्रिया मौजूद है जिसका नाम WAL प्रेषक है। यह WAL रजिस्ट्रियों को स्टैंडबाय सर्वर (एस) पर भेजने के प्रभारी के रूप में होता है।

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

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

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

PostgreSQL प्रतिकृति अंतराल के कारण

जैसा कि हमारे पिछले ब्लॉग में परिभाषित किया गया है, एक प्रतिकृति अंतराल लेन-देन (ओं) या संचालन (ओं) के लिए देरी की लागत है, जिसकी गणना स्टैंडबाय/स्लेव के खिलाफ प्राथमिक/मास्टर के बीच निष्पादन के समय के अंतर से की जाती है। नोड.

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

नेटवर्क की समस्याएं
प्राथमिक से WAL खंड खोजने में सक्षम नहीं है। आमतौर पर, यह चेकपॉइंटिंग व्यवहार के कारण होता है जहां वाल सेगमेंट घुमाए जाते हैं या पुनर्नवीनीकरण होते हैं
व्यस्त नोड्स (प्राथमिक और स्टैंडबाय)। बाहरी प्रक्रियाओं या संसाधन गहन होने के कारण कुछ खराब प्रश्नों के कारण हो सकता है
खराब हार्डवेयर या हार्डवेयर की समस्या के कारण कुछ देर हो रही है
पोस्टग्रेएसक्यूएल में खराब कॉन्फ़िगरेशन जैसे कि टन लेनदेन अनुरोधों (या बड़ी मात्रा में परिवर्तन) को संसाधित करते समय max_wal_senders की छोटी संख्या सेट की जा रही है।

PostgreSQL प्रतिकृति अंतराल के साथ क्या देखना है

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

pg_stat_replication View का उपयोग करना

प्राथमिक नोड में इस दृश्य को संदर्भित करने वाली क्वेरी को चलाना सबसे आम तरीका है। याद रखें, आप इस दृश्य का उपयोग करके केवल प्राथमिक नोड से जानकारी प्राप्त कर सकते हैं। इस दृश्य में निम्न तालिका परिभाषा शामिल है जो PostgreSQL 11 पर आधारित है जैसा कि नीचे दिखाया गया है:

postgres=# \d pg_stat_replication

                    View "pg_catalog.pg_stat_replication"

      Column      | Type           | Collation | Nullable | Default 

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

 pid              | integer           | | | 

 usesysid         | oid           | | | 

 usename          | name           | | | 

 application_name | text                     | | | 

 client_addr      | inet           | | | 

 client_hostname  | text           | | | 

 client_port      | integer           | | | 

 backend_start    | timestamp with time zone |           | | 

 backend_xmin     | xid           | | | 

 state            | text           | | | 

 sent_lsn         | pg_lsn           | | | 

 write_lsn        | pg_lsn           | | | 

 flush_lsn        | pg_lsn           | | | 

 replay_lsn       | pg_lsn           | | | 

 write_lag        | interval           | | | 

 flush_lag        | interval           | | | 

 replay_lag       | interval           | | | 

 sync_priority    | integer           | | | 

 sync_state       | text           | | |

जहां फ़ील्ड को इस प्रकार परिभाषित किया गया है (पीजी <10 संस्करण शामिल है),

पिड :वॉल्सेंडर प्रक्रिया की प्रक्रिया आईडी
usesysid :उपयोगकर्ता का OID जो स्ट्रीमिंग प्रतिकृति के लिए उपयोग किया जाता है।
उपयोगकर्ता नाम :उपयोगकर्ता का नाम जिसका उपयोग स्ट्रीमिंग प्रतिकृति के लिए किया जाता है
application_name :आवेदन का नाम मास्टर से जुड़ा है
client_addr :स्टैंडबाय/स्ट्रीमिंग प्रतिकृति का पता
क्लाइंट_होस्टनाम :स्टैंडबाय का होस्टनाम।
क्लाइंट_पोर्ट :टीसीपी पोर्ट नंबर जिस पर स्टैंडबाय वाल प्रेषक के साथ संचार कर रहा है
बैकएंड_स्टार्ट :प्रारंभ समय जब SR मास्टर से जुड़ा।
बैकएंड_एक्समिन :स्टैंडबाय का xmin क्षितिज hot_standby_feedback द्वारा रिपोर्ट किया गया।
राज्य :वर्तमान WAL प्रेषक स्थिति अर्थात स्ट्रीमिंग
send_lsn /भेजे गए_स्थान :अंतिम लेन-देन स्थान स्टैंडबाय को भेजा गया।
लिखें_एलएसएन /लेखन_स्थान :स्टैंडबाय पर डिस्क पर लिखा गया अंतिम लेनदेन
flush_lsn /flush_location :स्टैंडबाय पर डिस्क पर अंतिम लेनदेन फ्लश।
replay_lsn /रीप्ले_लोकेशन :स्टैंडबाय पर डिस्क पर अंतिम लेनदेन फ्लश।
लिखें_लैग :प्राथमिक से स्टैंडबाय तक प्रतिबद्ध WALs के दौरान बीता हुआ समय (लेकिन अभी तक स्टैंडबाय में प्रतिबद्ध नहीं है)
flush_lag :प्राथमिक से स्टैंडबाय तक प्रतिबद्ध WALs के दौरान बीता हुआ समय (WAL को पहले ही फ्लश कर दिया गया है लेकिन अभी तक लागू नहीं किया गया है)
replay_lag :प्राथमिक से स्टैंडबाय तक प्रतिबद्ध WALs के दौरान बीता हुआ समय (स्टैंडबाय नोड में पूरी तरह से प्रतिबद्ध)
sync_priority :स्टैंडबाय सर्वर को सिंक्रोनस स्टैंडबाय के रूप में चुनने की प्राथमिकता
sync_state :स्टैंडबाय की सिंक स्थिति (क्या यह एसिंक या सिंक्रोनस है)।

एक नमूना क्वेरी PostgreSQL 9.6 में इस प्रकार दिखाई देगी,

paultest=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid              | 7174

usesysid         | 16385

usename          | cmon_replication

application_name | pgsql_1_node_1

client_addr      | 192.168.30.30

client_hostname  | 

client_port      | 10580

backend_start    | 2020-02-20 18:45:52.892062+00

backend_xmin     | 

state            | streaming

sent_location    | 1/9FD5D78

write_location   | 1/9FD5D78

flush_location   | 1/9FD5D78

replay_location  | 1/9FD5D78

sync_priority    | 0

sync_state       | async

-[ RECORD 2 ]----+------------------------------

pid              | 7175

usesysid         | 16385

usename          | cmon_replication

application_name | pgsql_80_node_2

client_addr      | 192.168.30.20

client_hostname  | 

client_port      | 60686

backend_start    | 2020-02-20 18:45:52.899446+00

backend_xmin     | 

state            | streaming

sent_location    | 1/9FD5D78

write_location   | 1/9FD5D78

flush_location   | 1/9FD5D78

replay_location  | 1/9FD5D78

sync_priority    | 0

sync_state       | async

यह मूल रूप से आपको बताता है कि WAL सेगमेंट में स्थान के कौन से ब्लॉक लिखे गए हैं, फ़्लश किए गए हैं या लागू किए गए हैं। यह आपको प्रतिकृति स्थिति की एक बारीक अनदेखी प्रदान करता है।

स्टैंडबाय नोड में उपयोग की जाने वाली क्वेरी

स्टैंडबाय नोड में, ऐसे फ़ंक्शन हैं जो समर्थित हैं जिसके लिए आप इसे एक क्वेरी में कम कर सकते हैं और आपको अपने स्टैंडबाय प्रतिकृति के स्वास्थ्य का अवलोकन प्रदान कर सकते हैं। ऐसा करने के लिए, आप नीचे निम्न क्वेरी चला सकते हैं (क्वेरी पीजी संस्करण> 10 पर आधारित है),

postgres=#  select pg_is_in_recovery(),pg_is_wal_replay_paused(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();

-[ RECORD 1 ]-----------------+------------------------------

pg_is_in_recovery             | t

pg_is_wal_replay_paused       | f

pg_last_wal_receive_lsn       | 0/2705BDA0

pg_last_wal_replay_lsn        | 0/2705BDA0

pg_last_xact_replay_timestamp | 2020-02-21 02:18:54.603677+00

पुराने संस्करणों में, आप निम्न क्वेरी का उपयोग कर सकते हैं:

postgres=# select pg_is_in_recovery(),pg_last_xlog_receive_location(), pg_last_xlog_replay_location(), pg_last_xact_replay_timestamp();

-[ RECORD 1 ]-----------------+------------------------------

pg_is_in_recovery             | t

pg_last_xlog_receive_location | 1/9FD6490

pg_last_xlog_replay_location  | 1/9FD6490

pg_last_xact_replay_timestamp | 2020-02-21 08:32:40.485958-06

क्वेरी क्या बताती है? कार्यों को तदनुसार यहां परिभाषित किया गया है,

pg_is_in_recovery ():(बूलियन) सच है अगर रिकवरी अभी भी जारी है।
pg_last_wal_receive_lsn ()/pg_last_xlog_receive_location(): (pg_lsn) आगे लिखने का लॉग स्थान प्राप्त हुआ और प्रतिकृति स्ट्रीमिंग द्वारा डिस्क से समन्वयित किया गया।
pg_last_wal_replay_lsn ()/pg_last_xlog_replay_location(): (pg_lsn) पुनर्प्राप्ति के दौरान अंतिम राइट-फ़ॉरवर्ड लॉग स्थान फिर से चलाया गया। अगर रिकवरी अभी भी जारी है तो यह एकरस रूप से बढ़ जाएगी।
pg_last_xact_replay_timestamp (): (समय क्षेत्र के साथ टाइमस्टैम्प) पुनर्प्राप्ति के दौरान फिर से चलाए गए अंतिम लेनदेन का टाइमस्टैम्प प्राप्त करें।

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

SELECT CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()

THEN 0

ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())

END AS log_delay;

या संस्करणों में PG <10,

SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location()

THEN 0

ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())

END AS log_delay;

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

वाल सेगमेंट की अनुपस्थिति के कारण होने वाले अंतराल की पहचान करना

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

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

चरण 1:निर्धारित करें कि क्या कोई अंतराल है

postgres=# SELECT CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()

postgres-# THEN 0

postgres-# ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())

postgres-# END AS log_delay;

-[ RECORD 1 ]

log_delay | 0

चरण 2:प्राथमिक से प्राप्त WAL सेगमेंट निर्धारित करें और स्टैंडबाय नोड के साथ तुलना करें

## Get the master's current LSN. Run the query below in the master

postgres=# SELECT pg_current_wal_lsn();

-[ RECORD 1 ]------+-----------

pg_current_wal_lsn | 0/925D7E70

PG <10 के पुराने संस्करणों के लिए, pg_current_xlog_location का उपयोग करें।

## Get the current WAL segments received (flushed or applied/replayed)

postgres=# select pg_is_in_recovery(),pg_is_wal_replay_paused(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();

-[ RECORD 1 ]-----------------+------------------------------

pg_is_in_recovery             | t

pg_is_wal_replay_paused       | f

pg_last_wal_receive_lsn       | 0/2705BDA0

pg_last_wal_replay_lsn        | 0/2705BDA0

pg_last_xact_replay_timestamp | 2020-02-21 02:18:54.603677+00

यह बुरा लग रहा है।

चरण 3:निर्धारित करें कि यह कितना बुरा हो सकता है

अब, चरण #1 और चरण #2 में सूत्र को मिलाते हैं और अंतर प्राप्त करते हैं। यह कैसे करें, PostgreSQL में pg_wal_lsn_diff नामक एक फ़ंक्शन है जिसे परिभाषित किया गया है,

pg_wal_lsn_diff(lsn pg_lsn, lsn pg_lsn) / pg_xlog_location_diff (स्थान pg_lsn, स्थान pg_lsn): (संख्यात्मक) दो लिखने-आगे लॉग स्थानों के बीच अंतर की गणना करें

अब, इसका उपयोग अंतराल निर्धारित करने के लिए करते हैं। आप इसे किसी भी PG नोड में चला सकते हैं, क्योंकि हम केवल स्थिर मान प्रदान करेंगे:

postgres=# select pg_wal_lsn_diff('0/925D7E70','0/2705BDA0');                                                                                                                                     -[ RECORD 1 ]---+-----------

pg_wal_lsn_diff | 1800913104

आइए अनुमान लगाते हैं कि 1800913104 कितना है, ऐसा लगता है कि लगभग 1.6GiB स्टैंडबाय नोड में अनुपस्थित रहा होगा,

postgres=# select round(1800913104/pow(1024,3.0),2) missing_lsn_GiB;

-[ RECORD 1 ]---+-----

missing_lsn_gib | 1.68

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

## Primary

[email protected]:/var/lib/postgresql/11/main# tail -5f log/postgresql-2020-02-21_033512.log

2020-02-21 16:44:33.574 UTC [25023] ERROR:  requested WAL segment 000000030000000000000027 has already been removed

...



## Standby

[email protected]:/var/lib/postgresql/11/main# tail -5f log/postgresql-2020-02-21_014137.log 

2020-02-21 16:45:23.599 UTC [26976] LOG:  started streaming WAL from primary at 0/27000000 on timeline 3

2020-02-21 16:45:23.599 UTC [26976] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000030000000000000027 has already been removed

...

इस समस्या का सामना करते समय, अपने स्टैंडबाय नोड्स का पुनर्निर्माण करना बेहतर होता है। ClusterControl में, यह एक क्लिक जितना आसान है। बस नोड्स/टोपोलॉजी सेक्शन में जाएं, और नोड को ठीक नीचे की तरह फिर से बनाएं:

जांच की जाने वाली अन्य चीजें

आप हमारे पिछले ब्लॉग (MySQL में) में ps, top, iostat, netstat संयोजन जैसे सिस्टम टूल्स का उपयोग करके उसी दृष्टिकोण का उपयोग कर सकते हैं। उदाहरण के लिए, आप स्टैंडबाय नोड से वर्तमान पुनर्प्राप्त वाल सेगमेंट भी प्राप्त कर सकते हैं,

[email protected]:/var/lib/postgresql/11/main# ps axufwww|egrep "postgre[s].*startup"

postgres  8065 0.0 8.3 715820 170872 ?       Ss 01:41 0:03 \_ postgres: 11/main: startup   recovering 000000030000000000000027

ClusterControl कैसे मदद कर सकता है?

ClusterControl प्राथमिक से स्लेव नोड्स तक आपके डेटाबेस नोड्स की निगरानी करने का एक प्रभावी तरीका प्रदान करता है। जब आप अवलोकन टैब पर जाते हैं, तो आप पहले से ही अपने प्रतिकृति स्वास्थ्य के बारे में देख सकते हैं:

मूल रूप से, ऊपर दिए गए दो स्क्रीनशॉट प्रदर्शित करते हैं कि प्रतिकृति स्वास्थ्य कैसा है और वर्तमान में क्या है वाल खंड। ऐसा बिल्कुल नहीं है। ClusterControl आपके क्लस्टर के साथ क्या हो रहा है, इसकी वर्तमान गतिविधि भी दिखाता है।

निष्कर्ष

जब तक आप अपनी आवश्यकताओं को पूरा करने में सक्षम होते हैं, तब तक PostgreSQL में प्रतिकृति स्वास्थ्य की निगरानी एक अलग दृष्टिकोण पर समाप्त हो सकती है। अवलोकन के साथ तीसरे पक्ष के उपकरणों का उपयोग करना जो आपको आपदा के मामले में सूचित कर सकते हैं, आपका सही मार्ग है, चाहे वह एक खुला स्रोत हो या उद्यम। सबसे महत्वपूर्ण बात यह है कि इस तरह की परेशानी से पहले आपके पास अपनी आपदा वसूली योजना और व्यापार निरंतरता की योजना है।