Computer >> कंप्यूटर ट्यूटोरियल >  >> प्रोग्रामिंग >> डेटाबेस

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

यह पोस्ट चर्चा करती है कि मौजूदा Microsoft® SQL Server® AlwaysOn-कॉन्फ़िगर डेटाबेस के साथ लॉग शिपिंग कैसे सेट अप करें, जो एक डिजास्टर रिकवरी (DR) समाधान है।

परिचय

AlwaysOn उपलब्धता समूह (AG) सुविधा एक उच्च-उपलब्धता और डिजास्टर रिकवरी समाधान है जो डेटाबेस मिररिंग का एक एंटरप्राइज-लेवल विकल्प प्रदान करता है। SQL Server 2012 (11.x) में पेश किया गया, AlwaysOn AGs एक एंटरप्राइज के लिए उपयोगकर्ता डेटाबेस के एक सेट की उपलब्धता को अधिकतम करते हैं। AGs उपलब्धता डेटाबेस के रूप में जाने जाने वाले उपयोगकर्ता डेटाबेस के एक असतत सेट के लिए फेलओवर वातावरण का समर्थन करते हैं, जो एक साथ फेलओवर करते हैं। वे एक सेट रीड-राइट प्राथमिक डेटाबेस और एक से आठ सेट संबंधित सेकेंडरी डेटाबेस का भी समर्थन करते हैं। वैकल्पिक रूप से, AGs सेकेंडरी डेटाबेस को रीड-ओनली एक्सेस और कुछ बैकअप ऑपरेशन के लिए उपलब्ध करा सकते हैं।

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

AlwaysOn लॉग शिपिंग की आवश्यकता क्यों हो सकती है

मान लें कि आपने अपने प्राथमिक रेप्लिका सर्वर और अपने सेकेंडरी रेप्लिका के बीच AlwaysOn सेटअप कॉन्फ़िगर किया है और AlwaysOn का उपयोग मुख्य डेटा सेंटर में किया जाता है। आपको लॉग शिपिंग का उपयोग करने की आवश्यकता हो सकती है यदि आप आवश्यक Windows Server Failover Cluster (WSFC) कॉन्फ़िगरेशन को DR साइट में विस्तारित नहीं कर सकते। कारणों में निम्नलिखित संभावनाएं शामिल हैं:

  • इन्फ्रास्ट्रक्चर या स्टाफ अलग-अलग साइटों के बीच WSFC कॉन्फ़िगरेशन को बनाए नहीं रख सकते।
  • आप DR साइट में लक्ष्य सर्वर को WSFC कॉन्फ़िगरेशन में उपयोग नहीं कर सकते क्योंकि यह पहले से ही किसी अन्य WSFC कॉन्फ़िगरेशन का हिस्सा है।
  • रिकवरी पॉइंट ऑब्जेक्टिव (RPO) और रिकवरी टाइम ऑब्जेक्टिव (RTO) पर सर्विस लेवल एग्रीमेंट (SLA) मैन्युअल त्रुटि से तेजी से रिकवरी को मजबूर करते हैं, जिसे केवल उच्च उपलब्धता (HA) और DR रणनीति के एक इंस्टेंस पर विलंबित रिकवरी के साथ ट्रांजैक्शन लॉग बैकअप को पुनर्स्थापित करके महसूस किया जा सकता है।

इसलिए, आपको लक्ष्य सर्वर की आपूर्ति करने की आवश्यकता है, जो DR साइट में है, वर्तमान प्राथमिक पर मुख्य साइट पर किए गए बैकअप से ट्रांजैक्शन लॉग को शिप करके।

लॉग शिपिंग का उपयोग करने के लिए पूर्वापेक्षाएँ

लॉग शिपिंग सेट अप करने से पहले, सुनिश्चित करें कि आप निम्नलिखित पूर्वापेक्षाओं को पूरा करते हैं:

  • प्राथमिक डेटाबेस को फुल या बल्क-लॉग्ड रिकवरी मॉडल का उपयोग करना चाहिए। डेटाबेस को सिंपल रिकवरी पर स्विच करने से लॉग शिपिंग कार्य करना बंद कर देता है।
  • लॉग शिपिंग कॉन्फ़िगर करने से पहले, आपको ट्रांजैक्शन लॉग बैकअप को सेकेंडरी सर्वर पर उपलब्ध कराने के लिए एक साझा पथ बनाना होगा।
  • लॉग-शिपिंग स्टोर्ड प्रोसीजर के लिए sysadmin फिक्स्ड सर्वर भूमिका में सदस्यता की आवश्यकता होती है।
  • बैकअप साझा पथ में SQL Server सर्विस खाते के लिए पढ़ने और लिखने की अनुमति होनी चाहिए।

लॉग शिपिंग DR समाधान उदाहरण कॉन्फ़िगर करें

इस उदाहरण में, हमने पहले से ही प्राथमिक रेप्लिका सर्वर, जिसे PRIMEHEAD कहा जाता है, और आपके सेकेंडरी रेप्लिका, जिसे HEAD2 कहा जाता है, के बीच AlwasyOn सेटअप किया है, जैसा कि निम्न छवि में दिखाया गया है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

यह अनुभाग एक AlwaysOn AG का पहले से हिस्सा रहे डेटाबेस पर लॉग शिपिंग कॉन्फ़िगर करने के लिए चरण-दर-चरण समाधान प्रदान करता है।

चरण 1

AdventureWork2014 डेटाबेस के लिए PRIMEHEAD और DR सर्वर, HEAD3 के बीच लॉग शिपिंग कॉन्फ़िगर करें।

डेटाबेस पर लॉग शिपिंग कॉन्फ़िगर करते समय, AdventureWork2014 डेटाबेस का पूर्ण बैकअप लें और इसे HEAD3 पर नॉन-रिकवरी के साथ पुनर्स्थापित करें। आपको PRIMEHEAD पर एक साझा फ़ोल्डर बनाने की आवश्यकता है ताकि लॉग बैकअप स्टोर किया जा सके जिसका उपयोग LSCopy (लॉग शिपिंग) जॉब करता है।

चरण 2

डेटाबेस पर राइट-क्लिक करें, गुण चुनें, और PRIMEHEAD के बाईं ओर ट्रांजैक्शन लॉग शिपिंग विकल्प पर क्लिक करें। फिर, निम्न छवि में दिखाए अनुसार हाइलाइट किए गए इसे लॉग शिपिंग कॉन्फ़िगरेशन में प्राथमिक डेटाबेस के रूप में सक्षम करें चेकबॉक्स पर क्लिक करें:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 3

बैकअप सेटिंग पर क्लिक करके LS बैकअप विकल्प कॉन्फ़िगर करें। निम्न छवि में दिखाए अनुसार LS बैकअप के लिए नेटवर्क-साझा पथ चुनें:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 4

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

चरण 5

DR सर्वर जोड़ने के लिए, निम्न छवि में दिखाए अनुसार जोड़ें पर क्लिक करें:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 6

निम्न छवि में दिखाए अनुसार HEAD3, DR सर्वर से कनेक्ट करने के लिए कनेक्ट पर क्लिक करें:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 7

सेकेंडरी डेटाबेस आरंभ करें टैब पर, तीसरा विकल्प चुनें क्योंकि डेटाबेस पहले से ही HEAD3 पर आरंभ किया गया है।

चरण 8

फ़ाइलें कॉपी करें टैब पर क्लिक करें। कॉपी की गई फ़ाइलों के लिए गंतव्य फ़ोल्डर बॉक्स में, वह पथ टाइप करें जहां ट्रांजैक्शन लॉग बैकअप कॉपी किए जाते हैं। इस परिदृश्य के लिए, पथ के लिए C:\LSCopyAlwaysOn का उपयोग करें, जैसा कि निम्न छवि में दिखाया गया है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 9

ट्रांजैक्शन लॉग पुनर्स्थापित करें टैब पर, बैकअप पुनर्स्थापित करते समय डेटाबेस स्थिति के तहत, या तो नो रिकवरी मोड या स्टैंडबाय मोड चुनें, जैसा कि निम्न छवि में दिखाया गया है:

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

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 10

लॉग शिपिंग शुरू करने के लिए OK पर क्लिक करें।

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

निम्न स्क्रीन प्रदर्शित होती है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 11

लॉग शिपिंग स्थिति जांचने के लिए, DR सर्वर, HEAD3, इंस्टेंस पर राइट-क्लिक करें, और रिपोर्ट → मानक रिपोर्ट — → ट्रांजैक्शनल लॉग शिपिंग स्थिति चुनें। यदि निम्न स्क्रीन दिखाई देती है, तो लॉग शिपिंग स्वस्थ है और अपेक्षा के अनुरूप काम कर रहा है।

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

यदि PRIMEHEAD और HEAD2 के बीच AG फेलओवर होता है, तो लॉग शिपिंग तब तक बाधित होती है जब तक कि आप AG विनिर्देशों पर विचार करके इसे कॉन्फ़िगर नहीं करते।

अब आप HEAD2 से HEAD3 तक लॉग शिपिंग कॉन्फ़िगर कर सकते हैं, जो भविष्य में AG रेप्लिका के बीच फेलओवर होने पर भी लॉग शिपिंग कार्यक्षमता को प्रभावित नहीं करेगा। लॉग बैकअप हमेशा उसी पथ या स्थान पर होता है, भले ही कौन सा रेप्लिका प्राथमिक के रूप में कार्य कर रहा हो।

आपको रेप्लिका के बीच फेलओवर आरंभ करने की आवश्यकता है। फेलओवर आरंभ करने से पहले, निम्न चरणों को पूरा करें:

  1. प्राथमिक रेप्लिका पर LS बैकअप जॉब निष्पादित करें और जॉब को अक्षम करें।

  2. सेकेंडरी रेप्लिका पर LS कॉपी और रिस्टोर जॉब निष्पादित करें और फिर इसे अक्षम करें।

ऐसा करने के लिए, AG पर राइट-क्लिक करें और निम्न छवि में दिखाए अनुसार फेलओवर विकल्प चुनें:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

आप निम्न T-SQL कमांड का उपयोग करके मैन्युअल रूप से AG फेलओवर ट्रिगर करके भी इसे पूरा कर सकते हैं:

USE master; 
GO 
ALTER AVAILABILITY GROUP [AGName] FAILOVER 
GO

फेलओवर पूरा होने के बाद, निम्न विंडो प्रदर्शित होती है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

चरण 12

PRIMEHEAD और HEAD2 के बीच AG फेलओवर के बाद, वर्तमान प्राथमिक इंस्टेंस HEAD2 है।

वर्तमान प्राथमिक सर्वर या नोड, HEAD2, से DR सर्वर, HEAD3 तक लॉग शिपिंग कॉन्फ़िगर करने के लिए समान चरणों का पालन करें। लॉग शिपिंग कॉन्फ़िगर करते समय, वही साझा पथ चुनें जो आपने PRIMEHEAD और HEAD3 के बीच LS कॉन्फ़िगरेशन के दौरान उपयोग किया था, \Avail2017\lsbackup।

चरण 13

HEAD2, वर्तमान प्राथमिक, और HEAD3 के बीच लॉग शिपिंग पूरा होने के बाद, HEAD2 पर एक LS बैकअप जॉब बनाई जाती है, और HEAD3 पर LS कॉपी और LS रिस्टोर जॉब का एक और सेट बनाया जाता है।

एक बार फिर AG रेप्लिका के बीच फेलओवर आरंभ करें। फेलओवर आरंभ करने से पहले, निम्न चरणों को पूरा करना सुनिश्चित करें:

  1. प्राथमिक (HEAD2) पर LS बैकअप जॉब निष्पादित करें और जॉब को अक्षम करें।

  2. सेकेंडरी (HEAD3) पर LS कॉपी और रिस्टोर जॉब निष्पादित करें और फिर इसे अक्षम करें।

चरण 14

अंतिम फेलओवर के बाद, वर्तमान प्राथमिक PRIMEHEAD है, HEAD2 सेकेंडरी रेप्लिका है, और HEAD3 DR सर्वर है। क्योंकि LS बैकअप जॉब दोनों सर्वरों (प्राथमिक और सेकेंडरी) पर मौजूद हैं, आपको PRIMEHEAD और HEAD2 दोनों पर LS बैकअप जॉब को संशोधित करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि यह केवल वर्तमान प्राथमिक से लॉग बैकअप लेता है।

ऐसा करने के लिए, जॉब स्टेप 1 में निम्न कोड जोड़ें:

Declare @dbname as varchar(20) 
Set @dbname='AdventureWorks2014' 
If sys.fn_hadr_backup_is_preferred_replica (@dbname)<>1 
begin 
RAISERROR (50005,-- Message id, 
16, -- Severity, 
1, --State, 
N'This is not the primary server backup is rolled back'); 
end

निम्न छवि इसे दर्शाती है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

पूर्ववर्ती परिवर्तन करने के बाद, ध्यान दें कि LS बैकअप जॉब सेकेंडरी सर्वर पर विफल होने लगती है लेकिन प्राथमिक पर ठीक चलती है।

चरण 15

क्योंकि HEAD3, DR सर्वर पर LS कॉपी और रिस्टोर जॉब के दो सेट हैं, आपको यह सुनिश्चित करना होगा कि एक समय में केवल एक सेट जॉब चले। आपको उन जॉब को सक्षम रखने की आवश्यकता है जो HEAD2 और HEAD3 के बीच लॉग शिपिंग कॉन्फ़िगर करते समय बनाए गए थे और जॉब के दूसरे सेट को अक्षम करें।

निम्न छवि अधिक विवरण दिखाती है:

मौजूदा SQL Server AlwaysOn डेटाबेस के लिए लॉग शिपिंग: एक व्यावहारिक DR गाइड

अब, आपने एक डेटाबेस पर लॉग शिपिंग को सफलतापूर्वक कॉन्फ़िगर कर लिया है जो AlwaysOn AG का मौजूदा हिस्सा है। कोई फर्क नहीं पड़ता कि कौन सा सर्वर प्राथमिक सर्वर के रूप में काम कर रहा है, आपका लॉग शिपिंग सिंक में रहेगा।

नोट: हम दृढ़ता से अनुशंसा करते हैं कि आप टेस्टिंग के बिना प्रोडक्शन में कोई बदलाव न करें। इस समाधान को अपने प्रोडक्शन वातावरण में लागू करने से पहले, पहले इस कॉन्फ़िगरेशन को टेस्ट वातावरण में लागू करें।

मान्यता:

a) सुनिश्चित करें कि बैकअप जॉब वर्तमान प्राथमिक रेप्लिका पर सफलतापूर्वक चल रही है। b) बैकअप पथ साझा पथ के समान होना चाहिए। c) कॉपी और रिस्टोर जॉब, जो HEAD2 से HEAD3 तक LS कॉन्फ़िगरेशन के दौरान बनाए गए थे, DR सर्वर पर ठीक से चलना चाहिए। d) मानक रिपोर्ट अनुभाग में ट्रांजैक्शनल लॉग शिपिंग स्थिति जांचें।

निष्कर्ष

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

टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें।

विशेषज्ञ प्रशासन, प्रबंधन और कॉन्फ़िगरेशन के साथ अपने वातावरण को अनुकूलित करें

Rackspace के एप्लिकेशन सर्विसेज (RAS) विशेषज्ञ अनुप्रयोगों के एक विस्तृत पोर्टफोलियो में निम्नलिखित पेशेवर और प्रबंधित सेवाएं प्रदान करते हैं:

  • ईकॉमर्स और डिजिटल एक्सपीरियंस प्लेटफॉर्म
  • एंटरप्राइज रिसोर्स प्लानिंग (ERP)
  • बिजनेस इंटेलिजेंस
  • सेल्सफोर्स कस्टमर रिलेशनशिप मैनेजमेंट (CRM)
  • डेटाबेस
  • ईमेल होस्टिंग और उत्पादकता

हम प्रदान करते हैं:

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

अभी चैट करें शुरू करने के लिए।

  1. SQL Server Query Store मास्टर करें: क्वेरी प्रदर्शन को कैप्चर, विश्लेषण और हल करें SQL Server Query Store मास्टर करें: क्वेरी प्रदर्शन को कैप्चर, विश्लेषण और हल करें

    माइक्रोसॉफ्ट® SQL Server® Query Store, जैसा कि नाम से पता चलता है, एक स्टोर की तरह है जो निष्पादित क्वेरी, क्वेरी रनटाइम निष्पादन आंकड़े, और निष्पादन योजनाओं के डेटाबेस इतिहास को कैप्चर करता है। चूंकि डेटा डिस्क पर संग्रहीत होता है, आप किसी भी समय समस्या निवारण उद्देश्यों के लिए क्वेरी स्टोर डेटा पु

  1. Microsoft SQL Server में उन्नत भ्रष्टाचार पहचान और पुनर्प्राप्ति Microsoft SQL Server में उन्नत भ्रष्टाचार पहचान और पुनर्प्राप्ति

    यह ब्लॉग Microsoft® SQL Server® में डेटाबेस स्तर पर होने वाली भ्रष्टाचार का वर्णन करता है, उनका पता कैसे लगाया जाए, और उन्नत पुनर्स्थापना और मरम्मत तकनीकों का उपयोग करके उन्हें कैसे ठीक किया जाए। परिचय वर्तमान में, SQL Server अपनी उन्नत आंतरिक संरचना और उच्च विश्वसनीयता के कारण सबसे लोकप्रिय और व्या

  1. SQL Server 2019: आधुनिक विश्लेषण के लिए एकीकृत डेटा प्लेटफॉर्म SQL Server 2019: आधुनिक विश्लेषण के लिए एकीकृत डेटा प्लेटफॉर्म

    2006 में, ब्रिटिश गणितज्ञ क्लाइव रॉबर्ट हम्बी ने शब्दों को चिह्नित किया: डेटा नया तेल है। तब से, IT नेताओं ने इसे बार-बार सुना है, इस विचार से सहमत हुए हैं, और हर कदम पर इसे बढ़ाया है। क्लाइव ने आगे जोड़ा, डेटा मूल्यवान है, लेकिन अगर अनरिफाइंड है, तो इसका वास्तव में उपयोग नहीं किया जा सकता। जिस तरह