2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
यथा वयं सर्वे जानीमः, MySQL प्राथमिकः माध्यमिकः च आँकडाधाराः (द्वौ नोड्) सामान्यतया अतुल्यकालिकप्रतिकृतिः अर्धसमकालिकप्रतिकृतिः (Semi-Sync) च माध्यमेन उच्चदत्तांशउपलब्धतां प्राप्नुवन्ति तथापि सङ्गणककक्षजालविफलता तथा होस्टहैङ्गअप इत्यादिषु असामान्यपरिदृश्येषु प्राथमिक-माध्यमिक-आर्किटेक्चरयोः एचए-स्विचिंग्-पश्चात् गम्भीरसमस्यानां सामना भविष्यति (RPO!=0 इति उच्यते) ।अतः यावत् व्यावसायिकदत्तांशस्य महत्त्वं निश्चितं भवति तावत् MySQL प्राथमिकं माध्यमिकं च आर्किटेक्चरं (द्वौ नोड्) सह दत्तांशकोश-उत्पादं न चिन्वन्तु RPO=0 इत्यनेन सह बहुप्रतिलिपि-आर्किटेक्चरं चयनं अनुशंसितम्
MySQL समुदायः, RPO=0 इत्यनेन सह बहु-प्रति-प्रौद्योगिक्याः विकासस्य विषये:
PolarDB-X केन्द्रीकृतस्य वितरितस्य च एकीकरणस्य अवधारणा: आँकडानोड् DN इत्यस्य उपयोगः स्वतन्त्रतया केन्द्रीकृतस्य (मानकसंस्करणस्य) रूपस्य रूपेण कर्तुं शक्यते, यत् एकान्तदत्तांशकोशरूपेण सह पूर्णतया संगतम् अस्ति यदा व्यवसायः एतावत्पर्यन्तं वर्धते यत्र वितरितविस्तारस्य आवश्यकता भवति तदा वास्तुकला स्थाने वितरितरूपेण उन्नयनं भवति, तथा च वितरितघटकाः मूलदत्तांशनोडैः सह निर्विघ्नतया सम्बद्धाः भवन्ति अनुप्रयोगपक्षे दत्तांशप्रवासस्य परिवर्तनस्य वा आवश्यकता नास्ति , तथा च भवान् वितरणस्य आनन्दं लब्धुं शक्नोति ।"केन्द्रीकृत वितरित एकीकरण"।
MySQL इत्यस्य MGR तथा PolarDB-X इत्यस्य मानकसंस्करणं DN इत्येतौ द्वौ अपि निम्नतमसिद्धान्तात् Paxos प्रोटोकॉलस्य उपयोगं कुर्वन्ति अतः वास्तविकप्रयोगे विशिष्टानि प्रदर्शनानि भेदाः च के सन्ति? अस्मिन् लेखे वास्तुकलातुलना, प्रमुखभेदाः, परीक्षणतुलना च पक्षाः विस्तरेण वर्णिताः सन्ति ।
MGR/DN संक्षिप्तविवरणम् : MGR MySQL MGR इत्यस्य तकनीकीरूपं प्रतिनिधियति, तथा च DN PolarDB-X एकल DN केन्द्रीकृतस्य (मानकसंस्करणस्य) तकनीकीरूपं प्रतिनिधियति
विस्तृतं तुलनात्मकं विश्लेषणं तुल्यकालिकं दीर्घं भवति, अतः भवान् प्रथमं सारांशं निष्कर्षं च पठितुं शक्नोति यदि भवान् रुचिं लभते तर्हि सारांशस्य अनुसरणं कृत्वा अनन्तरं लेखेषु सूचकान् अन्वेष्टुं शक्नोति।
MySQL MGR सामान्यव्यापाराणां कम्पनीनां च कृते अनुशंसितः नास्ति यतोहि तस्य सम्यक् उपयोगाय व्यावसायिकं तकनीकीज्ञानं तथा च संचालन-रक्षणदलस्य आवश्यकता भवति अयं लेखः MySQL MGR इत्यस्य त्रीणि "गुप्तजालानि" अपि प्रदर्शयति ये दीर्घकालं यावत् उद्योगे प्रचलन्ति : १.
MySQL MGR इत्यनेन सह तुलने PolarDB-X Paxos इत्यस्य आँकडा-सङ्गतिः, क्रॉस्-कम्प्यूटर-कक्ष-आपदा-पुनर्प्राप्तिः, नोड्-सञ्चालनं, अनुरक्षणं च इति दृष्ट्या MGR-सदृशानि जालानि नास्ति तथापि आपदा-पुनर्प्राप्ति-विषये अपि अस्य केचन लघु-लघु-लघुताः, लाभाः च सन्ति
MGR/DN संक्षिप्तनाम विवरणम् : १.
MGR एकल-मास्टर-बहु-मास्टर-मोड् समर्थयति, तथा च MySQL इत्यस्य प्रतिकृति-प्रणाल्याः पूर्णतया पुनः उपयोगं करोति, यत्र Event, Binlog & Relaylog, Apply, Binlog Apply Recovery, GTID च सन्ति । DN इत्यस्मात् मुख्यः अन्तरः अस्ति यत् MGR लेनदेन-लॉग-बहुमतस्य सहमति-प्राप्त्यर्थं प्रवेशबिन्दुः मुख्य-दत्तांशकोश-व्यवहारस्य प्रतिबद्धतायाः पूर्वं भवति ।
MGR उपर्युक्तप्रक्रियाम् अङ्गीकुर्वति तस्य कारणं यत् MGR पूर्वनिर्धारितरूपेण बहु-मास्टर-मोड् मध्ये अस्ति, अतः एकस्मिन् Paxos Group इत्यस्मिन् अनुयायी नोड् प्रथमं RelayLog इत्यत्र परिवर्तयितुं, ततः संयोजनं कर्तुं च आवश्यकम् it with the write transaction it receives as the leader to submit , द्विचरणीयसमूहप्रदानप्रक्रियायां अन्तिमव्यवहारं प्रस्तुतुं Binlog सञ्चिका उत्पादिता भवति ।
DN MySQL इत्यस्य मूलभूतदत्तांशसंरचनायाः कार्यस्तरीयसङ्केतस्य च पुनः उपयोगं करोति, परन्तु बहुमतप्रतिकृतिस्य स्थितियन्त्रतन्त्रस्य च स्वस्य समुच्चयस्य निर्माणार्थं X-Paxos प्रोटोकॉलेन सह लॉगप्रतिकृतिं, लॉगप्रबन्धनं, लॉगप्लेबैकं, क्रैशपुनर्प्राप्तिः च निकटतया एकीकृत्य MGR इत्यस्मात् मुख्यः अन्तरः अस्ति यत् DN लेनदेन-लॉग-बहुमतस्य सहमति-प्राप्त्यर्थं प्रवेशबिन्दुः मुख्य-दत्तांशकोश-व्यवहार-प्रस्तुति-प्रक्रियायाः समये भवति
अस्य डिजाइनस्य कारणं अस्ति यत् DN सम्प्रति केवलं एक-मास्टर-मोड् समर्थयति, अतः X-Paxos प्रोटोकॉल-स्तरस्य लॉग् स्वयं Binlog अस्ति Follower अपि Relay Log अपि परित्यजति, तथा च तस्य निरन्तर-लॉगस्य आँकडा-सामग्री अपि च लीडरस्य लॉग् अपि परित्यजति are equal to Same मूल्यम्।
म.जी.आर
DN
सैद्धान्तिकरूपेण, Paxos तथा Raft इत्येतयोः द्वयोः अपि आँकडानां स्थिरतां सुनिश्चितं कर्तुं शक्यते तथा च Crash Recovery इत्यस्य अनन्तरं बहुमतं प्राप्ताः लॉग्स् नष्टाः न भविष्यन्ति, परन्तु अद्यापि विशिष्टेषु परियोजनासु भेदाः सन्ति
म.जी.आर
XCOM पूर्णतया Paxos प्रोटोकॉलं समाहितं करोति, तस्य सर्वः प्रोटोकॉलदत्तांशः प्रथमं स्मृतौ संग्रहीतः भवति, पूर्वनिर्धारितरूपेण, बहुमतं प्राप्तुं लेनदेनस्य लॉग-स्थायित्वस्य आवश्यकता नास्ति । यत्र अधिकांशः पाई अधः भवति तथा च लीडरः विफलः भवति तस्मिन् सन्दर्भे RPO != 0 इत्यस्य गम्भीरः समस्या भविष्यति ।अत्यन्तं परिदृश्यं कल्पयतु : १.
समुदायस्य पूर्वनिर्धारितमापदण्डानां अन्तर्गतं, बहुसंख्यकव्यवहारस्य लॉग-स्थायित्वस्य आवश्यकता नास्ति तथा च RPO=0 इत्यस्य गारण्टीं न ददाति । निरपेक्ष RPO=0 सुनिश्चित्य, भवद्भिः पैरामीटर् group_replication_consistency विन्यस्तं कर्तव्यं यत् पठन-लेखन-सङ्गतिं AFTER -इत्यत्र नियन्त्रयति तथापि, अस्मिन् सन्दर्भे, 1.5 RTT संजाल-ओवरहेडस्य अतिरिक्तं, लेनदेनस्य बहुमतं प्राप्तुं log IO-ओवरहेडस्य आवश्यकता भविष्यति, । तथा प्रदर्शनम् अतीव दुर्बलं भविष्यति।
DN
PolarDB-X DN वितरितप्रोटोकॉलं कार्यान्वितुं X-Paxos इत्यस्य उपयोगं करोति तथा च MySQL इत्यस्य Group Commit प्रक्रियायाः गभीररूपेण बद्धः भवति यदा लेनदेनं प्रस्तुतं भवति तदा बहुमतस्य वास्तविकप्रदानस्य अनुमतितः पूर्वं स्थापनस्य स्थायित्वस्य च पुष्टिः आवश्यकी भवति अत्र अधिकांशं डिस्कस्थापनं मुख्यपुस्तकालयस्य Binlog स्थापनं निर्दिशति स्टैण्डबाई पुस्तकालयस्य IO थ्रेड् मुख्यपुस्तकालयस्य लॉग् प्राप्य स्थायित्वार्थं स्वस्य Binlog इत्यत्र लिखति । अतः चरमपरिदृश्येषु सर्वे नोड् विफलाः भवन्ति चेदपि दत्तांशः नष्टः न भविष्यति तथा च RPO=0 गारण्टी कर्तुं शक्यते ।
आरटीओ समयः प्रणाल्याः एव शीतपुनर्प्रारम्भस्य समयस्य उपरिभागेन सह निकटतया सम्बद्धः भवति, यत् विशिष्टमूलकार्येषु प्रतिबिम्बितम् अस्ति:दोषपरिचयतन्त्रम्->दुर्घटनापुनर्प्राप्तितन्त्रम्->मास्टरचयनतन्त्रम्->लॉगसन्तुलनम्
म.जी.आर
DN
म.जी.आर
DN
एक-मास्टर-मोड् मध्ये, MGR इत्यस्य XCOM तथा DN X-Paxos, एकः सशक्तः लीडर-मोड्, लीडरस्य चयनार्थं समानं मूलभूतं सिद्धान्तं अनुसरति - येषां लॉग्स् क्लस्टरेन सहमताः सन्ति, ते पुनः रोल कर्तुं न शक्यन्ते परन्तु यदा असहमति-लॉगस्य विषयः आगच्छति तदा भेदाः सन्ति
म.जी.आर
DN
लॉग् समीकरणस्य अर्थः अस्ति यत् प्राथमिक-द्वितीयक-दत्तांशकोशयोः मध्ये लॉग्-मध्ये लॉग्-प्रतिकृति-विलम्बः भवति, तथा च गौण-दत्तांशकोषस्य लॉग्-समीकरणस्य आवश्यकता वर्तते पुनः आरब्धानां पुनर्स्थापितानां च नोड्-समूहानां कृते पुनर्प्राप्तिः प्रायः स्टैण्डबाई-दत्तांशकोशेन आरभ्यते, मुख्यदत्तांशकोशेन सह तुलने च लॉग्-प्रतिकृतिविलम्बः पूर्वमेव अभवत्, तथा च लॉग्-इत्येतत् मुख्यदत्तांशकोशेन सह गृहीतुं आवश्यकम् ये नोड्स् भौतिकरूपेण लीडरतः दूराः सन्ति, तेषां कृते बहुमतं प्राप्तुं प्रायः तेषां सह किमपि सम्बन्धः नास्ति, तेषां सर्वदा प्रतिकृति-लॉग्-विलम्बः भवति, ते च सर्वदा लॉग्-सङ्गतिं कुर्वन्ति एतेषु परिस्थितिषु लॉगप्रतिकृतिविलम्बस्य समये समाधानं सुनिश्चित्य विशिष्टं अभियांत्रिकीकार्यन्वयनस्य आवश्यकता भवति ।
म.जी.आर
DN
स्टैण्डबाई डाटाबेस् प्लेबैक् विलम्बः मुख्यदत्तांशकोशे समानः व्यवहारः सम्पन्नः भवति तथा च स्टैण्डबाई दत्तांशकोशे व्यवहारः प्रयुक्तः भवति इति समयस्य मध्ये विलम्बः अस्ति अपवादः भवति चेत् स्टैण्डबाई-दत्तांशकोशस्य स्वस्य दत्तांश-अनुप्रयोगं पूर्णं कर्तुं कियत्कालं भवति तथा च पठन-लेखन-सेवाः प्रदातुं कियत्कालं भवति इति प्रभावितं करोति ।
म.जी.आर
DN
बृहत् लेनदेनं न केवलं साधारणव्यवहारस्य प्रस्तुतीकरणं प्रभावितं करोति, अपितु वितरितप्रणाल्यां सम्पूर्णस्य वितरितप्रोटोकॉलस्य स्थिरतां अपि प्रभावितं करोति गम्भीरप्रसङ्गेषु बृहत् लेनदेनेन सम्पूर्णं समूहं दीर्घकालं यावत् अनुपलब्धं भविष्यति
म.जी.आर
DN
म.जी.आर
DN
म.जी.आर | DN | ||
प्रोटोकॉल दक्षता | लेनदेन प्रस्तुतीकरण समय | १.५~२.५ आरटीटी | १ आरटीटी |
बहुमत दृढ़ता | XCOM स्मृति रक्षतु | बिन्लॉग दृढता | |
विश्वसनीयता | आरपीओ=0 | पूर्वनिर्धारितरूपेण गारण्टी नास्ति | पूर्णतया गारण्टीकृतम् |
दोषपरिचयः | सर्वे नोड् परस्परं जाँचयन्ति, जालभारः अधिकः भवति हृदयस्पन्दनचक्रं समायोजितुं न शक्यते | मुख्यनोड् समये समये अन्येषां नोड्-परीक्षणं करोति हृदयस्पन्दनचक्रमापदण्डाः समायोज्यः भवन्ति | |
बहुमत पतन पुनर्प्राप्ति | हस्त हस्तक्षेप | स्वचालित पुनर्प्राप्ति | |
अल्पसंख्यक दुर्घटना पुनर्प्राप्ति | अधिकांशतया स्वचालितं पुनर्प्राप्तिः, विशेषपरिस्थितौ हस्तहस्तक्षेपः | स्वचालित पुनर्प्राप्ति | |
स्वामिनं चिनुत | चयनस्य क्रमं स्वतन्त्रतया निर्दिशन्तु | चयनस्य क्रमं स्वतन्त्रतया निर्दिशन्तु | |
लॉग टाई | पश्चात्तापाः लॉग्स् XCOM 1GB cache अतिक्रमितुं न शक्नुवन्ति | BInlog सञ्चिकाः न विलोप्यन्ते | |
स्टैण्डबाई डाटाबेस प्लेबैक विलम्ब | द्वौ चरणौ + द्विगुणं एकं, अतीव मन्दम् | एकं चरणं + द्विगुणं शून्यं, द्रुततरम् | |
बृहत् व्यापार | पूर्वनिर्धारितसीमा १४३MB तः अधिका नास्ति | आकारसीमा नास्ति | |
आवेदनपत्रं | उच्च उपलब्धता व्ययः | पूर्णतया कार्यात्मकाः त्रीणि प्रतिकृतयः, ३ प्रतिकृतयः दत्तांशसञ्चयस्य उपरि | लॉगर लॉग् प्रतिलिपिः, दत्तांशसञ्चयस्य २ प्रतियाः |
केवलं पठनीयः नोडः | स्वामी-दासप्रतिकृतिना सह कार्यान्वितम् | प्रोटोकॉलः Leaner केवलं पठनीयप्रतिलिपि कार्यान्वयनेन सह आगच्छति |
MGR इत्यस्य आरम्भः MySQL 5.7.17 इत्यस्मिन् कृतः, परन्तु अधिकानि MGR-सम्बद्धानि विशेषतानि केवलं MySQL 8.0 इत्यत्र एव उपलभ्यन्ते, तथा च MySQL 8.0.22 तथा ततः परं संस्करणेषु समग्रं प्रदर्शनं अधिकं स्थिरं विश्वसनीयं च भविष्यति अतः वयं तुलनात्मकपरीक्षणार्थं द्वयोः पक्षयोः नवीनतमं संस्करणं ८.०.३२ चयनं कृतवन्तः ।
PolarDB-X DN तथा MySQL MGR इत्येतयोः तुलनात्मकपरीक्षणस्य समये परीक्षणवातावरणेषु, संकलनविधिषु, परिनियोजनविधिषु, संचालनमापदण्डेषु, परीक्षणविधिषु च भेदाः सन्ति इति विचार्य, येन परीक्षणतुलनादत्तांशः अशुद्धः भवितुम् अर्हति, अयं लेखः विविधविवरणेषु केन्द्रितः भविष्यति .
परीक्षणस्य सज्जता | PolarDB-X DN | MySQL MGR [1] 1.1. |
हार्डवेयर वातावरण | 96C 754GB स्मृतिः SSD डिस्कः च सह समानं भौतिकयन्त्रं उपयुज्य | |
प्रचालन प्रणाली | लिनक्स 4.9.168-019.ali3000.alios7.x86_64 | |
कर्नेल् संस्करणम् | समुदायसंस्करणं 8.0.32 आधारितं कर्नेल् आधाररेखां उपयुज्य | |
संकलन विधि | समानेन RelWithDebInfo इत्यनेन सह संकलनं कुर्वन्तु | |
संचालन पैरामीटर्स | समानविनिर्देशैः पैरामीटरैः च सह 32C128G विक्रेतुं समान PolarDB-X आधिकारिकजालस्थलस्य उपयोगं कुर्वन्तु | |
परिनियोजनविधिः | एकल मास्टर मोड |
टीका:
दत्तांशकोशस्य चयनं कुर्वन् प्रथमं सर्वेषां ध्यानं कार्यप्रदर्शनपरीक्षणम् अस्ति । अत्र वयं OLTP परिदृश्येषु कार्यप्रदर्शनपरीक्षणं कर्तुं 16 सारणीनिर्माणार्थं, प्रत्येकस्मिन् 10 मिलियनदत्तांशयुक्तानि, तथा च भिन्न-भिन्न-OLTP-परिदृश्येषु भिन्न-भिन्न-समवर्ती-स्थितौ द्वयोः कार्यक्षमतायाः परीक्षणं तुलनां च कर्तुं आधिकारिक-सिस्बेन्च-उपकरणस्य उपयोगं कुर्मःवास्तविकनियोजनस्य भिन्नानि परिस्थितयः विचार्य वयं क्रमशः निम्नलिखितचतुर्णां परिनियोजनपरिदृश्यानां अनुकरणं कुर्मः:
दृष्टान्तरूपेण दर्शयतु : १.
क. चतुर्णां परिनियोजनपरिदृश्यानां कार्यप्रदर्शनस्य क्षैतिजतुलनं विचारयन्तु, त्रीणि स्थानानि च त्रीणि केन्द्राणि सर्वे 3 प्रतिकृतीनां परिनियोजनविधिं स्वीकुर्वन्ति।
ख परिनियोजन परिदृश्यम् .
1 | 4 | 16 | 64 | 256 | ||
oltp_पठनमात्रम् | MGR_1 | 688.42 | 2731.68 | 6920.54 | 11492.88 | 14561.71 |
MGR_0 | 699.27 | 2778.06 | 7989.45 | 11590.28 | 15038.34 | |
DN | 656.69 | 2612.58 | 7657.03 | 11328.72 | 14771.12 | |
MGR_0 बनाम MGR_1 | 1.58% | 1.70% | 15.45% | 0.85% | 3.27% | |
डीएन बनाम एमजीआर_1 | -4.61% | -4.36% | 10.64% | -1.43% | 1.44% | |
डीएन बनाम एमजीआर_0 | -6.09% | -5.96% | -4.16% | -2.26% | -1.78% | |
oltp_पठ_लिखना | MGR_1 | 317.85 | 1322.89 | 3464.07 | 5052.58 | 6736.55 |
MGR_0 | 117.91 | 425.25 | 721.45 | 217.11 | 228.24 | |
DN | 360.27 | 1485.99 | 3741.36 | 5460.47 | 7536.16 | |
MGR_0 बनाम MGR_1 | -62.90% | -67.85% | -79.17% | -95.70% | -96.61% | |
डीएन बनाम एमजीआर_1 | 13.35% | 12.33% | 8.00% | 8.07% | 11.87% | |
डीएन बनाम एमजीआर_0 | 205.55% | 249.44% | 418.59% | 2415.07% | 3201.86% | |
oltp_लेखन_मात्र | MGR_1 | 761.87 | 2924.1 | 7211.97 | 10374.15 | 16092.02 |
MGR_0 | 309.83 | 465.44 | 748.68 | 245.75 | 318.48 | |
DN | 1121.07 | 3787.64 | 7627.26 | 11684.37 | 15137.23 | |
MGR_0 बनाम MGR_1 | -59.33% | -84.08% | -89.62% | -97.63% | -98.02% | |
डीएन बनाम एमजीआर_1 | 47.15% | 29.53% | 5.76% | 12.63% | -5.93% | |
डीएन बनाम एमजीआर_0 | 261.83% | 713.78% | 918.76% | 4654.58% | 4652.96% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
टीपीएस तुलना | 1 | 4 | 16 | 64 | 256 | |
oltp_पठनमात्रम् | MGR_1 | 695.69 | 2697.91 | 7223.43 | 11699.29 | 14542.4 |
MGR_0 | 691.17 | 2708.6 | 7849.98 | 11636.94 | 14670.99 | |
DN | 645.11 | 2611.15 | 7628.39 | 11294.36 | 14647.22 | |
MGR_0 बनाम MGR_1 | -0.65% | 0.40% | 8.67% | -0.53% | 0.88% | |
डीएन बनाम एमजीआर_1 | -7.27% | -3.22% | 5.61% | -3.46% | 0.72% | |
डीएन बनाम एमजीआर_0 | -6.66% | -3.60% | -2.82% | -2.94% | -0.16% | |
oltp_पठ_लिखना | MGR_1 | 171.37 | 677.77 | 2230 | 3872.87 | 6096.62 |
MGR_0 | 117.11 | 469.17 | 765.64 | 813.85 | 812.46 | |
DN | 257.35 | 1126.07 | 3296.49 | 5135.18 | 7010.37 | |
MGR_0 बनाम MGR_1 | -31.66% | -30.78% | -65.67% | -78.99% | -86.67% | |
डीएन बनाम एमजीआर_1 | 50.17% | 66.14% | 47.82% | 32.59% | 14.99% | |
डीएन बनाम एमजीआर_0 | 119.75% | 140.01% | 330.55% | 530.97% | 762.86% | |
oltp_लेखन_मात्र | MGR_1 | 248.37 | 951.88 | 2791.07 | 5989.57 | 11666.16 |
MGR_0 | 162.92 | 603.72 | 791.27 | 828.16 | 866.65 | |
DN | 553.69 | 2173.18 | 5836.64 | 10588.9 | 13241.74 | |
MGR_0 बनाम MGR_1 | -34.40% | -36.58% | -71.65% | -86.17% | -92.57% | |
डीएन बनाम एमजीआर_1 | 122.93% | 128.30% | 109.12% | 76.79% | 13.51% | |
डीएन बनाम एमजीआर_0 | 239.85% | 259.96% | 637.63% | 1178.61% | 1427.92% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
टीपीएस तुलना | 1 | 4 | 16 | 64 | 256 | |
oltp_पठनमात्रम् | MGR_1 | 687.76 | 2703.5 | 7030.37 | 11580.36 | 14674.7 |
MGR_0 | 687.17 | 2744.41 | 7908.44 | 11535.35 | 14656 | |
DN | 657.06 | 2610.58 | 7591.21 | 11174.94 | 14545.45 | |
MGR_0 बनाम MGR_1 | -0.09% | 1.51% | 12.49% | -0.39% | -0.13% | |
डीएन बनाम एमजीआर_1 | -4.46% | -3.44% | 7.98% | -3.50% | -0.88% | |
डीएन बनाम एमजीआर_0 | -4.38% | -4.88% | -4.01% | -3.12% | -0.75% | |
oltp_पठ_लिखना | MGR_1 | 29.13 | 118.64 | 572.25 | 997.92 | 2253.19 |
MGR_0 | 26.94 | 90.8 | 313.64 | 419.17 | 426.7 | |
DN | 254.87 | 1146.57 | 3339.83 | 5307.85 | 7171.95 | |
MGR_0 बनाम MGR_1 | -7.52% | -23.47% | -45.19% | -58.00% | -81.06% | |
डीएन बनाम एमजीआर_1 | 774.94% | 866.43% | 483.63% | 431.89% | 218.30% | |
डीएन बनाम एमजीआर_0 | 846.07% | 1162.74% | 964.86% | 1166.28% | 1580.79% | |
oltp_लेखन_मात्र | MGR_1 | 30.81 | 145.54 | 576.61 | 1387.64 | 3705.51 |
MGR_0 | 28.68 | 108.86 | 387.48 | 470.5 | 476.4 | |
DN | 550.11 | 2171.64 | 5866.41 | 10381.72 | 14478.38 | |
MGR_0 बनाम MGR_1 | -6.91% | -25.20% | -32.80% | -66.09% | -87.14% | |
डीएन बनाम एमजीआर_1 | 1685.49% | 1392.13% | 917.40% | 648.16% | 290.73% | |
डीएन बनाम एमजीआर_0 | 1818.10% | 1894.89% | 1413.99% | 2106.53% | 2939.12% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
टीपीएस तुलना | 1 | 4 | 16 | 64 | 256 | |
oltp_पठनमात्रम् | MGR_1 | 688.49 | 2747.69 | 7853.91 | 11722.71 | 15292.73 |
MGR_0 | 687.66 | 2756.3 | 8005.11 | 11567.89 | 15055.69 | |
DN | 656.06 | 2600.35 | 7657.85 | 11227.56 | 14562.86 | |
MGR_0 बनाम MGR_1 | -0.12% | 0.31% | 1.93% | -1.32% | -1.55% | |
डीएन बनाम एमजीआर_1 | -4.71% | -5.36% | -2.50% | -4.22% | -4.77% | |
डीएन बनाम एमजीआर_0 | -4.60% | -5.66% | -4.34% | -2.94% | -3.27% | |
oltp_पठ_लिखना | MGR_1 | 26.01 | 113.98 | 334.95 | 693.34 | 2030.6 |
MGR_0 | 23.93 | 110.17 | 475.68 | 497.92 | 511.99 | |
DN | 122.06 | 525.88 | 1885.7 | 3314.9 | 5889.79 | |
MGR_0 बनाम MGR_1 | -8.00% | -3.34% | 42.02% | -28.19% | -74.79% | |
डीएन बनाम एमजीआर_1 | 369.28% | 361.38% | 462.98% | 378.11% | 190.05% | |
डीएन बनाम एमजीआर_0 | 410.07% | 377.34% | 296.42% | 565.75% | 1050.37% | |
oltp_लेखन_मात्र | MGR_1 | 27.5 | 141.64 | 344.05 | 982.47 | 2889.85 |
MGR_0 | 25.52 | 155.43 | 393.35 | 470.92 | 504.68 | |
DN | 171.74 | 535.83 | 1774.58 | 4328.44 | 9429.24 | |
MGR_0 बनाम MGR_1 | -7.20% | 9.74% | 14.33% | -52.07% | -82.54% | |
डीएन बनाम एमजीआर_1 | 524.51% | 278.30% | 415.79% | 340.57% | 226.29% | |
डीएन बनाम एमजीआर_0 | 572.96% | 244.74% | 351.15% | 819.15% | 1768.36% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
विभिन्ननियोजनविधिषु कार्यप्रदर्शनपरिवर्तनानां स्पष्टतया तुलनां कर्तुं वयं उपर्युक्तपरीक्षायां oltp_write_only परिदृश्यस्य अन्तर्गतं भिन्ननियोजनविधिनां अन्तर्गतं MGR तथा DN इत्येतयोः TPS आँकडानां चयनं कृतवन्तः सङ्गणककक्षपरीक्षादत्तांशस्य आधाररेखारूपेण उपयोगेन वयं गणनां कृतवन्तः तथा च पार-नगरनियोजनस्य समये कार्यप्रदर्शनपरिवर्तनस्य अन्तरं ज्ञातुं आधाररेखायाः तुलने भिन्न-भिन्न-नियोजन-विधिषु TPS-आँकडानां तुलनां कृतवान्
MGR_1 (256 समवर्ती) 1.1. | डी एन (२५६ समवर्ती) २. | एमजीआर इत्यस्य तुलने डीएन इत्यस्य कार्यप्रदर्शनस्य लाभाः | |
स एव सङ्गणककक्षः | 16092.02 | 15137.23 | -5.93% |
एकस्मिन् नगरे त्रीणि केन्द्राणि | 11666.16 (72.50%) | 13241.74 (87.48%) | +13.50% |
द्वौ स्थानौ त्रीणि केन्द्राणि च | 3705.51 (23.03%) | 14478.38 (95.64%) | +290.72% |
त्रीणि स्थानानि त्रीणि च केन्द्राणि | 2889.85 (17.96%) | 9429.24 (62.29%) | +226.28% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
वास्तविकप्रयोगे वयं न केवलं कार्यप्रदर्शनदत्तांशं प्रति ध्यानं दद्मः, अपितु कार्यप्रदर्शनस्य jitter इत्यत्र अपि ध्यानं दातुं प्रवृत्ताः भवेम । अन्ततः यदि जिटर रोलरकोस्टर इव भवति तर्हि वास्तविकः उपयोक्तृअनुभवः अतीव दुर्बलः भविष्यति । वयं TPS वास्तविकसमयनिर्गमदत्तांशस्य निरीक्षणं प्रदर्शयामः च यत् sysbenc उपकरणं स्वयं प्रदर्शनजिटरस्य उत्पादननिरीक्षणदत्तांशस्य समर्थनं न करोति, वयं तुलनासूचकरूपेण भिन्नतायाः गणितीयगुणकस्य उपयोगं कुर्मः:
256 समवर्ती oltp_read_write परिदृश्यं उदाहरणरूपेण गृहीत्वा वयं एकस्मिन् सङ्गणककक्षे, एकस्मिन् नगरे त्रीणि केन्द्राणि, द्वयोः स्थानयोः त्रीणि केन्द्राणि, तथा च MGR_1 (RPO<>0) तथा DN (RPO=0) इत्येतयोः TPS इत्यस्य सांख्यिकीयरूपेण विश्लेषणं कुर्मः त्रिषु स्थानेषु त्रीणि केन्द्राणि। वास्तविकः जिटर-ग्राफः निम्नलिखितरूपेण अस्ति, तथा च प्रत्येकस्य परिदृश्यस्य वास्तविकः जिटर-सूचकदत्तांशः निम्नलिखितरूपेण अस्ति ।
सी.वी | स एव सङ्गणककक्षः | एकस्मिन् नगरे त्रीणि केन्द्राणि | द्वौ स्थानौ त्रीणि केन्द्राणि च | त्रीणि स्थानानि त्रीणि च केन्द्राणि |
MGR_1 | 10.04% | 8.96% | 6.02% | 8.63% |
DN | 3.68% | 3.78% | 2.55% | 4.05% |
MGR_1/DN | 272.83% | 237.04% | 236.08% | 213.09% |
परीक्षणपरिणामात् द्रष्टुं शक्यते- १.
वितरितदत्तांशकोशस्य मूलविशेषता उच्चा उपलब्धता अस्ति । एकस्मिन् सङ्गणककक्षे एकेन मास्टरेन सह द्वौ बैकअपौ च नियोजितौ 3 नोड्स इत्यस्य विशिष्टनियोजनरूपस्य कृते वयं निम्नलिखितत्रिषु परिदृश्येषु उपयोगितापरीक्षां कर्तुं प्रयत्नम् अकरोम:
यदा भारः नास्ति तदा लीडरं मारयन्तु तथा च क्लस्टरस्य प्रत्येकस्य नोड् इत्यस्य स्थितिपरिवर्तनस्य निरीक्षणं कुर्वन्तु तथा च सः लेखनीयः अस्ति वा इति ।
म.जी.आर | DN | |
सामान्यतः आरभ्य | 0 | 0 |
नेतारं मारयतु | 0 | 0 |
असामान्यः नोडसमयः प्राप्तः | 5 | 5 |
३ नोड्स् २ नोड् यावत् न्यूनीकर्तुं समयः | 23 | 8 |
म.जी.आर | DN | |
सामान्यतः आरभ्य | 0 | 0 |
नेतारं मारयन्तु, स्वयमेव उपरि आकर्षयन्तु | 0 | 0 |
असामान्यः नोडसमयः प्राप्तः | 5 | 5 |
३ नोड्स् २ नोड् यावत् न्यूनीकर्तुं समयः | 23 | 8 |
२ नोड् पुनर्स्थापनम् ३ नोड् समयः | 37 | 15 |
परीक्षणपरिणामात् द्रष्टुं शक्यते यत् कोऽपि दबावस्य परिस्थितौ : १.
oltp_read_write परिदृश्ये 16 थ्रेड् इत्यस्य समवर्ती तनावपरीक्षां कर्तुं sysbench इत्यस्य उपयोगं कुर्वन्तु, चित्रे 10 तमे सेकेण्ड् मध्ये, मैन्युअल् रूपेण एकं स्टैण्डबाई नोड् मारयन्तु तथा च sysbench इत्यस्य वास्तविकसमयस्य आउटपुट् TPS आँकडानां अवलोकनं कुर्वन्तु ।
परीक्षणपरिणामचार्टात् द्रष्टुं शक्यते : १.
परीक्षणं निरन्तरं कुर्वन्तः वयं स्टैण्डबाई-दत्तांशकोशं पुनः आरभ्य पुनः स्थापयामः तथा च मुख्यदत्तांशकोशस्य TPS-दत्तांशस्य परिवर्तनं अवलोकयामः ।
परीक्षणपरिणामचार्टात् द्रष्टुं शक्यते : १.
MGR बहुमतविफलता RPO<>0 परिदृश्यस्य निर्माणार्थं वयं MGR इत्यत्र दोष-इञ्जेक्शन-परीक्षणं कर्तुं समुदायस्य स्वकीयायाः MTR Case पद्धतेः उपयोगं कुर्मः ।
- --echo
- --echo ############################################################
- --echo # 1. Deploy a 3 members group in single primary mode.
- --source include/have_debug.inc
- --source include/have_group_replication_plugin.inc
- --let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
- --let $rpl_group_replication_single_primary_mode=1
- --let $rpl_skip_group_replication_start= 1
- --let $rpl_server_count= 3
- --source include/group_replication.inc
-
- --let $rpl_connection_name= server1
- --source include/rpl_connection.inc
- --let $server1_uuid= `SELECT @@server_uuid`
- --source include/start_and_bootstrap_group_replication.inc
-
- --let $rpl_connection_name= server2
- --source include/rpl_connection.inc
- --source include/start_group_replication.inc
-
- --let $rpl_connection_name= server3
- --source include/rpl_connection.inc
- --source include/start_group_replication.inc
-
- --echo
- --echo ############################################################
- --echo # 2. Init data
- --let $rpl_connection_name = server1
- --source include/rpl_connection.inc
- CREATE TABLE t1 (c1 INT PRIMARY KEY);
- INSERT INTO t1 VALUES(1);
-
- --source include/rpl_sync.inc
- SELECT * FROM t1;
-
- --let $rpl_connection_name = server2
- --source include/rpl_connection.inc
- SELECT * FROM t1;
-
- --let $rpl_connection_name = server3
- --source include/rpl_connection.inc
- SELECT * FROM t1;
-
- --echo
- --echo ############################################################
- --echo # 3. Mock crash majority members
-
- --echo # server 2 wait before write relay log
- --let $rpl_connection_name = server2
- --source include/rpl_connection.inc
- SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
-
- --echo # server 3 wait before write relay log
- --let $rpl_connection_name = server3
- --source include/rpl_connection.inc
- SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
-
-
- --echo # server 1 commit new transaction
- --let $rpl_connection_name = server1
- --source include/rpl_connection.inc
- INSERT INTO t1 VALUES(2);
- # server 1 commit t1(c1=2) record
- SELECT * FROM t1;
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- --echo # server 1 crash
- --source include/kill_mysqld.inc
-
- --echo # sleep enough time for electing new leader
- sleep 60;
-
- --echo
- --echo # server 3 check
- --let $rpl_connection_name = server3
- --source include/rpl_connection.inc
- SELECT * FROM t1;
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- --echo # server 3 crash and restart
- --source include/kill_and_restart_mysqld.inc
-
- --echo # sleep enough time for electing new leader
- sleep 60;
-
- --echo
- --echo # server 2 check
- --let $rpl_connection_name = server2
- --source include/rpl_connection.inc
- SELECT * FROM t1;
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- --echo # server 2 crash and restart
- --source include/kill_and_restart_mysqld.inc
-
- --echo # sleep enough time for electing new leader
- sleep 60;
-
- --echo
- --echo ############################################################
- --echo # 4. Check alive members, lost t1(c1=2) record
-
- --echo # server 3 check
- --let $rpl_connection_name= server3
- --source include/rpl_connection.inc
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- --echo # server 3 lost t1(c1=2) record
- SELECT * FROM t1;
-
- --echo
- --echo # server 2 check
- --let $rpl_connection_name = server2
- --source include/rpl_connection.inc
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- --echo # server 2 lost t1(c1=2) record
- SELECT * FROM t1;
- !include ../my.cnf
-
- [mysqld.1]
- loose-group_replication_member_weight=100
-
- [mysqld.2]
- loose-group_replication_member_weight=90
-
- [mysqld.3]
- loose-group_replication_member_weight=80
-
- [ENV]
- SERVER_MYPORT_3= @mysqld.3.port
- SERVER_MYSOCK_3= @mysqld.3.socket
केस रनिंग् परिणामाः निम्नलिखितरूपेण सन्ति ।
-
- ############################################################
- # 1. Deploy a 3 members group in single primary mode.
- include/group_replication.inc [rpl_server_count=3]
- Warnings:
- Note #### Sending passwords in plain text without SSL/TLS is extremely insecure.
- Note #### Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
- [connection server1]
- [connection server1]
- include/start_and_bootstrap_group_replication.inc
- [connection server2]
- include/start_group_replication.inc
- [connection server3]
- include/start_group_replication.inc
-
- ############################################################
- # 2. Init data
- [connection server1]
- CREATE TABLE t1 (c1 INT PRIMARY KEY);
- INSERT INTO t1 VALUES(1);
- include/rpl_sync.inc
- SELECT * FROM t1;
- c1
- 1
- [connection server2]
- SELECT * FROM t1;
- c1
- 1
- [connection server3]
- SELECT * FROM t1;
- c1
- 1
-
- ############################################################
- # 3. Mock crash majority members
- # server 2 wait before write relay log
- [connection server2]
- SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
- # server 3 wait before write relay log
- [connection server3]
- SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
- # server 1 commit new transaction
- [connection server1]
- INSERT INTO t1 VALUES(2);
- SELECT * FROM t1;
- c1
- 1
- 2
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- CHANNEL_NAME MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION MEMBER_COMMUNICATION_STACK
- group_replication_applier 127.0.0.1 13000 ONLINE PRIMARY 8.0.32 XCom
- group_replication_applier 127.0.0.1 13002 ONLINE SECONDARY 8.0.32 XCom
- group_replication_applier 127.0.0.1 13004 ONLINE SECONDARY 8.0.32 XCom
- # server 1 crash
- # Kill the server
- # sleep enough time for electing new leader
-
- # server 3 check
- [connection server3]
- SELECT * FROM t1;
- c1
- 1
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- CHANNEL_NAME MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION MEMBER_COMMUNICATION_STACK
- group_replication_applier 127.0.0.1 13002 ONLINE PRIMARY 8.0.32 XCom
- group_replication_applier 127.0.0.1 13004 ONLINE SECONDARY 8.0.32 XCom
- # server 3 crash and restart
- # Kill and restart
- # sleep enough time for electing new leader
-
- # server 2 check
- [connection server2]
- SELECT * FROM t1;
- c1
- 1
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- CHANNEL_NAME MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION MEMBER_COMMUNICATION_STACK
- group_replication_applier 127.0.0.1 13002 ONLINE PRIMARY 8.0.32 XCom
- group_replication_applier 127.0.0.1 13004 UNREACHABLE SECONDARY 8.0.32 XCom
- # server 2 crash and restart
- # Kill and restart
- # sleep enough time for electing new leader
-
- ############################################################
- # 4. Check alive members, lost t1(c1=2) record
- # server 3 check
- [connection server3]
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- CHANNEL_NAME MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION MEMBER_COMMUNICATION_STACK
- group_replication_applier NULL OFFLINE
- # server 3 lost t1(c1=2) record
- SELECT * FROM t1;
- c1
- 1
-
- # server 2 check
- [connection server2]
- select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
- CHANNEL_NAME MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION MEMBER_COMMUNICATION_STACK
- group_replication_applier NULL OFFLINE
- # server 2 lost t1(c1=2) record
- SELECT * FROM t1;
- c1
- 1
लुप्तसङ्ख्याः पुनः प्रदर्शयति इति प्रकरणस्य अनुमानतः तर्कः यथा भवति ।
उपर्युक्तप्रकरणस्य अनुसारं MGR कृते, यदा बहुसंख्यकं सर्वरं निष्क्रियं भवति तथा च मुख्यदत्तांशकोशः अनुपलब्धः भवति, तदा स्टैण्डबाईदत्तांशकोशस्य पुनर्स्थापनानन्तरं RPO<>0 इत्यस्य दत्तांशहानिः भविष्यति, तथा च सफलप्रतिबद्धतायाः अभिलेखः यः आसीत् मूलतः ग्राहकं प्रति प्रत्यागतं नष्टं भवति।
DN कृते बहुमतस्य प्राप्त्यर्थं बहुमतेन लॉग्स् स्थातुं आवश्यकं भवति, अतः उपर्युक्तपरिदृश्ये अपि दत्तांशः न नष्टः भविष्यति तथा च RPO=0 गारण्टी कर्तुं शक्यते
MySQL इत्यस्य पारम्परिक-सक्रिय-स्टैण्डबाई-मोड्-मध्ये, स्टैण्डबाई-दत्तांशकोशे सामान्यतया IO-धागाः अपि च Apply-धागाः सन्ति depends on the overhead of Apply playback of the standby database , अत्र वयं standby database playback delay भवेम ।
वयं oltp_write_only परिदृश्यस्य परीक्षणार्थं sysbench इत्यस्य उपयोगं कुर्मः, तथा च 100 समवर्ती तथा भिन्नसङ्ख्यायाः घटनानां अन्तर्गतं स्टैण्डबाई डाटाबेस् प्लेबैक् मध्ये विलम्बस्य अवधिं परीक्षयामःप्रतिकृतिः समाप्तः अस्ति वा इति निर्धारयितुं performance_schema.replication_applier_status_by_worker सारणीयाः APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP स्तम्भस्य निरीक्षणेन स्टैण्डबाई-दत्तांशकोश-प्लेबैक-विलम्बसमयः निर्धारयितुं शक्यते
परीक्षणपरिणामचार्टात् द्रष्टुं शक्यते : १.
म.जी.आर | DN | ||
प्रदर्शनम् | व्यवहारं पठन्तु | समतलम् | समतलम् |
व्यवहारं लिखत | प्रदर्शनं DN इव उत्तमं नास्ति यदा RPO<>0 यदा RPO=0 तदा प्रदर्शनं DN इत्यस्मात् दूरं न्यूनं भवति पार-नगरनियोजनप्रदर्शने २७%~८२% गम्भीररूपेण न्यूनता अभवत् । | लेखनव्यवहारस्य प्रदर्शनं MGR इत्यस्मात् बहु अधिकं भवति नगरान्तरनियोजनप्रदर्शनं ४% तः ३७% पर्यन्तं न्यूनीभवति । | |
जिटर | प्रदर्शनं जिटरं गम्भीरं भवति, जिटर-परिधिः 6~10% भवति | ३% इत्यत्र तुल्यकालिकरूपेण स्थिरः, केवलं एमजीआर इत्यस्य आर्धः एव | |
आरटीओ | मुख्यदत्तांशकोशः अधः अस्ति | ५s मध्ये असामान्यता आविष्कृता, २३s मध्ये द्वौ नोडौ यावत् न्यूनीकृता । | ५s मध्ये असामान्यता आविष्कृता, ८ मध्ये द्वौ नोडौ यावत् न्यूनीकृता । |
मुख्यपुस्तकालयं पुनः आरभत | ५ सेकेण्ड् मध्ये एकः असामान्यता आविष्कृता, ३७ सेकेण्ड् मध्ये त्रीणि नोड्स् पुनः स्थापितानि । | ५ सेकेण्ड् मध्ये असामान्यता ज्ञायते, १५ सेकेण्ड् मध्ये त्रीणि नोड्स् पुनः स्थापितानि भवन्ति । | |
बैकअप डाटाबेस डाउनटाइम | मुख्यदत्तांशकोशस्य यातायातः २० सेकेण्ड् यावत् ० यावत् पतितः । group_replication_paxos_single_leader इत्यस्य स्पष्टतया चालू कृत्वा तस्य उपशमनं कर्तुं शक्यते । | मुख्यदत्तांशकोशस्य निरन्तरं उच्चा उपलब्धता | |
स्टैण्डबाई डाटाबेस् पुनः आरम्भः | मुख्यदत्तांशकोशस्य यातायातः १० सेकेण्ड् यावत् ० यावत् पतितः । स्पष्टतया group_replication_paxos_single_leader इत्यस्य चालूकरणस्य अपि कोऽपि प्रभावः नास्ति । | मुख्यदत्तांशकोशस्य निरन्तरं उच्चा उपलब्धता | |
आर पी ओ | प्रकरणस्य पुनरावृत्तिः | RPO<>0 यदा बहुमतपक्षः अधः गच्छति प्रदर्शनं तथा RPO=0 इत्येतयोः द्वयोः अपि भवितुं न शक्यते । | आरपीओ = 0 |
स्टैण्डबाई डाटाबेस विलम्ब | बैकअप डाटाबेस प्लेबैक समय | सक्रिय-स्टैण्डबाई-योः मध्ये विलम्बः अतीव महत् भवति । प्रदर्शनं प्राथमिक-बैकअप-विलम्बं च एकस्मिन् समये प्राप्तुं न शक्यते । | समग्ररूपेण स्टैण्डबाई डाटाबेक् प्लेबैक् इत्यत्र व्ययितस्य कुलसमयः MGR इत्यस्य ४% भवति, यत् MGR इत्यस्य २५ गुणा भवति । |
पैरामीटर् | कील पैरामीटर |
| पूर्वनिर्धारितविन्यासः, विन्यासस्य अनुकूलनार्थं व्यावसायिकानां आवश्यकता नास्ति |
गहनतया तकनीकीविश्लेषणस्य कार्यप्रदर्शनस्य च तुलनायाः अनन्तरंPolarDB-X स्वविकसितस्य X-Paxos प्रोटोकॉलस्य अनुकूलितस्य डिजाइनस्य च श्रृङ्खलायाः सह DN इत्यनेन MySQL MGR इत्यस्य अपेक्षया कार्यप्रदर्शनस्य, सम्यक्त्वस्य, उपलब्धतायाः, संसाधनस्य उपरितनस्य च दृष्ट्या बहवः लाभाः प्रदर्शिताः तथापि MySQL पारिस्थितिकीतन्त्रे अपि महत्त्वपूर्णं स्थानं धारयति , विभिन्नानि परिस्थितयः यथा स्टैण्डबाई डाटाबेस आउटेज जिटर, क्रॉस्-मशीन रूम आपदा पुनर्प्राप्ति प्रदर्शनस्य उतार-चढावः, स्थिरता च विचारणीयाः अतः यदि भवान् MGR इत्यस्य सदुपयोगं कर्तुम् इच्छति तर्हि व्यावसायिकतकनीकी तथा संचालन तथा अनुरक्षणदलेन सुसज्जितः भवितुमर्हति समर्थनम्।
यदा बृहत्-परिमाणेन, उच्च-समवर्ती, उच्च-उपलब्धता-आवश्यकतानां सामना भवति तदा PolarDB-X भण्डारण-इञ्जिनस्य अद्वितीयाः तकनीकीलाभाः सन्ति, उत्तमं प्रदर्शनं च भवतिPolarDB-XDN-आधारितस्य केन्द्रीकृतस्य (मानकसंस्करणस्य) कार्याणां कार्यक्षमतायाः च मध्ये उत्तमः संतुलनः भवति, येन एतत् अत्यन्तं प्रतिस्पर्धात्मकं दत्तांशकोशसमाधानं भवति ।