क्रिसमस की कहानी

हम उस कहानी को साझा करना चाहते हैं जो नए साल के लिए हमारी एक परियोजना में हुई थी। परियोजना का सार यह है कि यह चिकित्सा संस्थानों में डॉक्टरों के काम को स्वचालित करता है। रोगी की यात्रा के दौरान, डॉक्टर रिकॉर्डर को जानकारी लिखता है, फिर ऑडियो को स्थानांतरित किया जाता है। प्रतिलेखन प्रक्रिया के बाद - अर्थात ऑडियो रिकॉर्डिंग को पाठ में बदलना - एक मेडिकल दस्तावेज़ प्रासंगिक मानकों के अनुसार बनता है और क्लिनिक में वापस भेजा जाता है, जहाँ से ऑडियो रिकॉर्डिंग आती है, जहाँ भेजने वाले डॉक्टर इसे प्राप्त करते हैं, जाँच करते हैं और इसे अनुमोदित करते हैं। अनिवार्य जांचों को पास करने के बाद, दस्तावेज अंतिम रोगियों को भेजा जाता है।

उत्पाद का उपयोग करने वाले सभी चिकित्सा संस्थानों को सशर्त रूप से दो बड़े समूहों में विभाजित किया जा सकता है:

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

यह हमारी टीम के अंत सर्वरों के साथ बातचीत करता है जो सीधे हमारे ग्राहक के क्लाउड में होस्ट किए जाते हैं।



हमारे पास इन सर्वरों तक सभी निर्धारित कार्य और रखरखाव की आवश्यकता होती है।

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

यह ध्यान में रखा जाना चाहिए कि आरेख में दर्शाया गया प्रत्येक सर्वर वास्तव में एक एप्लिकेशन सर्वर और डेटाबेस सर्वर का एक संयोजन है। डेटाबेस सर्वर पर, क्रमशः, MS SQL सर्वर DBMS और SSRS रिपोर्टिंग सेवा स्थापित होती है। इसके अलावा, MSSQL सर्वर का संस्करण सभी क्लीनिकों में अलग है: 2008, 2012, 2014। स्वयं संस्करणों के अलावा, हर जगह अलग-अलग सर्विस पैक्स और पैच स्थापित किए जाते हैं। सामान्य तौर पर, एक पूर्ण चिड़ियाघर।

एप्लिकेशन सर्वर पर हमने IIS और ElasticSearch वेब सर्वर स्थापित किया है। ElasticSearch एक खोज इंजन है जो पूर्ण-पाठ खोज को भी लागू करता है।
हमारे उत्पाद के संदर्भ में मुख्य सार "नौकरी" है। कार्य एक अमूर्त इकाई है जो एक विशेष रोगी के रिसेप्शन से संबंधित सभी जानकारी को एक साथ जोड़ता है। इस जानकारी में शामिल हैं:

• डॉक्टर के बारे में डेटा;
• रोगी डेटा;
• यात्रा के बारे में डेटा;
• ऑडियो फ़ाइल (डॉक्टर का भाषण);
• दस्तावेज़ (कई संस्करण);
• कार्य प्रसंस्करण इतिहास;
• शाखा की जानकारी, आदि।

यह आरेख एक सरलीकृत डेटाबेस स्कीमा दिखाता है जिसमें से आप मुख्य तालिकाओं के बीच संबंधों को देख सकते हैं। यह केवल मूल भाग है, वास्तव में, डेटाबेस में 200 से अधिक टेबल हैं।



क्लिनिक के बारे में जहां घटना हुई:

• 1500-2000 प्रति दिन काम करता है;
• 1000+ सक्रिय उपयोगकर्ता (डॉक्टर + सचिव);
• स्व की मेजबानी की।

डीबी:

• आकार: 800+ जीबी (750K + कार्य, 2M + दस्तावेज);
• DBMS: MS SQL Server 2008 R2;
• रिकवरी मॉडल: सरल।

यहां मैं थोड़ा स्पष्टीकरण करना चाहता हूं। SQL सर्वर में 3 पुनर्प्राप्ति मॉडल हैं: सरल, बल्क-लॉग्ड और पूर्ण। मैं अब तीसरे के बारे में नहीं बोलूंगा, पहले और दूसरे के बारे में बताऊंगा। मुख्य अंतर यह है कि सरल मॉडल में हम लॉग में लेनदेन के इतिहास को संग्रहीत नहीं करते हैं - जैसे ही लेनदेन किया गया है, लेनदेन लॉग से रिकॉर्ड हटा दिया जाएगा। पूर्ण पुनर्प्राप्ति मोड का उपयोग करते समय, डेटा परिवर्तन का पूरा इतिहास एक लेनदेन लॉग में संग्रहीत किया जाता है। यह हमें क्या देता है? कुछ अप्रत्याशित स्थिति की स्थिति में, जब हमें डेटाबेस को बैकअप से रोल करने की आवश्यकता होती है, तो हम न केवल एक विशिष्ट बैकअप पर लौट सकते हैं, लेकिन किसी भी समय पर वापस लौट सकते हैं, एक विशिष्ट लेनदेन तक, अर्थात, हमने संग्रहीत किया है बैकअप में, न केवल बैकअप के समय डेटाबेस की एक निश्चित स्थिति होती है, बल्कि डेटा परिवर्तनों का एक पूरा इतिहास भी होता है।

मुझे लगता है कि यह समझाने योग्य नहीं है कि सरल मोड का उपयोग केवल विकास में, परीक्षण सर्वर पर और उत्पादन में इसका उपयोग अस्वीकार्य है। कोई रास्ता नहीं।

लेकिन क्लिनिक, जाहिरा तौर पर, इस विषय पर अपने स्वयं के विचार थे;)

शुरुआत

नए साल के कुछ दिनों बाद, हर कोई छुट्टी की तैयारी कर रहा है, उपहार खरीद रहा है, क्रिसमस के पेड़ सजा रहा है, कॉर्पोरेट पार्टी खर्च कर रहा है और एक लंबे सप्ताहांत के लिए इंतजार कर रहा है।

22 दिसंबर (शुक्रवार) 1 दिन

14:31 क्लाइंट ने कहा कि उसे अगली दैनिक रिपोर्ट प्राप्त नहीं हुई। रिपोर्ट एक शेड्यूल पर दिन में दो बार मेल में आती है; इसे बाहरी एकीकरण प्रणाली में डेटा भेजने को नियंत्रित करने की आवश्यकता होती है, जो बहुत महत्वपूर्ण नहीं है।

इसके कई कारण हो सकते हैं:

1. एसएमटीपी के साथ समस्याएं, केवल पत्र वितरित नहीं किए गए (उन्होंने पासवर्ड बदल दिया, उदाहरण के लिए, और उन्होंने किसी को नहीं बताया);
2. रिपोर्ट के सर्वर साइड में समस्याएं;
3. डेटाबेस में कुछ हुआ है।

16:03 क्लिनिक कभी-कभी इसके बारे में किसी को चेतावनी दिए बिना, पासवर्ड को SMTP में बदल देता है, इसलिए, वर्तमान कार्यों को पूरा करने के बाद, हम वेब इंटरफ़ेस के माध्यम से इसे लॉन्च करके मैन्युअल रूप से रिपोर्ट की जांच करते हैं - हमें एक त्रुटि मिलती है जो डेटाबेस में समस्याओं को इंगित करती है।

रिपोर्ट शुरू करते समय हमें प्राप्त त्रुटि का एक उदाहरण।

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x9876641f; actual: 0xa3255fbf). It occurred during a read of page (1:876) in database ID 7 at offset 0x000000006d8000 in file 'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\ServerLive.mdf'. 

यह इंगित करता है कि डेटाबेस ने पृष्ठों को दूषित कर दिया है। हमें थोड़ी-बहुत चिंता थी।

20:53 क्षति की सीमा का आकलन करने के लिए, हम विशेष DBCC CHECKDB कमांड का उपयोग करके एक डेटाबेस चेक चलाते हैं। क्षति के आकार के आधार पर, परीक्षण कमांड में काफी समय लग सकता है, इसलिए हम रात में कमांड चलाते हैं। यहां हम भाग्यशाली हैं कि यह शुक्रवार दोपहर को हुआ, अर्थात्, इस समस्या को हल करने के लिए हमारे पास कम से कम सभी दिन बंद थे।

उस समय, स्थिति इस प्रकार थी:

23 दिसंबर (शनिवार) दूसरा दिन

10:02 सुबह, हम पाते हैं कि CHECKDB के साथ डेटाबेस की जाँच फ़्लॉपी है - यह फ्री डिस्क की कमी के कारण था, क्योंकि सत्यापन प्रक्रिया के दौरान, अस्थायी अस्थायी डेटाबेस सक्रिय रूप से उपयोग किया जाता है, और कुछ बिंदु पर मुफ्त डिस्क स्थान बस बाहर भाग गया।

इसलिए, हम टेबल स्कैन को तुरंत लॉन्च करने के लिए पूरे डेटाबेस की जांच करने के बजाय निर्णय लेते हैं। ऐसा करने के लिए, DBCC CHECKTABLE कमांड का उपयोग करें।

10:46 हम JobHistory टेबल के साथ शुरू करने का निर्णय लेते हैं, जो संभवतः दूषित है, क्योंकि यह वह था जिसका उपयोग रिपोर्ट बनाने के लिए किया गया था। यह तालिका, जैसा कि नाम से स्पष्ट है, सभी कार्यों के इतिहास को संरक्षित करती है, अर्थात, चरणों के बीच कार्य का संक्रमण।

भागो DBCC CHECKTABLE ('dbo.JobHistory') ।

इस तालिका की जाँच से डेटाबेस में क्षतिग्रस्त तालिकाओं का पता चलता है, जो सिद्धांत रूप में अपेक्षित थी।

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

हम शुरू करते हैं। चेक फिर से एक त्रुटि के साथ समाप्त होता है - हमें एक त्रुटि मिलती है कि संबंधित तालिकाओं को बहाल करने तक इस तालिका की बहाली असंभव है। हिस्ट्री टेबल विदेशी कुंजी द्वारा कार्य तालिका (जॉब्स) को संदर्भित करता है, इसलिए, हम यह निष्कर्ष निकालते हैं कि मुख्य कार्य तालिका (जॉब्स) में भी क्षति है।

13:30 अगला चरण जॉब्स तालिका की जांच करना है, उसी समय - हमें उम्मीद है कि क्षति सूचकांक में है, और डेटा में नहीं। इस स्थिति में, डेटा रिकवरी के लिए इंडेक्स को फिर से बनाना हमारे लिए पर्याप्त होगा।

17:33 थोड़ी देर के बाद, हम पाते हैं कि हमारा सर्वर RDP के माध्यम से उपलब्ध नहीं है। यह शायद बंद कर दिया गया था, चेक पूरा नहीं हुआ था, काम निलंबित कर दिया गया था। हम क्लिनिक को सूचित करते हैं कि सर्वर अनुपलब्ध है, कृपया इसे बढ़ाएं।

हल्के चिंता बहुत विशिष्ट रूपों पर होती है।

24 दिसंबर (रविवार) तीसरा दिन

14:31 डिनर के लिए, सर्वर बढ़ा हुआ है, हम जॉब्स टेबल चेक को फिर से चलाते हैं।
DBCC CHECKTABLE ('dbo.Jobs')

16:05 सत्यापन पूरा नहीं हुआ, सर्वर अनुपलब्ध है। फिर।

कुछ समय बाद, सर्वर फिर से अनुपलब्ध है, इससे पहले कि हम तालिका की जाँच करने में सफल रहे। इस बिंदु पर, क्लिनिक की आईटी सेवा सर्वर चेक की एक श्रृंखला करती है। हम काम पूरा होने का इंतजार कर रहे हैं।

छुट्टियों के कारण, हमारे और ग्राहक के बीच संचार धीमा था - हमें कई घंटों तक सवालों के जवाब की उम्मीद थी।

25 दिसंबर (सोमवार - क्रिसमस) 4 वां दिन

16:00 अगले दिन सर्वर उठाया गया, ग्राहक के पास क्रिसमस है, और हम फिर से तालिका की जांच शुरू करते हैं, लेकिन इस बार हम स्कैन से अनुक्रमित को बाहर करते हैं, और हम केवल डेटा की जांच छोड़ देते हैं। और कुछ समय बाद सर्वर फिर से अनुपलब्ध है।

क्या चल रहा है?

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

क्लाइंट होस्ट मशीन पर डिस्क चेक करता है।

17:19 क्लिनिक IT सेवा ने बताया कि वर्चुअल मशीन फ़ाइल क्षतिग्रस्त है - यह खराब है!
हम अभी तक काम नहीं कर सकते हैं, और हम एक संकेत की प्रतीक्षा कर रहे हैं जब वे समस्या को ठीक करते हैं और हम अपना काम जारी रख सकते हैं।

26 दिसंबर (मंगलवार) दिन 5

14:05 आईटी क्लिनिक सेवा ने एक और डिस्क रिकवरी प्रक्रिया शुरू की। हमें बताया गया था कि हम तालिका की जांच करने के लिए समानांतर में CHECKTABLE चला सकते हैं। हम फिर से परीक्षण शुरू करते हैं - वर्चुअल मशीन फिर से क्रैश हो जाती है, हम क्लाइंट को सूचित करते हैं कि वर्चुअल मशीन फ़ाइल अभी भी दूषित है।

इन दिनों, छुट्टियों के कारण एक विशाल समय अंतराल के साथ ग्राहक के साथ सभी संचार बहुत धीमे हैं।

27 दिसंबर (बुधवार) दिन 6

14:00 हम वर्चुअल मशीन के अंदर विंडोज - चेकडिस्क का उपयोग करके डिस्क की जांच शुरू करते हैं - कोई समस्या नहीं पाई गई।
डेटाबेस सरल मोड में है, इसलिए DBMS टूल के साथ वर्तमान डेटाबेस को ठीक करने की संभावना शून्य हो जाती है, क्योंकि हम व्यक्तिगत क्षतिग्रस्त पृष्ठों को पुनर्प्राप्त नहीं कर सकते हैं।
हम बैकअप को वापस लाने और डेटाबेस को बैकअप से बहाल करने के विकल्प पर विचार करना शुरू कर रहे हैं।
हम डेटाबेस बैकअप की जांच करते हैं और पाते हैं कि बैकअप DBMS साधनों का उपयोग करके नहीं बनाए गए थे, अंतिम बैकअप 2014 में था, अर्थात डेटाबेस का कोई बैकअप नहीं है। उन्होंने ऐसा क्यों नहीं किया यह एक अलग मुद्दा है, यह डेटाबेस की संचालन और सुरक्षा सुनिश्चित करने के लिए क्लिनिक की जिम्मेदारी है।

एक उच्च संभावना है कि यह वर्तमान डेटाबेस को पुनर्स्थापित करने के लिए काम नहीं करेगा, हम रोलबैक के अन्य विकल्पों पर विचार करना शुरू करते हैं।

आइए क्लिनिक में बैकअप के साथ स्थिति पर अधिक विस्तार से ध्यान दें।

बैकअप के साथ स्थिति:

• डेटाबेस बैकअप नहीं हैं (!!!)
• वर्चुअल मशीन (?) के कोई स्नैपशॉट नहीं हैं
• लेकिन डिस्क बैकअप (पूर्ण + इंक) हैं

डेटाबेस क्रमशः डिस्क डी पर है, उन्होंने साप्ताहिक पूर्ण बैकअप और दैनिक वृद्धिशील बैकअप किए।

• हर शुक्रवार को 20:00 पूर्ण बैकअप पर
• हर दिन वृद्धिशील बैकअप
• 15 वीं और 22 वीं पूर्ण बैकअप है
• 21 तारीख तक दैनिक बैकअप हैं

यानी सिद्धांत रूप में, हम समस्या होने से पहले वापस रोल कर सकते हैं।
हम बैकअप से डेटाबेस के रोलबैक को शुरू करने के लिए क्लिनिक से अपडेट की प्रतीक्षा कर रहे हैं।

उसी समय, क्लिनिक ने लोहे (एचपी) के आपूर्तिकर्ता को "तत्काल" चिह्नित करने का अनुरोध भेजा।

28 दिसंबर (गुरुवार) दिन 7

13:13 क्लिनिक आईटी सेवा एक नई वर्चुअल मशीन स्थापित करना शुरू करती है, जैसा कि पुरानी वर्चुअल मशीन की फ़ाइल में क्षति को ठीक करना संभव नहीं है।

19:09 SQL सर्वर स्थापित के साथ एक नई वर्चुअल मशीन उपलब्ध है।
अगला कदम डेटाबेस को डिस्क बैकअप से पुनर्स्थापित करना है। शुरू करने के लिए, हम 22 वें दिन तक वापस आने का फैसला करते हैं, यदि समस्या अभी भी मौजूद है, तो 21 वीं, 20 वीं तारीख और इसी तरह, जब तक हम एक कार्यशील स्थिति में नहीं आते हैं, तब तक रोल करें।

यह यार्ड में 28 वां दिन था, हम कॉर्पोरेट पार्टी में थे, और यहां वे हमें बताते हैं कि क्लिनिक में बैकअप बहाल करने में समस्या है, क्योंकि बैकप्ल ईएमपीटीवाई हैं!

यहाँ खबर है!

21 वें से ड्राइव डी का बैकअप बहाल करते समय, यह पता चलता है कि यह खाली है, सभी की तरह। प्रत्यक्ष श्रेडर बैकअप प्राप्त होते हैं - वे वहां लगते हैं, लेकिन उसी समय वे नहीं होते हैं। यह पूरी तरह से स्पष्ट नहीं है कि यह सब कैसे हुआ, लेकिन, जहां तक ​​हम समझने में सक्षम थे, बिंदु डिस्क बैकअप को संग्रहीत करने के लिए अपर्याप्त डिस्क स्थान पर है। उन्होंने भंडारण के लिए 500 जीबी बैकअप आवंटित किया, लेकिन घटना के समय, डेटाबेस में पहले से ही 800 जीबी वजन था, इसलिए, सिद्धांत रूप में, बैकअप सफल नहीं हो सकता था। यानी शेड्यूल के अनुसार बैकअप नियमित रूप से किया गया था, लेकिन जगह की कमी के कारण, वे एक त्रुटि के साथ समाप्त हो गए और, तदनुसार, खाली थे, और क्लिनिक की आईटी सेवा को यह जांचने का भी विचार नहीं था कि उनके साथ सब कुछ ठीक था। ऐसा मत करो।

29 दिसंबर (शुक्रवार) दिन 8

13:11 आगे की क्रियाओं पर चर्चा। संभावित विकल्प:

• डेटाबेस फ़ाइलों (.ldf + .two फ़ाइलों) की प्रतिलिपि बनाने का प्रयास - सफलता की संभावना बहुत कम है;
• डेटाबेस का बैकअप लेने की कोशिश फिर से बहुत कम मौका है;
• प्रतिकृति कॉन्फ़िगर करें - काम कर सकता है।

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

14:36 इसलिए, हम नंबर एक विकल्प के लिए आगे बढ़ते हैं, हालाँकि हम बहुत अधिक सफलता की उम्मीद नहीं करते हैं।
SQL सर्वर बंद करो, डेटा फ़ाइल (mdf) और लॉग (ldf) की प्रतिलिपि बनाना शुरू करें।

16:13 लॉग फ़ाइल के आधे हिस्से के बाद, इसे सफलतापूर्वक (48 Gb) कॉपी किया गया था, और 50 GB डेटा फ़ाइल को पहले ही कॉपी कर लिया गया था (746 846 GB की बाईं ओर)। इस गति से, प्रतिलिपि को पूरा करने में लगभग 12 घंटे लगेंगे।

16:30 फ़ाइल को कॉपी करते समय पुराना डेटाबेस सर्वर बंद हो गया, जो काफी अपेक्षित है।

17:09 इसलिए, हम अगले विकल्प पर जाते हैं - प्रतिकृति की स्थापना, जबकि हम निर्दिष्ट कर सकते हैं कि किस डेटा को दोहराया जाएगा, अर्थात्, हम पहले जानबूझकर क्षतिग्रस्त तालिकाओं को बाहर कर सकते हैं और सबसे पहले undamaged डेटा की प्रतिलिपि बना सकते हैं, और फिर भागों में समस्याग्रस्त तालिकाओं को स्थानांतरित कर सकते हैं। लेकिन यह विकल्प, दुर्भाग्य से, या तो काम नहीं करता है, क्योंकि हम डेटाबेस भ्रष्टाचार के कारण कुछ तालिकाओं के साथ एक प्रकाशन भी नहीं बना सकते हैं।
हम डेटा ट्रांसफर के विकल्पों पर भी विचार कर रहे हैं।

20:01 परिणामस्वरूप, हम प्राथमिकता क्रम में आयात और निर्यात करके पुराने से नए सर्वर में डेटा स्थानांतरित करना शुरू करते हैं।

21:35 सबसे पहले, सबसे महत्वपूर्ण डेटा, फिर अभिलेखीय और कम महत्वपूर्ण (~ 300 जीबी)। पहले निर्यात लहर में, 300 जीबी से कम डेटा बना रहा। दस्तावेज़ तालिका (300GB) को भी बाहर रखा गया है। हम रात में नकल की प्रक्रिया शुरू करते हैं।

30 दिसंबर (शनिवार) दिन 9

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

इसके अलावा, इस बिंदु पर, डेटाबेस स्कीमा रिकवरी पूरी हो गई है।

घटना के परिणाम:

इस बिंदु पर, हमें लाइव डेटा का भारी नुकसान होता है।
यानी औपचारिक रूप से, हमारे पास डेटाबेस में कुछ डेटा हैं, लेकिन वास्तव में, उनका उपयोग करने या उन्हें कनेक्ट करने का कोई तरीका नहीं है, इसलिए हम डेटा के पूर्ण नुकसान के बारे में बात कर सकते हैं।
750,000 से अधिक रोगी प्रवेश पर खोया हुआ डेटा।

यह वास्तव में दुखद है!

• यह हमारे ग्राहक की प्रतिष्ठा के लिए एक बहुत बड़ा आघात है, जो नए अनुबंधों को समाप्त करने और अपने ग्राहकों को खोजने पर व्यवसाय में उनके लिए बड़ी समस्याएं बन सकता है।
• क्लिनिक के लिए बहुत अधिक डेटा खोने से गंभीर समस्याएं और जुर्माना हो सकता है, क्योंकि यह गोपनीय गोपनीयता वाला डेटा है, और शाब्दिक अर्थ में, लोगों के जीवन पर निर्भर करता है।

हम सोचने लगे कि इस स्थिति में हम क्या कर सकते हैं। वे सुराग खोजने के लिए हड्डियों द्वारा प्रणाली के माध्यम से छंटनी करने लगे।

15:16 सिस्टम के सभी पहलुओं का विश्लेषण करते हुए, हम समझते हैं कि हम ElasticSearch इंडेक्स से लापता डेटा को निकालने की कोशिश कर सकते हैं। बात यह है कि इलास्टिकसर्च इंडेक्स के गलत कॉन्फ़िगरेशन के कारण, यह न केवल उन फ़ील्ड्स को संग्रहीत करता है जिनके द्वारा पूर्ण-पाठ खोज की जाती है, बल्कि सामान्य रूप से सब कुछ, यानी वास्तव में डेटा की एक पूरी प्रतिलिपि होती है और हम सैद्धांतिक रूप से वहाँ से डेटा निकाल सकते हैं। के बारे में काम करता है और उन्हें वापस हमारे डेटाबेस में डाल दिया। यह आशा है कि डेटा अभी भी पुनर्प्राप्त करने में सक्षम होगा।

एक बग जिसे आप एक स्मारक रख सकते हैं!



18:00 डेटा को निकालने के लिए एक उपयोगिता जल्दी से लिखी गई थी, और कुछ घंटों के बाद हम सुनिश्चित करते हैं कि दृष्टिकोण काम करता है और डेटा को पुनर्स्थापित किया जा सकता है।

20:00 एक लिखित उपयोगिता की मदद से इलास्टिकसर्च से काम की बहाली शुरू हो गई है। काम किया दृष्टिकोण, हम काम पर डेटा को पुनर्स्थापित कर सकते हैं। समानांतर में, हम प्रत्येक कार्य के लिए दस्तावेज़ के नवीनतम संस्करण निकालना शुरू करते हैं।

31 दिसंबर (रविवार - नया साल) दिन 10

14:09 रात के दौरान, 188 811 काम बहाल किए गए।

20:13 हमारी सफलता को देखकर, क्लिनिक ने पुराने सर्वर से अधिकतम डेटा निकालने के लिए हमें समय देने के लिए, HP सेवा में सर्वर के हस्तांतरण को स्थगित करने का निर्णय लिया।
ऐसी खबरों के साथ, हमने नया साल मनाया))

01 जनवरी (सोमवार) को 11 वां दिन

11:23 घटना के बाद सिस्टम शुरू करने की तैयारी:

• App सर्वर पर पुन: कॉन्फ़िगर किया गया IIS;
• नए डेटाबेस सर्वर के साथ काम करने के लिए सभी आवश्यक सेवाओं को फिर से कॉन्फ़िगर किया गया;
• ट्रिगर, संग्रहीत कार्यविधियाँ, फ़ंक्शन पुनर्स्थापित किए गए।

14:28 फिर उन्होंने दस्तावेजों की तालिका की प्रतिलिपि बनाना शुरू किया, जो प्रारंभिक हस्तांतरण के दौरान बड़े आकार के कारण छोड़ दिया गया था।
- पुराना DB सर्वर फिर से बंद हो जाता है। जाहिर है, दस्तावेज़ तालिका भी दूषित है, यह इसके साथ है कि सभी रोगी जानकारी संग्रहीत है। सौभाग्य से, यह पूरी तरह से क्षतिग्रस्त नहीं है, हम इसके लिए अनुरोध कर सकते हैं, और जब हमारे लिए एक अनुरोध एक क्षतिग्रस्त रिकॉर्ड लौटाता है, उस समय सर्वर दुर्घटनाग्रस्त हो जाता है और बंद हो जाता है। हम कुछ डेटा निकाल सकते हैं।

तदनुसार, हम क्लाइंट को संकेत देते हैं, वे सर्वर को बढ़ाते हैं, और समानांतर में हम सिस्टम के लॉन्च के लिए नया डेटाबेस तैयार करना जारी रखते हैं।

18:01 डेटा के मुख्य भाग के हस्तांतरण के बाद सभी अखंडता बाधाओं की वसूली।

22:02 पूर्ण प्रतिबंधों की बहाली। हमने केवल कच्चे डेटा को अधिकतम स्थानांतरित कर दिया है। अखंडता बाधाओं की उपस्थिति हमारे कार्य को बहुत जटिल करेगी।

02 जनवरी (मंगलवार) दिन 12

05:52 पुराने DB सर्वर ने डॉक्यूमेंट को कॉपी करते हुए फिर से बंद कर दिया। उसे तुरंत उठाया जाता है ताकि हम काम करना जारी रख सकें।

09:00 बैच में लगभग 200,000 दस्तावेज (लगभग 20%) की वसूली संभव थी
हमने अलग-अलग पुनर्प्राप्ति विधियों का उपयोग करना शुरू किया: तालिका के अंत में कुछ क्षतिग्रस्त भाग पर ठोकर खाने तक, तालिका के अंत या शुरुआत से डेटा प्राप्त करने के लिए विभिन्न कॉलमों को छांटना।

13:42 तालिका में अभिलेखीय प्रतिलिपि बनाना शुरू किया - सौभाग्य से, यह क्षतिग्रस्त नहीं है।

17:08 सभी अभिलेखीय कार्य (491 380 टुकड़े) को बहाल किया।

सिस्टम लॉन्च करने के लिए तैयार है: उपयोगकर्ता नया काम बना और संसाधित कर सकते हैं।

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

• विभिन्न क्षेत्रों (आईडी, डेटाइम) द्वारा छंटनी;
• आरोही क्रमबद्ध, अवरोही;
• लाइनों के छोटे समूहों (1000, 100) के साथ काम करें;
• आईडी द्वारा रोजगार प्राप्त करना।

03 जनवरी (बुधवार) दिन 13

08:58 दस्तावेज़ों को पुनर्स्थापित करने की प्रक्रिया जारी रखी । सक्रिय, अधूरे काम के लिए ही दस्तावेज बहाल किए गए। इस बिंदु पर, बिना दस्तावेजों के 1000 कार्य (सक्रिय)।

11:38 सभी SQL जॉब्स को माइग्रेट किया

13:17 दस्तावेज़ों के बिना 5 काम करता है, 231 कोई काम नहीं करता है, लेकिन एक ऑडियो फ़ाइल है, आपको फिर से सिंक्रनाइज़ करने की आवश्यकता है।

04 जनवरी (गुरुवार) दिन 14

शेष कार्यों की मैन्युअल वसूली और सत्यापन शुरू हो गया है।
सिस्टम ऑनलाइन त्रुटियों की निगरानी और निर्धारण का काम करता है।

05 जनवरी (शुक्रवार) दिन 15

SSRS में रिपोर्ट प्रवास की योजना बनाई गई।
एक नए सर्वर पर स्थानांतरण संभव नहीं है, क्योंकि क्लिनिक ने SQL सर्वर का एक पुराना संस्करण स्थापित किया है और यह पुराने सर्वर से डेटाबेस को स्थानांतरित करने के लिए काम नहीं करेगा।

विकल्प:

• 2008 से 2008 R2 तक SQL सर्वर को अपग्रेड करें;
• सब कुछ खरोंच से कॉन्फ़िगर करें।

SQL सर्वर अद्यतन के लिए प्रतीक्षा करने का निर्णय लिया गया था।

09:21 पूर्ण कार्य के लिए दस्तावेजों की पृष्ठभूमि की बहाली शुरू हो गई है - प्रक्रिया लंबी है और इसमें कई दिन लगेंगे।

13:28 विभागों द्वारा दस्तावेजों की बहाली की प्राथमिकता में बदलाव।

18:18 क्लिनिक ने SMTP, मेल सेटअप तक पहुँच दी

परिणाम:

• लगभग सभी डेटा को बहाल कर दिया गया (केवल 5 नौकरियां खो गईं);
• ऐसी स्थितियों को रोकने के लिए डेटाबेस रखरखाव पर सिफारिशें जारी की गईं;
• डेटाबेस बैकअप SQL सर्वर का उपयोग कर कॉन्फ़िगर किया गया है;
• हमारी ओर से बैकअप की अतिरिक्त निगरानी, ​​विफल होने की स्थिति में अलर्ट।