व्यापार निरंतरता के लिए PostgreSQL को कॉन्फ़िगर करना

डेटाबेस के लिए व्यावसायिक निरंतरता

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

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

यह सुनिश्चित करने के लिए कि उत्पादन डेटाबेस एक आपदा से बचे, एक डिजास्टर रिकवरी (DR) साइट को कॉन्फ़िगर किया जाना चाहिए। उत्पादन और डीआर साइट दो भौगोलिक दृष्टि से दूर डेटा केंद्रों का हिस्सा होना चाहिए। इसका मतलब है, प्रत्येक उत्पादन डेटाबेस के लिए डीआर साइट पर एक स्टैंडबाय डेटाबेस कॉन्फ़िगर किया जाना चाहिए ताकि, उत्पादन डेटाबेस पर होने वाले डेटा परिवर्तन तुरंत लेनदेन लॉग के माध्यम से स्टैंडबाय डेटाबेस में समन्वयित हो जाएं। यह PostgreSQL में "स्ट्रीमिंग प्रतिकृति" क्षमता द्वारा प्राप्त किया जा सकता है।

अगर आपदा उत्पादन (या प्राथमिक) डेटाबेस को प्रभावित करती है तो क्या होना चाहिए?

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

पोस्टग्रेएसक्यूएल को उच्च उपलब्धता के लिए कॉन्फ़िगर करना

जैसा कि ऊपर कहा गया है, यह सुनिश्चित करने के लिए कि PostgreSQL आपदा वसूली के अनुरूप है, इसे पहले स्ट्रीमिंग प्रतिकृति (मास्टर + स्टैंडबाय डेटाबेस) और स्वचालित स्टैंडबाय प्रचार / विफलता क्षमताओं के साथ कॉन्फ़िगर किया जाना चाहिए। आइए देखें कि पहले स्ट्रीमिंग प्रतिकृति को कैसे कॉन्फ़िगर करें और उसके बाद "विफलता" प्रक्रिया को कैसे कॉन्फ़िगर करें।

स्टैंडबाय डेटाबेस को कॉन्फ़िगर करना (स्ट्रीमिंग प्रतिकृति)

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

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

प्राथमिक डेटाबेस अनिवार्य कॉन्फ़िगरेशन

सुनिश्चित करें कि निम्नलिखित पैरामीटर प्राथमिक डेटाबेस पर postgresql.conf में कॉन्फ़िगर किए गए हैं। निम्नलिखित परिवर्तन करने के लिए डेटाबेस को पुनः आरंभ करने की आवश्यकता होगी।

wal_level=logical

wal_level पैरामीटर सुनिश्चित करता है कि प्रतिकृति के लिए आवश्यक जानकारी WAL फ़ाइलों में लिखी गई है।

max_wal_senders=1 (or any number more than 0)

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

WAL संग्रह सक्षम करें

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

archive_mode=on
archive_command=<archive location>

स्टैंडबाय से कनेक्शन स्वीकार करने के लिए प्राथमिक डेटाबेस को कॉन्फ़िगर किया जाना चाहिए।

नीचे कॉन्फ़िगरेशन pg_hba.conf में होना चाहिए

host    replication     postgres        <standby-database-host-ip>/32            trust

अब, प्राथमिक डेटाबेस का बैकअप लें और उसे DR साइट पर पुनर्स्थापित करें। एक बार बहाली के साथ, नीचे दी गई सामग्री के साथ डेटा निर्देशिका में पुनर्प्राप्ति.कॉन्फ़ फ़ाइल बनाएं:

standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

अब, स्टैंडबाय डेटाबेस प्रारंभ करें। स्ट्रीमिंग प्रतिकृति सक्षम होना चाहिए। स्टैंडबाय डेटाबेस की पोस्टग्रेस्क्ल लॉग फ़ाइल में नीचे दिया गया संदेश पुष्टि करता है कि स्ट्रीमिंग प्रतिकृति सफलतापूर्वक काम कर रही है:

2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

यह निष्कर्ष निकालता है कि पूरी तरह कार्यात्मक स्ट्रीमिंग प्रतिकृति जगह में है। repmgr को स्थापित/कॉन्फ़िगर करने के लिए अगला चरण। इससे पहले, आइए हम फ़ेलओवर प्रक्रिया को समझते हैं।

विफलता क्या है?

विफलता तब होती है जब आपदा के कारण प्राथमिक डेटाबेस पूरी तरह से अनुपलब्ध हो जाता है। फ़ेलओवर प्रक्रिया के दौरान, स्टैंडबाय डेटाबेस को एक नया प्राथमिक डेटाबेस बनने के लिए प्रोत्साहित किया जाएगा ताकि अनुप्रयोग व्यवसाय संचालन जारी रख सकें।

स्वचालित विफलता

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

ऐसा ही एक उपकरण जो स्वचालित विफलता को निष्पादित करने में मदद करता है, वह है "repmgr"।

आइए एक नजर डालते हैं repmgr और इसकी क्षमताओं पर।

Repmgr

Repmgr 2nd Quadrant द्वारा विकसित एक ओपनसोर्स टूल है। यह उपकरण आपदा की स्थिति में स्वचालित विफलता गतिविधियों को करने सहित PostgreSQL प्रतिकृति के निर्माण और निगरानी जैसी विभिन्न डेटाबेस प्रशासनिक गतिविधियों को करने में मदद करता है और स्विचओवर संचालन करने में भी मदद करता है।

Repmgr स्थापित करने में आसान उपकरण है और कॉन्फ़िगरेशन भी जटिल नहीं हैं। आइए पहले इंस्टालेशन पर एक नज़र डालें:

repmgr इंस्टॉल करना

यहां से टूल डाउनलोड करें।

टारबॉल को अनटार करें और नीचे दिखाए अनुसार इंस्टॉलेशन करें:

मैंने CentOS 7 होस्ट पर repmgr-4.2.0 स्थापित किया है और मैंने PostgreSQL-11.1 के विरुद्ध repmgr स्थापित किया है। स्थापना से पहले सुनिश्चित करें कि PostgreSQL बिन निर्देशिका $PATH का हिस्सा है और PostgreSQL lib निर्देशिका $LD_LIBRARY_PATH का हिस्सा है। यह समझने के लिए कि PostgreSQL-11.1 के खिलाफ repmgr स्थापित है, मैं नीचे "इंस्टॉल करें" आउटपुट प्रदर्शित कर रहा हूं:

[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

स्वचालित विफलता के लिए repmgr को कॉन्फ़िगर करना

"Repmgr" को कॉन्फ़िगर करने से पहले, डेटाबेस को स्ट्रीमिंग प्रतिकृति के साथ कॉन्फ़िगर किया जाना चाहिए जिसे हमने पहले देखा है। शुरू करने के लिए, दोनों डेटाबेस (प्राथमिक और स्टैंडबाय) को निम्नलिखित पैरामीटर के साथ postgresql.conf में कॉन्फ़िगर किया जाना चाहिए:

Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

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

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

फ़ाइल को डेटा निर्देशिका में रखें, इस मामले में, यह "/data/pgdata11" है।

स्टैंडबाय डेटाबेस कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित सामग्री होनी चाहिए:

node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

दोनों डेटाबेस को repmgr के साथ पंजीकृत होना चाहिए।
प्राथमिक डेटाबेस पंजीकृत करें

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

स्टैंडबाय डेटाबेस पंजीकृत करें

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

यह सुनिश्चित करने के लिए नीचे दिया गया आदेश चलाएँ कि repmgr लॉगिंग काम कर रही है।

[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

यदि आप देख सकते हैं, तो मैंने स्टैंडबाय की repmgr.conf फ़ाइल में विस्तृत लॉगिंग उत्पन्न करने के लिए log_level को DEBUG में कॉन्फ़िगर किया है। प्रतिकृति स्थिति के लिए लॉग की जांच करें।
जांचें कि प्रतिकृति repmgr का उपयोग करके अपेक्षित रूप से काम कर रही है:

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

उपरोक्त संदेश पुष्टि करता है कि प्रतिकृति ठीक चल रही है।

अब, यदि मैं प्राथमिक डेटाबेस को बंद करता हूं, तो repmgrd daemon को प्राथमिक डेटाबेस की विफलता का पता लगाना चाहिए और स्टैंडबाय डेटाबेस को बढ़ावा देना चाहिए। देखते हैं कि क्या ऐसा होता है -प्राथमिक डेटाबेस बंद हो जाता है:

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

स्टैंडबाय डेटाबेस को स्वचालित रूप से प्रचारित किया जाना चाहिए। repmgr लॉग वही दिखाएंगे:

fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

उपरोक्त सटीक अर्थ है, repmgr प्राथमिक डेटाबेस से कनेक्ट करने में असमर्थ था और असफल 5 प्रयासों के बाद, स्टैंडबाय को नए प्राथमिक डेटाबेस में बढ़ावा दिया जाता है। प्रचारित स्टैंडबाय (नए प्राथमिक) डेटाबेस लॉग को नीचे दिखाया गया है:

2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

मैंने केवल repmgr कॉन्फ़िगरेशन फ़ाइल में महत्वपूर्ण मापदंडों का उल्लेख किया है। कई अन्य पैरामीटर हैं जिन्हें विभिन्न आवश्यकताओं को पूरा करने के लिए संशोधित किया जा सकता है। अन्य महत्वपूर्ण पैरामीटर प्रतिकृति_लैग_* पैरामीटर हैं जैसा कि नीचे दिखाया गया है:

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

स्टैंडबाय को बढ़ावा देने से पहले रेपमग्र उपरोक्त मापदंडों की थ्रेसहोल्ड की जांच करेगा। यदि प्रतिकृति अंतराल महत्वपूर्ण है, तो पदोन्नति आगे नहीं बढ़ेगी। जो वास्तव में अच्छा है क्योंकि अगर अंतराल होने पर स्टैंडबाय को बढ़ावा दिया जाता है जिसके परिणामस्वरूप डेटा हानि हो सकती है।

एप्लिकेशन को यह सुनिश्चित करना चाहिए कि वे अपेक्षित समय सीमा के भीतर नए प्रचारित स्टैंडबाय से सफलतापूर्वक पुन:कनेक्ट हों। जब प्राथमिक डेटाबेस अनुत्तरदायी हो जाता है तो लोड बैलेंसर्स में ऐप कनेक्शन को डायवर्ट करने की क्षमता होगी। अन्य विकल्प यह सुनिश्चित करने के लिए PgPool-II जैसे मिडलवेयर टूल का उपयोग करना होगा कि सभी कनेक्शन सफलतापूर्वक डायवर्ट किए गए हैं।

उत्पादन में सफल उच्च-उपलब्धता वास्तुकला को सुनिश्चित करने के लिए, पूरी प्रक्रिया का संपूर्ण एंड-टू-एंड परीक्षण किया जाना चाहिए। मेरे अनुभव में, हम इस अभ्यास को DR DRILL कहते हैं। मतलब, हर 6 महीने में एक स्विचओवर ऑपरेशन किया जाएगा ताकि यह सुनिश्चित किया जा सके कि स्टैंडबाय को सफलतापूर्वक बढ़ावा दिया जा रहा है और ऐप कनेक्शन प्रचारित स्टैंडबाय से सफलतापूर्वक जुड़ रहे हैं। मौजूदा प्राथमिक एक नया स्टैंडबाय बन जाएगा। एक बार जब स्विचओवर ऑपरेशन सफल हो जाता है, तो एसएलए की पूर्ति देखने के लिए मेट्रिक्स को हटा दिया जाता है।

स्विचओवर क्या है?

जैसा कि ऊपर बताया गया है, स्विचओवर एक नियोजित गतिविधि है जिसमें प्राथमिक और स्टैंडबाय डेटाबेस की भूमिकाएं बदल दी जाती हैं। मतलब, स्टैंडबाय प्राइमरी हो जाएगा और प्राइमरी स्टैंडबाय हो जाएगा। repmgr का उपयोग करके, इसे प्राप्त किया जा सकता है। जब स्विचओवर कमांड जारी किया जाता है तो नीचे दिया गया है कि repmgr क्या करता है।

$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

अन्य प्रतिनिधि क्या कर सकते हैं?

• Repmgr शुरुआत से ही स्टैंडबाय डेटाबेस बनाने में मदद कर सकता है
• एक मास्टर रनिंग के साथ कई स्टैंडबाय डेटाबेस बनाए जा सकते हैं
• कैस्केडिंग स्टैंडबाय बनाया जा सकता है जो मुझे लगता है कि एक से अधिक स्टैंडबाय को एक मास्टर डेटाबेस में कॉन्फ़िगर करने की तुलना में अधिक फायदेमंद है

क्या होगा यदि प्राथमिक और स्टैंडबाय दोनों समाप्त हो जाएं?

खैर, यह एक ऐसी स्थिति है जिसमें व्यवसाय कई स्टैंडबाय इंस्टेंस होने के बारे में सोचता है। यदि वे सभी चले गए हैं, तो बैकअप से डेटाबेस को पुनर्स्थापित करने का एकमात्र तरीका है। यही कारण है कि एक अच्छी बैकअप रणनीति जरूरी है। बैकअप विश्वसनीय हैं यह सुनिश्चित करने के लिए बैकअप को परीक्षण-पुनर्स्थापित किया जाना चाहिए, नियमित आधार पर सत्यापित किया जाना चाहिए। बैकअप के लिए इन्फ्रास्ट्रक्चर डिज़ाइन ऐसा होना चाहिए कि, बैकअप की बहाली और पुनर्प्राप्ति में अधिक समय न लगे। बैकअप की बहाली और पुनर्प्राप्ति प्रक्रिया को निर्दिष्ट SLA के भीतर पूरा किया जाना चाहिए। बैकअप के लिए SLA को RTO (रिकवरी टाइम ऑब्जेक्टिव) और RPO (रिकवरी पॉइंट ऑब्जेक्टिव) के संदर्भ में डिज़ाइन किया गया है। मतलब, आरटीओ:बैकअप को बहाल करने और पुनर्प्राप्त करने के लिए लिया गया समय एसएलए और आरपीओ के साथ होना चाहिए:किस समय तक वसूली की गई थी, यह स्वीकार्य होना चाहिए, दूसरे शब्दों में यह डेटा हानि सहनशीलता है और आम तौर पर व्यवसाय 0 डेटा हानि कहते हैं सहनशीलता।

निष्कर्ष

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