CAP نظريو ورهايل نظام جي نظريي جو بنياد آهي. يقينن، ان جي چوڌاري تڪرار ختم نه ٿو ٿئي: ان ۾ وصفون نه آهن اصولي آهن، ۽ نه ڪو سخت ثبوت آهي ... تنهن هوندي به، مضبوطيء سان روزمره جي عام احساس جي پوزيشن تي بيٺو آهي™، اسان سمجهه سان سمجهون ٿا ته نظريو صحيح آهي.
فقط اها ڳالهه واضح ناهي ته اکر جي معنيٰ ”پي“ آهي. جڏهن ڪلستر ورهايو ويندو آهي، اهو فيصلو ڪري ٿو ته جواب نه ڏيو جيستائين ڪورم پورو نه ٿئي، يا موجود ڊيٽا واپس ڏي. ھن انتخاب جي نتيجن تي مدار رکندي، سسٽم کي CP يا AP جي طور تي درجه بندي ڪيو ويو آھي. Cassandra، مثال طور، ڪنهن به طريقي سان عمل ڪري سگهي ٿو، ان تي منحصر ناهي ته ڪلستر سيٽنگن تي، پر هر مخصوص درخواست جي پيٽرولن تي. پر جيڪڏهن سسٽم "P" نه آهي ۽ اهو ورهائي ٿو، پوء ڇا؟
هن سوال جو جواب ڪجهه غير متوقع آهي: هڪ CA ڪلستر ورهائي نٿو سگهي.
هي ڪهڙي قسم جو ڪلستر آهي جيڪو ورهائي نٿو سگهي؟
اهڙي ڪلستر جو هڪ لازمي وصف هڪ گڏيل ڊيٽا اسٽوريج سسٽم آهي. ڪيسن جي وڏي اڪثريت ۾، هن جو مطلب آهي هڪ SAN سان ڳنڍڻ، جيڪو CA حلن جي استعمال کي محدود ڪري ٿو وڏن ادارن کي SAN انفراسٽرڪچر کي برقرار رکڻ جي قابل. ساڳئي ڊيٽا سان ڪم ڪرڻ لاء ڪيترن ئي سرورن لاء، هڪ ڪلستر ٿيل فائل سسٽم گهربل آهي. اهڙا فائل سسٽم HPE (CFS)، Veritas (VxCFS) ۽ IBM (GPFS) پورٽ فوليو ۾ موجود آهن.
Oracle RAC
ريئل ايپليڪيشن ڪلستر آپشن پهريون ڀيرو 2001 ۾ Oracle 9i جي ڇڏڻ سان ظاهر ٿيو. اهڙي ڪلستر ۾، ڪيترن ئي سرور جا مثال ساڳي ڊيٽابيس سان ڪم ڪن ٿا.
Oracle ٻئي ڪلستر ٿيل فائل سسٽم ۽ ان جي پنهنجي حل سان ڪم ڪري سگھي ٿو - ASM، خودڪار اسٽوريج مئنيجمينٽ.
هر ڪاپي پنهنجي جرنل رکي ٿو. ٽرانزيڪشن تي عمل ڪيو ويو آهي ۽ هڪ مثال طرفان انجام ڏنو ويو آهي. جيڪڏهن هڪ مثال ناڪام ٿئي ٿو، هڪ بچيل ڪلستر نوڊس (مثال) ان جو لاگ پڙهي ٿو ۽ گم ٿيل ڊيٽا کي بحال ڪري ٿو - انهي سان دستيابي کي يقيني بڻائي ٿي.
سڀئي مثالون پنهنجي ڪيش کي برقرار رکندا آهن، ۽ ساڳيا صفحا (بلاڪ) هڪ ئي وقت ڪيترن ئي مثالن جي ڪيش ۾ رهجي سگهن ٿا. ان کان علاوه، جيڪڏهن هڪ مثال هڪ صفحي جي ضرورت آهي ۽ اهو ٻئي مثال جي ڪيش ۾ آهي، اهو ڊسڪ مان پڙهڻ جي بدران ڪيش فيوزن ميڪانيزم استعمال ڪندي پنهنجي پاڙيسري کان حاصل ڪري سگهي ٿو.
پر ڇا ٿيندو جيڪڏهن هڪ مثال کي ڊيٽا تبديل ڪرڻ جي ضرورت آهي؟
Oracle جي خصوصيت اها آهي ته ان وٽ وقف ٿيل بند ڪرڻ جي خدمت ناهي: جيڪڏهن سرور هڪ قطار کي بند ڪرڻ چاهي ٿو، ته پوءِ تالا رڪارڊ سڌو سنئون ميموري واري صفحي تي رکيل آهي جتي بند ٿيل قطار واقع آهي. هن طريقي جي مهرباني، Oracle monolithic ڊيٽابيس جي وچ ۾ ڪارڪردگي چيمپئن آهي: لاڪنگ سروس ڪڏهن به رڪاوٽ نه ٿيندي آهي. پر هڪ ڪلستر جي جوڙجڪ ۾، اهڙي فن تعمير کي شديد نيٽ ورڪ ٽرئفڪ ۽ خراب ٿيڻ جي ڪري سگھي ٿو.
هڪ دفعو هڪ رڪارڊ بند ڪيو ويندو آهي، هڪ مثال ٻين سڀني مثالن کي اطلاع ڏئي ٿو ته اهو صفحو جيڪو محفوظ ڪري ٿو اهو رڪارڊ هڪ خاص هولڊ آهي. جيڪڏهن ڪنهن ٻئي مثال کي ساڳئي صفحي تي رڪارڊ تبديل ڪرڻ جي ضرورت آهي، ان کي انتظار ڪرڻو پوندو جيستائين صفحي ۾ تبديليون انجام نه ڏنيون وڃن، اهو آهي، تبديلي جي معلومات ڊسڪ تي جرنل ڏانهن لکيل آهي (۽ ٽرانزيڪشن جاري رهي سگهي ٿو). اهو به ٿي سگهي ٿو ته هڪ صفحو ڪيترن ئي نقلن جي ترتيب سان تبديل ڪيو وڃي، ۽ پوء جڏهن صفحي کي ڊسڪ تي لکندو، توهان کي اهو معلوم ڪرڻو پوندو ته هن صفحي جي موجوده ورزن کي ڪير محفوظ ڪري ٿو.
بي ترتيب طور تي ساڳئي صفحن کي مختلف RAC نوڊس ۾ اپڊيٽ ڪرڻ ڊيٽابيس جي ڪارڪردگي کي ڊرامائي طور تي گھٽائڻ جو سبب بڻائيندو آهي، ان نقطي تائين جتي ڪلستر جي ڪارڪردگي هڪ مثال جي ڀيٽ ۾ گهٽ ٿي سگهي ٿي.
Oracle RAC جو صحيح استعمال ڊيٽا کي جسماني طور تي ورهاڱي ڪرڻ آهي (مثال طور، ورهاڱي واري ٽيبل ميڪانيزم کي استعمال ڪندي) ۽ تقسيم جي هر سيٽ تائين رسائي هڪ وقف نوڊ ذريعي. RAC جو بنيادي مقصد افقي اسڪيلنگ نه هو، پر غلطي رواداري کي يقيني بڻائڻ.
جيڪڏهن ڪو نوڊ دل جي ڌڙڪڻ جو جواب ڏيڻ بند ڪري ٿو، ته پوءِ اهو نوڊ جنهن ان کي معلوم ڪيو آهي اهو پهريان ڊسڪ تي ووٽنگ جو عمل شروع ڪري ٿو. جيڪڏهن غائب نوڊ هتي نوٽ نه ڪيو ويو آهي، پوء نوڊس مان هڪ ڊيٽا جي وصولي جي ذميواري تي وٺندو آهي:
- "منجمد" سڀئي صفحا جيڪي غائب نوڊ جي ڪيش ۾ هئا؛
- گم ٿيل نوڊ جي لاگز (ريڊو) کي پڙهي ٿو ۽ انهن لاگز ۾ رڪارڊ ڪيل تبديلين کي ٻيهر لاڳو ڪري ٿو، انهي سان گڏ چيڪ ڪري ٿو ته ڇا ٻين نوڊس صفحن جا وڌيڪ تازو ورزن تبديل ڪيا پيا وڃن؛
- التوا واري ٽرانزيڪشن کي واپس آڻيندي.
نوڊس جي وچ ۾ سوئچنگ کي آسان ڪرڻ لاء، Oracle وٽ هڪ خدمت جو تصور آهي - هڪ مجازي مثال. ھڪڙو مثال گھڻن خدمتن جي خدمت ڪري سگھي ٿو، ۽ ھڪڙي خدمت نوڊس جي وچ ۾ منتقل ڪري سگھي ٿو. هڪ ايپليڪيشن مثال طور ڊيٽابيس جي هڪ خاص حصي جي خدمت ڪري ٿي (مثال طور، گراهڪن جو هڪ گروپ) هڪ خدمت سان ڪم ڪري ٿو، ۽ ڊيٽابيس جي هن حصي جي ذميوار خدمت ٻئي نوڊ ڏانهن منتقل ٿئي ٿي جڏهن ڪو نوڊ ناڪام ٿئي ٿو.
ٽرانزيڪشن لاء IBM خالص ڊيٽا سسٽم
DBMS لاءِ ڪلسٽر حل 2009 ۾ بليو گينٽ پورٽ فوليو ۾ ظاهر ٿيو. نظرياتي طور تي، اهو متوازي سيسپلڪس ڪلستر جو جانشين آهي، "باقاعده" سامان تي ٺهيل آهي. 2009 ۾، DB2 pureScale هڪ سافٽ ويئر سوٽ جي طور تي جاري ڪيو ويو، ۽ 2012 ۾، IBM هڪ اوزار پيش ڪيو جنهن کي Pure Data Systems for Transactions سڏيو ويندو آهي. ان کي اينالائيٽڪس لاءِ خالص ڊيٽا سسٽم سان پريشان نه ٿيڻ گهرجي، جيڪو نيٽيزا جي نالي سان وڌيڪ ڪجهه ناهي.
پهرين نظر ۾، pureScale آرڪيٽيڪچر Oracle RAC سان ملندڙ جلندڙ آهي: ساڳئي طرح، ڪيترائي نوڊس هڪ عام ڊيٽا اسٽوريج سسٽم سان ڳنڍيل آهن، ۽ هر نوڊ پنهنجي پنهنجي ڊي بي ايم ايس مثال کي پنهنجي ميموري علائقن ۽ ٽرانزيڪشن لاگز سان هلائي ٿو. پر، Oracle جي برعڪس، DB2 وٽ هڪ وقف لاڪنگ سروس آهي جيڪا db2LLM* پروسيس جي هڪ سيٽ جي نمائندگي ڪري ٿي. ڪلستر جي ترتيب ۾، هي خدمت هڪ الڳ نوڊ تي رکيل آهي، جنهن کي Parallel Sysplex ۾ coupling facility (CF) ۽ Pure Data ۾ PowerHA سڏيو ويندو آهي.
PowerHA هيٺ ڏنل خدمتون مهيا ڪري ٿي:
- تالا مينيجر؛
- عالمي بفر ڪيش؛
- interprocess مواصلات جو علائقو.
PowerHA کان ڊيٽا کي ڊيٽابيس جي نوڊس ڏانهن منتقل ڪرڻ لاءِ ۽ واپس، ريموٽ ميموري جي رسائي استعمال ڪئي ويندي آهي، تنهن ڪري ڪلسٽر انٽر ڪنيڪٽ کي RDMA پروٽوڪول کي سپورٽ ڪرڻ گهرجي. PureScale Ethernet تي Infiniband ۽ RDMA ٻئي استعمال ڪري سگھن ٿا.
جيڪڏهن نوڊ کي هڪ صفحي جي ضرورت آهي، ۽ اهو صفحو ڪيش ۾ نه آهي، پوء نوڊ گلوبل ڪيش ۾ صفحي جي درخواست ڪري ٿو، ۽ صرف جيڪڏهن اهو موجود ناهي، ان کي ڊسڪ مان پڙهي ٿو. Oracle جي برعڪس، درخواست صرف PowerHA ڏانهن وڃي ٿي، ۽ پاڙيسري نوڊس ڏانهن نه.
جيڪڏهن هڪ مثال هڪ قطار کي تبديل ڪرڻ وارو آهي، اهو ان کي خاص موڊ ۾ بند ڪري ٿو، ۽ صفحو جتي قطار حصيداري موڊ ۾ واقع آهي. سڀئي تالا گلوبل تالا مينيجر ۾ رجسٽر ٿيل آهن. جڏهن ٽرانزيڪشن مڪمل ٿئي ٿي، نوڊ لاڪ مئنيجر ڏانهن هڪ پيغام موڪلي ٿو، جيڪو تبديل ٿيل صفحي کي گلوبل ڪيش ۾ نقل ڪري ٿو، لاڪ جاري ڪري ٿو، ۽ تبديل ٿيل صفحي کي ٻين نوڊس جي ڪيش ۾ غلط ڪري ٿو.
جيڪڏهن صفحو جنهن ۾ تبديل ٿيل قطار واقع آهي اڳ ۾ ئي بند ٿيل آهي، ته پوءِ لاڪ مئنيجر تبديل ٿيل صفحي کي نوڊ جي ميموري مان پڙهندو جنهن تبديلي ڪئي، لاڪ جاري ڪيو، تبديل ٿيل پيج کي ٻين نوڊس جي ڪيش ۾ باطل ڪري، ۽ پيج لاڪ کي نوڊ کي ڏيو جنهن ان جي درخواست ڪئي.
"گندي"، يعني تبديل ٿيل، صفحا ڊسڪ تي لکي سگھجن ٿا ٻنهي کي باقاعده نوڊ ۽ PowerHA (castout) کان.
جيڪڏهن PureScale Nodes مان هڪ ناڪام ٿئي ٿو، وصولي صرف انهن ٽرانزيڪشنن تائين محدود آهي جيڪي اڃا تائين ناڪامي جي وقت مڪمل نه ٿيا هئا: مڪمل ٽرانزيڪشن ۾ ان نوڊ پاران تبديل ٿيل صفحا PowerHA تي گلوبل ڪيش ۾ آهن. نوڊ ڪلستر ۾ سرورز مان ھڪڙي تي گھٽ ترتيب واري ترتيب ۾ ٻيهر شروع ٿئي ٿو، پوئتي پيل ٽرانزيڪشن کي رول ڪري ٿو ۽ لاڪ جاري ڪري ٿو.
PowerHA ٻن سرورن تي هلندو آهي ۽ ماسٽر نوڊ ان جي حالت کي هم وقت سازي سان نقل ڪري ٿو. جيڪڏهن پرائمري پاور ايڇ اي نوڊ ناڪام ٿئي ٿي، ڪلستر بيڪ اپ نوڊ سان هلائڻ جاري رکي ٿو.
يقينا، جيڪڏهن توهان هڪ واحد نوڊ ذريعي ڊيٽا سيٽ تائين رسائي ڪريو ٿا، ڪلستر جي مجموعي ڪارڪردگي وڌيڪ هوندي. PureScale اهو به نوٽيس ڪري سگهي ٿو ته ڊيٽا جي هڪ مخصوص حصي کي هڪ نوڊ ذريعي پروسيس ڪيو پيو وڃي، ۽ پوءِ ان علائقي سان لاڳاپيل سڀئي لاڪ، نوڊ ذريعي مقامي طور تي پروسيس ڪيا ويندا بغير PowerHA سان رابطي جي. پر جيئن ئي ايپليڪيشن ڪنهن ٻئي نوڊ ذريعي هن ڊيٽا تائين رسائي حاصل ڪرڻ جي ڪوشش ڪندي، سينٽرلائزڊ لاڪ پروسيسنگ ٻيهر شروع ٿيندي.
90٪ پڙهڻ ۽ 10٪ لکڻ جي ڪم لوڊ تي IBM جا اندروني تجربا، جيڪي حقيقي دنيا جي پيداوار جي ڪم جي لوڊ سان بلڪل ملندڙ جلندڙ آهن، تقريبن 128 نوڊس تائين لڪير اسڪيلنگ ڏيکاري ٿو. ٽيسٽ حالتون، بدقسمتي سان، ظاهر نه ڪيا ويا آهن.
HPE نان اسٽاپ SQL
Hewlett-Packard انٽرپرائز پورٽ فوليو پڻ ان جي پنهنجي انتهائي دستياب پليٽ فارم آهي. هي نان اسٽاپ پليٽ فارم آهي، جيڪو 1976 ۾ ٽنڊيم ڪمپيوٽرز طرفان مارڪيٽ ۾ جاري ڪيو ويو. 1997 ۾، ڪمپني کي Compaq پاران حاصل ڪيو ويو، جيڪو بدلي ۾ 2002 ۾ Hewlett-Packard سان ضم ٿي ويو.
نان اسٽاپ نازڪ ايپليڪيشنون ٺاهڻ لاءِ استعمال ڪيو ويندو آهي - مثال طور، HLR يا بئنڪ ڪارڊ پروسيسنگ. پليٽ فارم هڪ سافٽ ويئر ۽ هارڊويئر ڪمپليڪس (آلائينس) جي صورت ۾ پهچايو ويو آهي، جنهن ۾ ڪمپيوٽنگ نوڊس، ڊيٽا اسٽوريج سسٽم ۽ مواصلاتي سامان شامل آهن. ServerNet نيٽ ورڪ (جديد سسٽم ۾ - Infiniband) ٻنهي نوڊس جي وچ ۾ مٽائڻ ۽ ڊيٽا اسٽوريج سسٽم تائين رسائي لاء ڪم ڪري ٿو.
سسٽم جي شروعاتي ورزن ۾ ملڪيت وارا پروسيسرز استعمال ڪيا ويا جيڪي هڪ ٻئي سان هم وقت سازي ڪيا ويا: سڀني عملن کي ڪيترن ئي پروسيسرز پاران هم وقت سازي سان انجام ڏنو ويو، ۽ جيئن ئي پروسيسرز مان هڪ غلطي ڪئي، اهو بند ڪيو ويو، ۽ ٻيو ڪم جاري رهيو. بعد ۾ سسٽم روايتي پروسيسرز (پهريون MIPS، پوء Itanium ۽ آخر ۾ x86) ڏانهن تبديل ڪيو، ۽ ٻين ميڪانيزم کي هم وقت سازي لاء استعمال ڪرڻ شروع ڪيو:
- نياپا: هر سسٽم جي عمل ۾ هڪ "ڇايو" ٽوئن هوندو آهي، جنهن ۾ فعال عمل وقتي طور تي پيغام موڪليندو آهي ان جي حيثيت بابت؛ جيڪڏهن مکيه عمل ناڪام ٿئي ٿو، ڇانو عمل آخري پيغام طرفان طئي ٿيل لمحن کان ڪم ڪرڻ شروع ڪري ٿو؛
- ووٽنگ: اسٽوريج سسٽم ۾ هڪ خاص هارڊويئر جزو آهي جيڪو ڪيترن ئي هڪجهڙائي واري رسائي کي قبول ڪري ٿو ۽ انهن کي صرف ان صورت ۾ عمل ڪري ٿو جڏهن رسائي ملن؛ جسماني هم وقت سازي جي بدران، پروسيسر غير مطابقت سان هلن ٿا، ۽ انهن جي ڪم جا نتيجا صرف I / O لمحن تي مقابلو ڪيا ويا آهن.
1987 کان وٺي، هڪ تعلقي DBMS نان اسٽاپ پليٽ فارم تي هلندڙ آهي - پهريون SQL/MP، ۽ بعد ۾ SQL/MX.
سڄو ڊيٽابيس حصن ۾ ورهايل آهي، ۽ هر حصو پنهنجي ڊيٽا جي رسائي مئنيجر (ڊيم) جي عمل لاء ذميوار آهي. اهو مهيا ڪري ٿو ڊيٽا رڪارڊنگ، ڪيشنگ، ۽ لاڪنگ ميڪانيزم. ڊيٽا پروسيسنگ ايگزيڪيوٽر سرور جي پروسيسنگ ذريعي ڪئي ويندي آهي ساڳئي نوڊس تي هلندڙ ڊيٽا مينيجرز جي طور تي. SQL/MX شيڊولر ڪمن کي عملدارن جي وچ ۾ ورهائي ٿو ۽ نتيجن کي گڏ ڪري ٿو. جڏهن اتفاق ٿيل تبديليون ڪرڻ ضروري آهي، TMF (ٽرانزيڪشن مئنيجمينٽ فيڪلٽي) لائبريري پاران مهيا ڪيل ٻه-مرحلي ڪمٽ پروٽوڪول استعمال ڪيو ويندو آهي.
نان اسٽاپ SQL عملن کي ترجيح ڏئي سگھي ٿو ته جيئن ڊگھا تجزياتي سوال ٽرانزيڪشن جي عمل ۾ مداخلت نه ڪن. بهرحال، ان جو مقصد مختصر طور تي مختصر ٽرانزيڪشن جي پروسيسنگ آهي، ۽ تجزياتي نه. ڊولپر پنجن ”نائن“ جي سطح تي نان اسٽاپ ڪلسٽر جي دستيابي جي ضمانت ڏئي ٿو، يعني، ڊائون ٽائم صرف 5 منٽ في سال آهي.
ايس پي ھنا
HANA DBMS (1.0) جو پهريون مستحڪم رليز نومبر 2010 ۾ ٿيو، ۽ SAP ERP پيڪيج مئي 2013 ۾ HANA ۾ تبديل ٿي ويو. پليٽ فارم خريد ڪيل ٽيڪنالاجيز تي ٻڌل آهي: TREX سرچ انجڻ (سرچ ان ڪالمنر اسٽوريج)، P*TIME DBMS ۽ MAX DB.
لفظ "HANA" پاڻ هڪ مخفف آهي، اعلي ڪارڪردگي تجزياتي سامان. هي DBMS ڪوڊ جي صورت ۾ فراهم ڪيو ويو آهي جيڪو ڪنهن به x86 سرور تي هلائي سگهي ٿو، جڏهن ته، صنعتي تنصيب صرف تصديق ٿيل سامان تي اجازت ڏني وئي آهي. HP، Lenovo، Cisco، Dell، Fujitsu، Hitachi، NEC کان دستياب حل. ڪجھ Lenovo ترتيبون SAN کان سواء آپريشن جي اجازت ڏين ٿيون - ھڪڙي عام اسٽوريج سسٽم جو ڪردار مقامي ڊسڪ تي GPFS ڪلستر پاران ادا ڪيو ويندو آھي.
مٿي ڏنل پليٽ فارمن جي برعڪس، HANA هڪ ان-ميموري ڊي بي ايم ايس آهي، يعني بنيادي ڊيٽا جي تصوير RAM ۾ محفوظ ڪئي وئي آهي، ۽ صرف لاگس ۽ وقتي سنيپ شاٽ ڊسڪ تي لکيل آهن هڪ آفت جي صورت ۾ وصولي لاءِ.
هر HANA ڪلستر نوڊ ڊيٽا جي پنهنجي حصي لاءِ ذميوار هوندو آهي، ۽ ڊيٽا جو نقشو هڪ خاص جزو ۾ محفوظ ڪيو ويندو آهي - نالو سرور، ڪوآرڊينيٽر نوڊ تي واقع آهي. ڊيٽا نوڊس جي وچ ۾ نقل نه ڪئي وئي آهي. لاڪنگ جي معلومات پڻ هر نوڊ تي ذخيرو ٿيل آهي، پر سسٽم ۾ هڪ گلوبل ڊيڊ لاڪ ڊيڪٽر آهي.
جڏهن هڪ HANA ڪلائنٽ هڪ ڪلستر سان ڳنڍيندو آهي، اهو ان جي ٽوپولوجي کي ڊائون لوڊ ڪري ٿو ۽ پوء سڌو ڪنهن به نوڊ تائين رسائي ڪري سگهي ٿو، ان تي منحصر ڪري ٿو ته ڪهڙي ڊيٽا جي ضرورت آهي. جيڪڏهن هڪ ٽرانزيڪشن هڪ واحد نوڊ جي ڊيٽا کي متاثر ڪري ٿو، ته پوء ان کي مقامي طور تي ان نوڊ ذريعي عمل ڪري سگهجي ٿو، پر جيڪڏهن ڪيترن ئي نوڊس جي ڊيٽا تبديل ٿي وڃي ٿي، شروعات ڪندڙ نوڊ ڪوآرڊينيٽر نوڊ سان رابطو ڪري ٿو، جيڪو ورهايل ٽرانزيڪشن کي کوليو ۽ ان کي ترتيب ڏئي ٿو، ان کي استعمال ڪندي. بهتر ٿيل ٻه-مرحلي ڪمٽ پروٽوڪول.
ڪوآرڊينيٽر نوڊ نقل ڪيو ويو آهي، تنهنڪري جيڪڏهن ڪوآرڊينيٽر ناڪام ٿئي ٿو، بيڪ اپ نوڊ فوري طور تي ختم ڪري ٿو. پر جيڪڏهن ڊيٽا سان ڪو نوڊ ناڪام ٿئي ٿو، ته ان جي ڊيٽا تائين رسائي جو واحد طريقو نوڊ کي ٻيهر شروع ڪرڻ آهي. ضابطي جي طور تي، HANA ڪلستر هڪ اسپيئر سرور کي برقرار رکڻ لاء ان تي جلدي ممڪن طور تي گم ٿيل نوڊ کي ٻيهر شروع ڪرڻ لاء.
جو ذريعو: www.habr.com