आईएमओ, प्रमुख संस्करण उन्नयन करते समय एक उचित फॉलबैक योजना होनी चाहिए क्योंकि अगर आवेदन बग्गी में बदल जाता है या उन्नत संस्करण पर अच्छा प्रदर्शन करने में विफल रहता है, तो हमें तुरंत पुराने संस्करण में रोलबैक करने में सक्षम होना चाहिए। Slony-I स्विचबैक के रूप में ऐसी कार्यक्षमता प्रदान करता है। यह पोस्ट स्विचओवर/स्विचबैक चरणों सहित न्यूनतम डाउनटाइम अपग्रेडेशन को प्रदर्शित करता है।
डेमो पर जाने से पहले, ध्यान देने योग्य एक महत्वपूर्ण कदम, पहले PG 9.0.x संस्करण bytea डेटाटाइप कॉलम डेटा को ESCAPE प्रारूप में संग्रहीत करने के लिए उपयोग करते हैं और बाद में इसे HEX प्रारूप में संस्करणित करते हैं। स्विचबैक (पुराने संस्करण में नया संस्करण) करते समय, इस प्रकार के बाइटा प्रारूप अंतर स्लोनी-आई द्वारा समर्थित नहीं हैं, इसलिए ESCAPE प्रारूप को अपग्रेड अवधि के दौरान बनाए रखा जाना चाहिए, अन्यथा आप एक त्रुटि का सामना कर सकते हैं:
ERROR remoteWorkerThread_1_1: error at end of COPY IN: ERROR: invalid input syntax for type bytea
CONTEXT: COPY sl_log_1, line 1: "1 991380 1 100001 public foo I 0 {id,500003,name,"A ",b,"\\x41"}"
ERROR remoteWorkerThread_1: SYNC aborted
ठीक करने के लिए, PG 8.4.x पर लेकिन PG 9.3.5 bytea_output पैरामीटर पर किसी भी बदलाव की आवश्यकता नहीं है, जैसा कि दिखाया गया है HEX से ESCAPE पर सेट किया जाना चाहिए। हम इसे क्लस्टर-स्तर ($PGDATA/postgresql.conf) या उपयोगकर्ता-स्तर (ALTER TABLE…SET) पर सेट कर सकते हैं, मैंने उपयोगकर्ता-स्तर के परिवर्तनों के साथ जाना पसंद किया है।
slavedb=# alter user postgres set bytea_output to escape;
ALTER ROLE
आइए अपग्रेड चरणों के साथ आगे बढ़ें। इस डेमो में उपयोग किए गए मेरे दो संस्करण सर्वर विवरण नीचे दिए गए हैं, यदि आप कोशिश कर रहे हैं तो इसे अपने सर्वर सेटअप के अनुसार बदलें:
Origin Node (Master/Primary are called as Origin) Subscriber Node (Slave/Secondary are called as Subscriber)
------------------------------------------------- ----------------------------------------------------------
Host IP : 192.168.22.130 192.168.22.131
OS Version : RHEL 6.5 64 bit RHEL 6.5 64 bit
PG Version : 8.4.22 (5432 Port) 9.3.5 (5432 Port)
Slony Vers. : 2.2.2 2.2.2
PG Binaries : /usr/local/pg84/bin /opt/PostgreSQL/9.3/
Database : masterdb slavedb
PK Table : foo(id int primary key, name char(20), image bytea) ...restore PK tables structure from Origin...
सरल समझ और आसान कार्यान्वयन के लिए, मैंने डेमो को तीन खंडों में विभाजित किया है
1. PostgreSQL संस्करणों के विरुद्ध Slony-I बायनेरिज़ के लिए संकलन2। प्रतिकृति स्क्रिप्ट बनाना और क्रियान्वित करना
3. परीक्षण स्विचओवर/स्विचबैक।
1. PostgreSQL संस्करण के विरुद्ध Slony-I बायनेरिज़ के लिए संकलन
यहां से Slony-I स्रोत डाउनलोड करें, और ओरिजिन और सब्सक्राइबर नोड्स पर PostgreSQL बायनेरिज़ के विरुद्ध सोर्स इंस्टॉलेशन करें।
On Origin Node:
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgbindir=/usr/local/pg84/bin
--with-pglibdir=/usr/local/pg84/lib
--with-pgincludedir=/usr/local/pg84/include
--with-pgpkglibdir=/usr/local/pg84/lib/postgresql
--with-pgincludeserverdir=/usr/local/pg84/include/postgresql/
make
make install
On Subscriber Node: (assuming PG 9.3.5 installed)
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgconfigdir=/opt/PostgreSQL/9.3/bin
--with-pgbindir=/opt/PostgreSQL/9.3/bin
--with-pglibdir=/opt/PostgreSQL/9.3/lib
--with-pgincludedir=/opt/PostgreSQL/9.3/include
--with-pgpkglibdir=/opt/PostgreSQL/9.3/lib/postgresql
--with-pgincludeserverdir=/opt/PostgreSQL/9.3/include/postgresql/server/
--with-pgsharedir=/opt/PostgreSQL/9.3/share
make
make install
2. प्रतिकृति स्क्रिप्ट बनाना और क्रियान्वित करना
प्रतिकृति सेटअप करने के लिए, हमें कुछ ऐसी स्क्रिप्ट बनाने की आवश्यकता है जो स्विचओवर/स्विचबैक सहित प्रतिकृति का ध्यान रखें।
1. इनिशियलाइज़.स्लोनिक - इस स्क्रिप्ट में ओरिजिन/सब्सक्राइबर नोड कनेक्शन की जानकारी होती है।
2. create_set.slonik - इस स्क्रिप्ट में सभी ओरिजिन पीके टेबल्स हैं जो सब्सक्राइबर नोड को दोहराते हैं।
3. subscribe_set.slonik - यह स्क्रिप्ट सेट डेटा को सब्सक्राइबर नोड में दोहराना शुरू कर देती है।
4. switchover.slonik - यह स्क्रिप्ट मूल से सब्सक्राइबर तक नियंत्रण स्थानांतरित करने में मदद करती है।
5. switchback.slonik - यह स्क्रिप्ट सब्सक्राइबर से ओरिजिन तक फॉलबैक कंट्रोल करने में मदद करती है।
अंत में, दो और स्टार्टअप स्क्रिप्ट “start_OriginNode.sh” और “start_SubscriberNode.sh” जो ओरिजिन/सब्सक्राइबर नोड्स पर संकलित बायनेरिज़ के अनुसार स्लोन प्रक्रिया शुरू करता है।
यहां से सभी स्क्रिप्ट डाउनलोड करें।
यहां फू टेबल में ओरिजिन नोड (8.4.22) पर बाइटिया डेटाटाइप के एक कॉलम के साथ नमूना डेटा है, जिसे हम बनाई गई स्क्रिप्ट की मदद से सब्सक्राइबर नोड (9.3.5) में दोहराएंगे।
masterdb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)
प्रतिकृति सेटअप करने के लिए स्क्रिप्ट को एक-एक करके कॉल करें। याद रखें कि "start_OriginNode.sh" और "start_SubscriberNode.sh" को छोड़कर सभी स्लोनिक स्क्रिप्ट को केवल मूल नोड पर निष्पादित किया जाना चाहिए, जिसे व्यक्तिगत रूप से निष्पादित किया जाना चाहिए।
-bash-4.1$ slonik initalize.slonik
-bash-4.1$ slonik create_set.slonik
create_set.slonik:13: Set 1 ...created
create_set.slonik:16: PKey table *** public.foo *** added.
-bash-4.1$ sh start_OriginNode.sh
-bash-4.1$ sh start_SubscriberNode.sh //ON SUBSCRIBER NODE
-bash-4.1$ slonik subscribe_set.slonik
उपरोक्त स्क्रिप्ट के सफल निष्पादन के बाद, आप देख सकते हैं कि उत्पत्ति (मास्टरडीबी) पर डेटा सब्सक्राइबर (स्लेवडब) में दोहराया गया है। साथ ही सब्सक्राइबर नोड पर किसी भी डीएमएल संचालन की अनुमति नहीं देना:
slavedb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)
slavedb=# insert into foo values (4,'PG-Experts','Image2');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
बढ़िया… हमने डेटा को PostgreSQL 9.3.5 के नए संस्करण में स्थानांतरित कर दिया है। इस स्तर पर यदि आपको लगता है कि सभी डेटा सब्सक्राइबर नोड में दोहराया गया है, तो आप स्विचओवर कर सकते हैं।
3. परीक्षण स्विचओवर/स्विचबैक।
आइए स्क्रिप्ट के साथ नवीनतम संस्करण पर स्विच करें और सब्सक्राइबर/ओरिजिन नोड्स पर डेटा डालने का प्रयास करें।
-bash-4.1$ slonik switchover.slonik
switchover.slonik:8: Set 1 has been moved from Node 1 to Node 2
slavedb=# insert into foo values (4,'PG-Experts','Image2');
INSERT 0 1
masterdb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
(4 rows)
masterdb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
बिल्कुल सही ... यह वही है जो हम देख रहे हैं, अब स्लेवडब (सब्सक्राइबर नोड) पीजी 9.3.5 संस्करण चला रहा है जो डेटा स्वीकार करता है और मास्टरडब (ओरिजिन नोड) स्लेवडब डेटा प्राप्त करता है। इसके अलावा मास्टरडीबी पर निष्पादित डीएमएल को खारिज कर दिया।
Slony-I लॉग्स स्विचओवर के समय मूल/सब्सक्राइबर नोड आईडी मूवमेंट दिखाता है:
2014-12-12 04:55:06 PST CONFIG moveSet: set_id=1 old_origin=1 new_origin=2
2014-12-12 04:55:06 PST CONFIG storeListen: li_origin=1 li_receiver=2 li_provider=1
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: update provider configuration
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: helper thread for provider 1 terminated
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: disconnecting from data provider 1
...
...
2014-12-12 04:55:11 PST INFO start processing ACCEPT_SET
2014-12-12 04:55:11 PST INFO ACCEPT: set=1
2014-12-12 04:55:11 PST INFO ACCEPT: old origin=1
2014-12-12 04:55:11 PST INFO ACCEPT: new origin=2
2014-12-12 04:55:11 PST INFO ACCEPT: move set seq=5000006393
2014-12-12 04:55:11 PST INFO got parms ACCEPT_SET
यदि आपको इस स्तर पर कोई समस्या आती है, तो आप पुराने संस्करण पर वापस जा सकते हैं। स्विचबैक के बाद आप अपने आवेदन या अन्य मुद्दों के ठीक होने तक पुराने संस्करण के साथ जारी रख सकते हैं। स्विचओवर के बाद समस्याओं के मामले में अधिक समय बर्बाद किए बिना यह एकदम सही रोलबैक योजना है..
-bash-4.1$ slonik switchback.slonik
switchback.slonik:8: Set 1 has been moved from Node 2 to Node 1
slavedb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0
masterdb=# insert into foo values (5,'PG-Experts','Image3');
INSERT 0 1
slavedb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
5 | PG-Experts | Image3
(5 rows)
बहुत अच्छा…!!! क्या यह न्यूनतम डाउनटाइम के साथ सटीक रोलबैक नहीं है? हां, यह बिना लेन-देन खोए नोड्स के बीच एकदम सही स्विचिंग है।
सब्सक्राइबर से ओरिजिन नोड में स्विचबैक दिखाने वाले लॉग:
2014-12-12 04:58:45 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
2014-12-12 04:58:45 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: update provider configuration
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: helper thread for provider 2 terminated
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: disconnecting from data provider 2
2014-12-12 04:58:46 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
...
...
2014-12-12 04:58:47 PST INFO start processing ACCEPT_SET
2014-12-12 04:58:47 PST INFO ACCEPT: set=1
2014-12-12 04:58:47 PST INFO ACCEPT: old origin=2
2014-12-12 04:58:47 PST INFO ACCEPT: new origin=1
2014-12-12 04:58:47 PST INFO ACCEPT: move set seq=5000006403
2014-12-12 04:58:47 PST INFO got parms ACCEPT_SET
2014-12-12 04:58:48 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
इस समय तक आपने देखा होगा कि PostgreSQL संस्करणों के बीच स्विचिंग ऑपरेशन के दौरान कोई भी लेन-देन खो नहीं गया है। ओरिजिन और सब्सक्राइबर नोड्स से कनेक्ट करने के लिए केवल डाउनटाइम ही आपका एप्लिकेशन स्टार्ट/स्टॉप हो सकता है, लेकिन ओरिजिन/सब्सक्राइबर नोड्स को कभी भी डाउन नहीं किया जाता है, वे बस ऊपर और चल रहे हैं।
याद रखें, यहां दिखाया गया तरीका न केवल अपग्रेड के लिए उपयोगी है बल्कि नोड्स के बीच जाने के लिए Slony-I में भी यही तरीका है।
आपके धैर्य के लिए धन्यवाद :)। आशा है कि यह पोस्ट आपको उचित रोलबैक योजना सहित Slony-I का उपयोग करके PostgreSQL को न्यूनतम डाउनटाइम के साथ अपग्रेड करने में मदद करेगी।
