मैं इन पैच से पहले संक्षेप में इसे स्पष्ट करने का प्रयास करता हूं, आप सभी जानते हैं कि स्टैंडबाय तेजी से और सुरक्षित आपदा वसूली प्राप्त करने में महत्वपूर्ण घटक हैं। PostgreSQL में, पुनर्प्राप्ति अवधारणा मुख्य रूप से PITR से पहले और बाद में WAL खंडों की एक श्रृंखला की पहचान करने या WAL खंडों के अतिव्यापी होने से बचने के लिए स्टैंडबाय को बढ़ावा देने के लिए समय-सीमा से संबंधित है। टाइमलाइन आईडी वाल सेगमेंट फ़ाइल नामों के साथ जुड़ा हुआ है (उदाहरण:- $PGDATA/pg_xlog/0000000C000000020000009E सेगमेंट में "0000000C" टाइमलाइन आईडी है)। स्ट्रीमिंग प्रतिकृति में प्राइमरी और स्लेव दोनों एक ही टाइमलाइन आईडी का पालन करेंगे, हालांकि जब स्टैंडबाय को स्विचओवर द्वारा नए मास्टर के रूप में पदोन्नति मिलती है तो यह टाइमलाइन आईडी को टक्कर देता है और पुराना प्राइमरी टाइमलाइन आईडी अंतर के कारण स्टैंडबाय के रूप में पुनरारंभ करने से इनकार करता है और त्रुटि संदेश को इस प्रकार फेंकता है:
FATAL: requested timeline 10 is not a child of this server's history
DETAIL: Latest checkpoint is at 2/9A000028 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2/99017E68.
इस प्रकार, एक नया स्टैंडबाय खरोंच से बनाया जाना है, यदि डेटाबेस का आकार बहुत बड़ा है तो पुनर्निर्माण के लिए एक लंबा समय है और इस अवधि के लिए नए पदोन्नत प्राथमिक स्टैंडबाय के बिना चलेंगे। अन्य समस्याएँ भी हैं, जैसे, जब स्विचओवर होता है तो प्राइमरी क्लीन शटडाउन करता है, वॉल्सेंडर प्रक्रिया सभी बकाया WAL रिकॉर्ड्स को स्टैंडबाय पर भेजती है, लेकिन यह बाहर निकलने से पहले उनके दोहराए जाने की प्रतीक्षा नहीं करता है। Walreceiver उन बकाया WAL रिकॉर्ड को लागू करने में विफल रहता है क्योंकि यह कनेक्शन के बंद होने और बाहर निकलने का पता लगाता है।
आज, PostgreSQL 9.3 में दो प्रमुख सॉफ़्टवेयर अपडेट के साथ, दोनों मुद्दों को लेखकों द्वारा बहुत अच्छी तरह से संबोधित किया गया है और अब स्ट्रीमिंग प्रतिकृति स्टैंडबाय लगातार एक टाइमलाइन स्विच का पालन करता है। अब हम मूल रूप से और बिना दर्द के प्राथमिक और स्टैंडबाय के बीच कर्तव्यों को केवल पुनरारंभ करके और स्टैंडबाय के पुनर्निर्माण समय को कम करके बदल सकते हैं।
नोट:स्विचओवर/स्विचबैक संभव नहीं है यदि वाल आर्काइव्स दोनों सर्वरों तक पहुंच योग्य नहीं हैं और स्विचओवर प्रक्रिया में प्राथमिक डेटाबेस को क्लीन शटडाउन (सामान्य या तेज मोड) करना चाहिए।
डेमो करने के लिए, स्ट्रीमिंग प्रतिकृति (सेटअप एसआर के लिए विकी) के सेटअप के साथ शुरू करते हैं, जिसे मैंने अपने स्थानीय वीएम में दो समूहों (5432 प्राथमिक और 5433 स्टैंडबाय के रूप में) के बीच एक सामान्य वाल अभिलेखागार स्थान साझा करते हुए कॉन्फ़िगर किया है, क्योंकि दोनों समूहों की पूरी पहुंच होनी चाहिए वाल अभिलेखागार के अनुक्रम का। अवधारणा की बेहतर समझ के लिए सेटअप विवरण और वर्तमान टाइमलाइन आईडी के साथ नीचे साझा किए गए स्नैपशॉट को देखें।
इस स्तर पर सभी को एक ठोस समझ होनी चाहिए कि स्विचओवर और स्विचबैक नियोजित गतिविधियाँ हैं। अब एसआर सेटअप की जगह हम प्राथमिक और स्टैंडबाय के कर्तव्यों का आदान-प्रदान कर सकते हैं जैसा कि नीचे दिखाया गया है:
स्विचओवर चरण:
चरण 1. प्राइमरी का क्लीन शटडाउन करें[5432] (-एम फास्ट या स्मार्ट)
[postgres@localhost:/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data stop -mf
waiting for server to shut down.... done
server stopped
चरण 2. स्टैंडबाय का प्रचार करने से पहले सिंक स्थिति और स्टैंडबाय की पुनर्प्राप्ति स्थिति की जांच करें[5433]:
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c 'select pg_last_xlog_receive_location() "receive_location",
pg_last_xlog_replay_location() "replay_location",
pg_is_in_recovery() "recovery_status";'
receive_location | replay_location | recovery_status
------------------+-----------------+-----------------
2/9F000A20 | 2/9F000A20 | t
(1 row)
पूर्ण सिंक में स्टैंडबाय। इस स्तर पर हम इसे प्राथमिक के रूप में प्रचारित करने के लिए सुरक्षित हैं।
चरण 3। pg_ctl प्रचार या ट्रिगर फ़ाइल बनाकर स्टैंडबाय को नए प्राथमिक के रूप में खोलें।
[postgres@localhost:/opt/PostgreSQL/9.3~]$ grep trigger_file data_slave/recovery.conf
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_down.txt
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
In Logs:
2014-12-29 00:16:04 PST-26344-- [host=] LOG: trigger file found: /tmp/primary_down.txt
2014-12-29 00:16:04 PST-26344-- [host=] LOG: redo done at 2/A0000028
2014-12-29 00:16:04 PST-26344-- [host=] LOG: selected new timeline ID: 14
2014-12-29 00:16:04 PST-26344-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:16:04 PST-26344-- [host=] LOG: archive recovery complete
2014-12-29 00:16:04 PST-26342-- [host=] LOG: database system is ready to accept connections
2014-12-29 00:16:04 PST-31874-- [host=] LOG: autovacuum launcher started
स्टैंडबाय को मास्टर के रूप में प्रचारित किया गया है और एक नई टाइमलाइन का अनुसरण किया गया है जिसे आप लॉग में देख सकते हैं।
चरण 4. पुराने प्राथमिक को स्टैंडबाय के रूप में पुनरारंभ करें और $PGDATA/recovery.conf फ़ाइल में "recovery_target_timline='latest'" पास करके नई टाइमलाइन का पालन करने की अनुमति दें।
[postgres@localhost:/opt/PostgreSQL/9.3~]$ cat data/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5433 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_131_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data start
server starting
यदि आप पुनर्प्राप्ति के माध्यम से जाते हैं। conf यह बहुत स्पष्ट है कि पुराना प्राथमिक 5433 पोर्ट से नए स्टैंडबाय के रूप में कनेक्ट करने का प्रयास कर रहा है जो सामान्य वाल अभिलेखागार स्थान की ओर इशारा करता है और शुरू होता है।
In Logs:
2014-12-29 00:21:17 PST-32315-- [host=] LOG: database system was shut down at 2014-12-29 00:12:23 PST
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: entering standby mode
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D00000002000000A0" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: consistent recovery state reached at 2/A0000090
2014-12-29 00:21:17 PST-32315-- [host=] LOG: record with zero length at 2/A0000090
2014-12-29 00:21:17 PST-32310-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:21:17 PST-32325-- [host=] LOG: started streaming WAL from primary at 2/A0000000 on timeline 14
चरण 5. नई स्टैंडबाय स्थिति सत्यापित करें।
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)
बढ़िया, बिना किसी री-सेटअप के हम पुराने प्राइमरी को नए स्टैंडबाय के रूप में वापस लाए हैं।
स्विचबैक चरण:
चरण 1. नए प्राथमिक [5433] का क्लीन शटडाउन करें:
[postgres@localhost:/opt/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave stop -mf
waiting for server to shut down.... done
server stopped
चरण 2. प्रचार करने से पहले नए स्टैंडबाय [5432] की सिंक स्थिति की जांच करें।
चरण 3. ट्रिगर फ़ाइल या pg_ctl बढ़ावा देकर नया स्टैंडबाय [5432] प्राथमिक के रूप में खोलें।
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt
चरण 4. नए प्राथमिक [5433] को नए स्टैंडबाय के रूप में पुनरारंभ करें।
[postgres@localhost:/opt/PostgreSQL/9.3~]$ more data_slave/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5432 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave start
server starting
आप नए स्टैंडबाय के लॉग सत्यापित कर सकते हैं।
In logs:
[postgres@localhost:/opt/PostgreSQL/9.3/data_slave/pg_log~]$ more postgresql-2014-12-29_003655.log
2014-12-29 00:36:55 PST-919-- [host=] LOG: database system was shut down at 2014-12-29 00:34:01 PST
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: entering standby mode
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E00000002000000A1" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: consistent recovery state reached at 2/A1000090
2014-12-29 00:36:55 PST-919-- [host=] LOG: record with zero length at 2/A1000090
2014-12-29 00:36:55 PST-914-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:36:55 PST-929-- [host=] LOG: started streaming WAL from primary at 2/A1000000 on timeline 15
2014-12-29 00:36:56 PST-919-- [host=] LOG: redo starts at 2/A1000090
बहुत बढ़िया, बिना अधिक समय के हमने प्राइमरी और स्टैंडबाय सर्वरों के कर्तव्यों को बदल दिया है। आप प्रत्येक प्रचार के लिए लॉग से टाइमलाइन आईडी की वृद्धि भी देख सकते हैं।
दूसरों की तरह मेरी सभी पोस्ट ज्ञान साझा करने का हिस्सा हैं, किसी भी टिप्पणी या सुधार का स्वागत है।
