प्रौद्योगिकी साझेदारी

डाटाबेस आपदा पुनर्प्राप्ति |.MySQL MGR तथा Alibaba Cloud PolarDB-X Paxos इत्येतयोः मध्ये गहनतया तुलना

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

मुक्तस्रोतपारिस्थितिकीतन्त्रम्

यथा वयं सर्वे जानीमः, MySQL प्राथमिकः माध्यमिकः च आँकडाधाराः (द्वौ नोड्) सामान्यतया अतुल्यकालिकप्रतिकृतिः अर्धसमकालिकप्रतिकृतिः (Semi-Sync) च माध्यमेन उच्चदत्तांशउपलब्धतां प्राप्नुवन्ति तथापि सङ्गणककक्षजालविफलता तथा होस्टहैङ्गअप इत्यादिषु असामान्यपरिदृश्येषु प्राथमिक-माध्यमिक-आर्किटेक्चरयोः एचए-स्विचिंग्-पश्चात् गम्भीरसमस्यानां सामना भविष्यति (RPO!=0 इति उच्यते) ।अतः यावत् व्यावसायिकदत्तांशस्य महत्त्वं निश्चितं भवति तावत् MySQL प्राथमिकं माध्यमिकं च आर्किटेक्चरं (द्वौ नोड्) सह दत्तांशकोश-उत्पादं न चिन्वन्तु RPO=0 इत्यनेन सह बहुप्रतिलिपि-आर्किटेक्चरं चयनं अनुशंसितम्

MySQL समुदायः, RPO=0 इत्यनेन सह बहु-प्रति-प्रौद्योगिक्याः विकासस्य विषये:

  • MySQL आधिकारिकतया मुक्तस्रोतः अस्ति तथा च समूहप्रतिकृतिमाधारितं MySQL समूहप्रतिकृतिं (MGR) उच्च-उपलब्धतासमाधानं प्रारब्धवान् Paxos प्रोटोकॉलं आन्तरिकरूपेण XCOM मार्गेण समाहितं भवति यत् आँकडासुसंगततां सुनिश्चितं करोति।
  • अली मेघ PolarDB-X , अलीबाबा इत्यस्य ई-वाणिज्यस्य डबल इलेवेन् इत्यस्य व्यावसायिक-पॉलिशिंग्-सत्यापनात् च भिन्न-भिन्नस्थानेषु बहु-क्रियाकलापात् प्राप्तः, अयं अक्टोबर् २०२१ तमे वर्षे सम्पूर्णे कोर-मध्ये मुक्त-स्रोतः भविष्यति, MySQL-मुक्त-स्रोत-पारिस्थितिकीतन्त्रं पूर्णतया आलिंगयति PolarDB-X एकस्य केन्द्रीकृतस्य वितरितस्य च एकीकृतदत्तांशकोशस्य रूपेण स्थितः अस्ति अस्य आँकडानोड् Data Node (DN) स्वविकसितं X-Paxos प्रोटोकॉलं स्वीकरोति तथा च MySQL 5.7/8.0 इत्यनेन सह अत्यन्तं संगतम् अस्ति , but also अस्य अत्यन्तं स्केल-करणीय-व्यवहार-इञ्जिनस्य, लचीला-सञ्चालनस्य, अनुरक्षणस्य च आपदा-पुनर्प्राप्तेः, न्यून-लाभस्य च आँकडा-सञ्चयस्य विशेषताः सन्ति सन्दर्भः: ".PolarDB-X Open Source |.Paxos इत्यस्य आधारेण MySQL इत्यस्य त्रीणि प्रतियाः》。

PolarDB-X केन्द्रीकृतस्य वितरितस्य च एकीकरणस्य अवधारणा: आँकडानोड् DN इत्यस्य उपयोगः स्वतन्त्रतया केन्द्रीकृतस्य (मानकसंस्करणस्य) रूपस्य रूपेण कर्तुं शक्यते, यत् एकान्तदत्तांशकोशरूपेण सह पूर्णतया संगतम् अस्ति यदा व्यवसायः एतावत्पर्यन्तं वर्धते यत्र वितरितविस्तारस्य आवश्यकता भवति तदा वास्तुकला स्थाने वितरितरूपेण उन्नयनं भवति, तथा च वितरितघटकाः मूलदत्तांशनोडैः सह निर्विघ्नतया सम्बद्धाः भवन्ति अनुप्रयोगपक्षे दत्तांशप्रवासस्य परिवर्तनस्य वा आवश्यकता नास्ति , तथा च भवान् वितरणस्य आनन्दं लब्धुं शक्नोति ।"केन्द्रीकृत वितरित एकीकरण"।

MySQL इत्यस्य MGR तथा PolarDB-X इत्यस्य मानकसंस्करणं DN इत्येतौ द्वौ अपि निम्नतमसिद्धान्तात् Paxos प्रोटोकॉलस्य उपयोगं कुर्वन्ति अतः वास्तविकप्रयोगे विशिष्टानि प्रदर्शनानि भेदाः च के सन्ति? अस्मिन् लेखे वास्तुकलातुलना, प्रमुखभेदाः, परीक्षणतुलना च पक्षाः विस्तरेण वर्णिताः सन्ति ।

MGR/DN संक्षिप्तविवरणम् : MGR MySQL MGR इत्यस्य तकनीकीरूपं प्रतिनिधियति, तथा च DN PolarDB-X एकल DN केन्द्रीकृतस्य (मानकसंस्करणस्य) तकनीकीरूपं प्रतिनिधियति

टीएल;डॉ

विस्तृतं तुलनात्मकं विश्लेषणं तुल्यकालिकं दीर्घं भवति, अतः भवान् प्रथमं सारांशं निष्कर्षं च पठितुं शक्नोति यदि भवान् रुचिं लभते तर्हि सारांशस्य अनुसरणं कृत्वा अनन्तरं लेखेषु सूचकान् अन्वेष्टुं शक्नोति।

MySQL MGR सामान्यव्यापाराणां कम्पनीनां च कृते अनुशंसितः नास्ति यतोहि तस्य सम्यक् उपयोगाय व्यावसायिकं तकनीकीज्ञानं तथा च संचालन-रक्षणदलस्य आवश्यकता भवति अयं लेखः MySQL MGR इत्यस्य त्रीणि "गुप्तजालानि" अपि प्रदर्शयति ये दीर्घकालं यावत् उद्योगे प्रचलन्ति : १.

  • Dark Pit 1: MySQL MGR तथा XCOM प्रोटोकॉल पूर्णस्मृतिविधिं स्वीकुर्वन्ति पूर्वनिर्धारितं RPO=0 इत्यस्य आँकडा-संगति-प्रतिश्रुतिं न पूरयितुं (अस्मिन् लेखे पश्चात् परीक्षण-प्रकरणे आँकडा-अनुपलब्धतायाः समस्या भविष्यति) प्रदर्शनं कृत्वा तत् सुनिश्चित्य विन्यस्तं कुर्वन्तु वर्तमानकाले MGR इत्यस्य डिजाइनं कार्यक्षमतां RPO च द्वौ अपि प्राप्तुं न शक्नोति।
  • जालम् 2: MySQL MGR इत्यस्य कार्यक्षमता तदा दुर्बलं भवति यदा संजालविलम्बः भवति लेखेन 4-मिनिट्-जाल-परिदृश्यानां (एकस्मिन् नगरे त्रीणि सङ्गणक-कक्षाणि, द्वयोः स्थानयोः त्रीणि केन्द्राणि च समाविष्टानि) परीक्षणं कृतम् city ​​performance parameters, it is only 1/5 of that in the same city , यदि RPO=0 इत्यस्य दत्तांशप्रतिश्रुतिः चालू भवति तर्हि कार्यक्षमता अपि दुर्बलतरं भविष्यति ।अतः MySQL MGR एकस्मिन् एव सङ्गणककक्षस्य परिदृश्ये उपयोगाय अधिकं उपयुक्तः अस्ति, परन्तु पार-सङ्गणककक्षस्य आपदापुनर्प्राप्त्यर्थं उपयुक्तः नास्ति ।
  • जालम् 3: MySQL MGR इत्यस्य बहुप्रतिलिपि-आर्किटेक्चर-मध्ये, स्टैण्डबाई-नोड्-विफलतायाः कारणेन मुख्य-नोड्-लीडरस्य यातायातस्य 0 -पर्यन्तं पतनं भविष्यति, यत् सामान्य-बुद्ध्या सह सङ्गतं नास्ति लेखः MGR इत्यस्य एकलनेताविधिं (MySQL इत्यस्य पूर्ववर्ती-गुलाम-प्रतिकृति-आर्किटेक्चरस्य तुलने) सक्षमीकरणस्य प्रयासे केन्द्रितः अस्ति, दास-प्रतिकृतिस्य डाउनटाइमस्य पुनर्प्राप्तेः च क्रियाद्वयस्य अनुकरणं कृत्वा दास-नोड्-सञ्चालनस्य, अनुरक्षणस्य च कार्याणि अपि मास्टरस्य कारणं भविष्यन्ति node (Leader) इति प्रकटितुं यातायातः 0 (प्रायः 10 सेकण्ड् यावत् स्थास्यति) यावत् पतितः, समग्ररूपेण संचालनक्षमता, परिपालनक्षमता च तुल्यकालिकरूपेण दुर्बलः आसीत् ।अतः MySQL MGR इत्यस्य होस्ट्-सञ्चालनस्य अनुरक्षणस्य च विषये तुल्यकालिकरूपेण उच्चाः आवश्यकताः सन्ति तथा च व्यावसायिकस्य DBA-दलस्य आवश्यकता भवति ।

MySQL MGR इत्यनेन सह तुलने PolarDB-X Paxos इत्यस्य आँकडा-सङ्गतिः, क्रॉस्-कम्प्यूटर-कक्ष-आपदा-पुनर्प्राप्तिः, नोड्-सञ्चालनं, अनुरक्षणं च इति दृष्ट्या MGR-सदृशानि जालानि नास्ति तथापि आपदा-पुनर्प्राप्ति-विषये अपि अस्य केचन लघु-लघु-लघुताः, लाभाः च सन्ति

  • एकस्यैव सङ्गणककक्षस्य सरलपरिदृश्ये, न्यूनसमवर्ततायाः अन्तर्गतं केवलं पठनीयं प्रदर्शनं उच्चसमवर्ततायाः अन्तर्गतं शुद्धलेखनप्रदर्शनं च MySQL MGR इत्यस्मात् किञ्चित् न्यूनं भवति, एकस्मिन् समये संजालद्वारा बहुप्रतियाः प्रेष्यन्ते, तथा च कार्यप्रदर्शने अग्रे अनुकूलनस्य स्थानं वर्तते।
  • लाभाः: MySQL 5.7/8.0 इत्यस्य विशेषताभिः सह 100% संगतम्, तस्मिन् एव काले, बहु-प्रति-स्टैण्डबाई-दत्तांशकोश-प्रतिकृति-विफलता-मार्गेषु अधिक-सुव्यवस्थित-अनुकूलनं कृतम् अस्ति, उच्च-उपलब्धता-स्विचिंग् RTO <= 8 सेकण्ड्, एकः सामान्यः -उद्योगे -मिनिटस्य आपदा-पुनर्प्राप्ति-परिदृश्यं सम्यक् प्रदर्शनं कुर्वन्ति तथा च अर्ध-समन्वयन (अर्ध-समन्वयन), एमजीआर इत्यादीनां स्थाने स्थातुं शक्नुवन्ति।

1. वास्तुकला तुलना

शब्दावली

MGR/DN संक्षिप्तनाम विवरणम् : १.

  1. MGR: MySQL MGR इत्यस्य तकनीकीरूपं, तदनन्तरं सामग्रीयाः संक्षिप्तरूपेण: MGR
  2. DN: अलीबाबा क्लाउड PolarDB-X एकं केन्द्रीकृतं (मानकसंस्करणं) तकनीकीरूपं वितरितदत्तांशनोडं DN स्वतन्त्रतया एकान्तदत्तांशकोशैः सह पूर्णतया संगतम् अस्ति यथा: DN

म.जी.आर

MGR एकल-मास्टर-बहु-मास्टर-मोड् समर्थयति, तथा च MySQL इत्यस्य प्रतिकृति-प्रणाल्याः पूर्णतया पुनः उपयोगं करोति, यत्र Event, Binlog & Relaylog, Apply, Binlog Apply Recovery, GTID च सन्ति । DN इत्यस्मात् मुख्यः अन्तरः अस्ति यत् MGR लेनदेन-लॉग-बहुमतस्य सहमति-प्राप्त्यर्थं प्रवेशबिन्दुः मुख्य-दत्तांशकोश-व्यवहारस्य प्रतिबद्धतायाः पूर्वं भवति ।

  • नेता:
    1. लेनदेनस्य प्रतिबद्धतायाः पूर्वं, MGR इत्यस्य बहुमतप्रतिकृतिं प्रविष्टुं before_commit हुक् फंक्शन् group_replication_trans_before_commit आह्वयते ।
    2. MGR THD इत्यत्र संग्रहीतं Binlog Events सर्वेषु ऑनलाइन नोड् मध्ये समन्वययितुं Paxos प्रोटोकॉलस्य उपयोगं करोति
    3. बहुमतप्रतिसादं प्राप्य एमजीआर निर्धारयति यत् व्यवहारः प्रस्तूयते इति
    4. THD लेनदेनसमूहस्य प्रस्तुतीकरणप्रक्रियायां प्रविशति तथा च स्थानीयं Binlog update Redo reply client OK सन्देशं लिखितुं आरभते
  • अनुयायी : ९.
    1. MGR इत्यस्य Paxos Engine इत्येतत् Leader इत्यस्य प्रोटोकॉलसन्देशान् निरन्तरं शृणोति
    2. सम्पूर्णस्य Paxos सहमतिप्रक्रियायाः अनन्तरं पुष्टिः भवति यत् एषः (batch) Event समूहे बहुमतं प्राप्तवान् अस्ति
    3. प्राप्तं Event इत्येतत् Relay Log, IO Thread Apply Relay Log इत्यत्र लिखन्तु
    4. Relay Log अनुप्रयोगः सम्पूर्णसमूहप्रस्तुतिप्रक्रियायाः माध्यमेन गच्छति, तथा च स्टैण्डबाईदत्तांशकोशः अन्ते स्वकीयं binlog सञ्चिकां जनयिष्यति ।

MGR उपर्युक्तप्रक्रियाम् अङ्गीकुर्वति तस्य कारणं यत् MGR पूर्वनिर्धारितरूपेण बहु-मास्टर-मोड् मध्ये अस्ति, अतः एकस्मिन् Paxos Group इत्यस्मिन् अनुयायी नोड् प्रथमं RelayLog इत्यत्र परिवर्तयितुं, ततः संयोजनं कर्तुं च आवश्यकम् it with the write transaction it receives as the leader to submit , द्विचरणीयसमूहप्रदानप्रक्रियायां अन्तिमव्यवहारं प्रस्तुतुं Binlog सञ्चिका उत्पादिता भवति ।

DN

DN MySQL इत्यस्य मूलभूतदत्तांशसंरचनायाः कार्यस्तरीयसङ्केतस्य च पुनः उपयोगं करोति, परन्तु बहुमतप्रतिकृतिस्य स्थितियन्त्रतन्त्रस्य च स्वस्य समुच्चयस्य निर्माणार्थं X-Paxos प्रोटोकॉलेन सह लॉगप्रतिकृतिं, लॉगप्रबन्धनं, लॉगप्लेबैकं, क्रैशपुनर्प्राप्तिः च निकटतया एकीकृत्य MGR इत्यस्मात् मुख्यः अन्तरः अस्ति यत् DN लेनदेन-लॉग-बहुमतस्य सहमति-प्राप्त्यर्थं प्रवेशबिन्दुः मुख्य-दत्तांशकोश-व्यवहार-प्रस्तुति-प्रक्रियायाः समये भवति

  • नेता:
    1. लेनदेनस्य समूहप्रस्तुतिप्रक्रियायां प्रविशन्तु समूहप्रदानस्य Flush चरणे प्रत्येकस्मिन् THD इत्यत्र Events Binlog सञ्चिकायां लिख्यन्ते, ततः लॉगः X-Paxos इत्यस्य माध्यमेन सर्वेभ्यः अनुयायिभ्यः अतुल्यकालिकरूपेण प्रसारितः भवति
    2. समूहप्रदानस्य Sync चरणे प्रथमं Binlog स्थायित्वं भवति, ततः X-Paxos स्थायित्वस्थानं अद्यतनं भवति ।
    3. समूहप्रदानस्य Commit चरणे प्रथमं X-Paxos बहुमतप्रतिसादं प्राप्तुं प्रतीक्षां कुर्वन्तु, ततः लेनदेनसमूहं प्रस्तूयन्ते, अन्ते च ग्राहकात् OK सन्देशेन उत्तरं दातव्यम्
  • अनुयायी : ९.
    1. X-Paxos लीडर इत्यस्मात् प्रोटोकॉलसन्देशान् निरन्तरं शृणोति
    2. एकं (समूहं) Events प्राप्नुवन्तु, स्थानीयं Binlog - मध्ये लिखन्तु, प्रतिक्रियां च ददतु
    3. अग्रिमः सन्देशः प्राप्यते, यः बहुमतं प्राप्तस्य स्थानस्य Commit सूचकाङ्कं वहति ।
    4. SQL Apply थ्रेड् पृष्ठभूमितः प्राप्तं Binlog लॉग् प्रयोजयति, अधिकतमं बहुमतस्थाने एव प्रयोजयति ।

अस्य डिजाइनस्य कारणं अस्ति यत् DN सम्प्रति केवलं एक-मास्टर-मोड् समर्थयति, अतः X-Paxos प्रोटोकॉल-स्तरस्य लॉग् स्वयं Binlog अस्ति Follower अपि Relay Log अपि परित्यजति, तथा च तस्य निरन्तर-लॉगस्य आँकडा-सामग्री अपि च लीडरस्य लॉग् अपि परित्यजति are equal to Same मूल्यम्।

2. मुख्यभेदाः

2.1.Paxos प्रोटोकॉल दक्षता

म.जी.आर

  • MGR इत्यस्य Paxos प्रोटोकॉलः Mencius प्रोटोकॉल इत्यस्य आधारेण कार्यान्वितः अस्ति, यः Multi-Paxos सिद्धान्तस्य अन्तर्गतः अस्ति, अन्तरं अस्ति यत् Mencius इत्यनेन मास्टर नोड् इत्यस्य भारं न्यूनीकर्तुं, थ्रूपुट् वर्धयितुं च अनुकूलनसुधारः कृतः
  • MGR इत्यस्य Paxos प्रोटोकॉल XCOM घटकैः कार्यान्वितं भवति तथा च बहु-मास्टर-मोड-नियोजनं समर्थयति एकल-मास्टर-मोड्-मध्ये, Leader-उपरि Binlog परमाणुरूपेण Follower-नोड्-इत्यत्र प्रसारयति एकः मानकः Multi-Paxos प्रक्रिया।
  • व्यवहारस्य बहुमतं सन्तुष्टुं XCOM इत्यस्य Accept+AckAccept+Learn इत्यस्य न्यूनातिन्यूनं त्रीणि सन्देशपरस्परक्रियाः गन्तुं आवश्यकाः सन्ति, अर्थात्न्यूनातिन्यूनं १.५ आरटीटी ओवरहेड् ।अस्य अधिकतमं त्रीणि सन्देशपरस्परक्रियाः आवश्यकाः सन्ति: Prepare+AckPrepare+Accept+AckAccept+Learn इति ।अर्थात् कुलम् अधिकतमं २.५ आरटीटी ओवरहेड्
  • यतो हि Paxos प्रोटोकॉल XCOM मॉड्यूले उच्चसङ्गतिसहितं सम्पन्नं भवति तथा च MySQL प्रतिकृतिप्रणाल्याः विषये अवगतः नास्ति, अतः लीडरेण स्थानीयरूपेण लेनदेनं कर्तुं पूर्वं सम्पूर्णं Paxos प्रक्रियां पूर्णं भवितुं प्रतीक्षितव्यं, यत्र Binlog स्थायित्वं समूहप्रस्तुतिः च सन्ति
  • अनुयायी बहुमतप्रदानं सम्पन्नं कृत्वा, सः अतुल्यकालिकरूपेण Relay Log मध्ये Events स्थास्यति, ततः SQL Thread अनुप्रयोगः समूहश्च उत्पादनं Binlog प्रस्तुतं करिष्यति
  • यतो हि Paxos द्वारा समन्वयितः लॉगः एकः Binlog अस्ति यः समूहप्रस्तुतिप्रक्रियायां प्रवेशात् पूर्वं क्रमबद्धः न भवति, अतः Leader इत्यत्र Binlog Events इत्यस्य क्रमः Follower नोड् इत्यत्र Relay Log इत्यस्मिन् Events इत्यस्य क्रमः समानः न भवितुम् अर्हति

DN

  • DN इत्यस्य Paxos प्रोटोकॉलः Raft प्रोटोकॉल इत्यस्य आधारेण कार्यान्वितः अस्ति तथा च Multi-Paoxs सिद्धान्तस्य अन्तर्गतः अस्ति अन्तरं यत् Raft प्रोटोकॉल इत्यस्य नेतृत्वस्य गारण्टी अपि च अभियांत्रिकी स्थिरतायाः गारण्टी अधिका अस्ति ।
  • DN इत्यस्य Paxos प्रोटोकॉलः X-Paoxs घटकेन सम्पन्नः भवति .
  • लेनदेनस्य बहुमतं सन्तुष्टुं X-Paoxs इत्यस्य केवलं Append+AckAppend इत्यस्य सन्देशपरस्परक्रियाद्वयं गन्तुं आवश्यकं भवति, तथा च केवलं१ आरटीटी उपरि
  • नेता अनुयायिणं प्रति लॉगं प्रेषयित्वा यावत् बहुमतं सन्तुष्टं भवति तावत् द्वितीयपदे Commit Index प्रसारणस्य प्रतीक्षां विना व्यवहारं प्रतिबद्धं करोति
  • अनुयायी बहुमत-प्रस्तुतिं पूर्णं कर्तुं शक्नोति तस्मात् पूर्वं, एतत् MGR इत्यस्य XCOM इत्यस्मात् महत्त्वपूर्णतया भिन्नम् अस्ति ।
  • Commit Index इत्येतत् अनन्तरं सन्देशेषु हृदयस्पन्दनसन्देशेषु च आनयति, तथा च CommitIndex इत्यस्य उपरि धक्कायमानस्य अनन्तरं Follower Apply Event इत्येतत् करोति ।
  • Leader तथा Follower इत्येतयोः Binlog सामग्रीः एकस्मिन् क्रमे भवति, Raft logs इत्यस्य छिद्रं नास्ति, तथा च Batching/Pipeline तन्त्रस्य उपयोगः log replication throughput वर्धयितुं भवति
  • एमजीआर इत्यस्य तुलने लीडरस्य सर्वदा केवलं एकः एव गोलयात्राविलम्बः भवति यदा व्यवहारः क्रियते ।, विलम्ब-संवेदनशीलवितरित-अनुप्रयोगानाम् कृते अतीव महत्त्वपूर्णम्

२.२. आर पी ओ

सैद्धान्तिकरूपेण, Paxos तथा Raft इत्येतयोः द्वयोः अपि आँकडानां स्थिरतां सुनिश्चितं कर्तुं शक्यते तथा च Crash Recovery इत्यस्य अनन्तरं बहुमतं प्राप्ताः लॉग्स् नष्टाः न भविष्यन्ति, परन्तु अद्यापि विशिष्टेषु परियोजनासु भेदाः सन्ति

म.जी.आर

XCOM पूर्णतया Paxos प्रोटोकॉलं समाहितं करोति, तस्य सर्वः प्रोटोकॉलदत्तांशः प्रथमं स्मृतौ संग्रहीतः भवति, पूर्वनिर्धारितरूपेण, बहुमतं प्राप्तुं लेनदेनस्य लॉग-स्थायित्वस्य आवश्यकता नास्ति । यत्र अधिकांशः पाई अधः भवति तथा च लीडरः विफलः भवति तस्मिन् सन्दर्भे RPO != 0 इत्यस्य गम्भीरः समस्या भविष्यति ।अत्यन्तं परिदृश्यं कल्पयतु : १.

  1. एमजीआर-समूहे एबीसी इति त्रयः नोड्स् सन्ति, येषु एबी एकस्मिन् एव नगरे स्वतन्त्रः सङ्गणककक्षः अस्ति, सी च क्रॉस्-सिटी नोड् अस्ति । A Leader, BC Follower नोड् इति
  2. लीडर ए नोड् इत्यत्र लेनदेनं 001 आरभत यदि बहुमतं Paxos प्रोटोकॉलद्वारा सन्तुष्टं भवति तर्हि लेनदेनं प्रस्तुतं इति गणयितुं शक्यते । खण्डः AB बहुमतं निर्मितवान्, तथा च नोड् C इत्यनेन पार-नगरजालविलम्बस्य कारणेन लेनदेनस्य 001 इत्यस्य लॉगः न प्राप्तः ।
  3. अग्रिमे क्षणे लीडर ए लेनदेनं 001 प्रस्तौति तथा च Client सफलतां प्रत्यागच्छति, यस्य अर्थः अस्ति यत् लेनदेनं 001 दत्तांशकोशे प्रस्तुतम् अस्ति ।
  4. अस्मिन् क्षणे, नोड् B इत्यस्य Follower इत्यत्र, लेनदेनस्य log 001 अद्यापि XCOM cache मध्ये अस्ति तथा च RelayLog इत्यत्र फ्लश कर्तुं समयः न प्राप्तः, अस्मिन् क्षणे, नोड् C इत्यस्य Follower इत्यनेन अद्यापि लेनदेनं 001 न प्राप्तम्; नोडस्य अग्रणीतः log A.
  5. अस्मिन् समये नोड् AB अधः अस्ति, नोड् A विफलः भवति, दीर्घकालं यावत् पुनः प्राप्तुं न शक्यते, नोड् B पुनः आरभ्यते, शीघ्रं पुनः प्राप्तुं च शक्यते, नोड् BC पठनलेखनसेवाः निरन्तरं प्रदास्यन्ति
  6. यतः व्यवहारः 001 लॉग् अवकाशसमये नोड् B इत्यस्य RelayLog प्रति न स्थापितः आसीत्, न च नोड् C इत्यनेन प्राप्तः, अतः अस्मिन् क्षणे, BC नोड् वस्तुतः लेनदेनं 001 नष्टवान् अस्ति तथा च तत् पुनः प्राप्तुं न शक्नोति
  7. अस्मिन् परिदृश्ये यत्र बहुमतदलः अधः अस्ति, 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 गारण्टी कर्तुं शक्यते ।

२.३. आरटीओ

आरटीओ समयः प्रणाल्याः एव शीतपुनर्प्रारम्भस्य समयस्य उपरिभागेन सह निकटतया सम्बद्धः भवति, यत् विशिष्टमूलकार्येषु प्रतिबिम्बितम् अस्ति:दोषपरिचयतन्त्रम्->दुर्घटनापुनर्प्राप्तितन्त्रम्->मास्टरचयनतन्त्रम्->लॉगसन्तुलनम्

२.३.१.दोषपरिचयः

म.जी.आर

  • प्रत्येकं नोडः समये समये अन्येभ्यः नोड्भ्यः हृदयस्पन्दनपैकेट् प्रेषयति यत् अन्ये नोड् स्वस्थाः सन्ति वा इति परीक्षते हृदयस्पन्दनकालः 1s इत्यत्र नियतः अस्ति तथा च समायोजितुं न शक्यते ।
  • यदि वर्तमाननोड् पश्यति यत् अन्ये नोड्स् group_replication_member_expel_timeout (default 5s) इत्यस्य अनन्तरं प्रतिक्रियां न दत्तवन्तः, तर्हि तत् असफलं नोड् इति गण्यते, क्लस्टरतः बहिः पातितम् भविष्यति
  • जालव्यत्ययः अथवा असामान्यपुनर्प्रारम्भ इत्यादीनां अपवादानाम् कृते जालस्य पुनर्स्थापनानन्तरं एकः असफलः नोड् स्वयमेव क्लस्टरं सम्मिलितुं प्रयतते ततः लॉग् बद्धुं प्रयतते

DN

  • लीडर नोड् समये समये अन्येभ्यः नोड्भ्यः हृदयस्पन्दनपैकेट् प्रेषयति यत् अन्ये नोड् स्वस्थाः सन्ति वा इति परीक्षते । निर्वाचनसमयसमाप्तिः पैरामीटर् consensus_election_timeout द्वारा नियन्त्रिता भवति, अतः पूर्वनिर्धारितं 5s अस्ति, अतः लीडर नोड् हृदयस्पन्दनकालः पूर्वनिर्धारितरूपेण 1s भवति ।
  • यदि लीडरः अन्ये नोड्स् अफलाइन इति पश्यति तर्हि अन्येभ्यः नोड्-इत्येतत् दुर्घटनातः पुनः प्राप्तेः च अनन्तरं समये एव प्रवेशं कर्तुं शक्नुवन्ति इति सुनिश्चित्य अन्येभ्यः सर्वेभ्यः नोड्-भ्यः समये समये हृदयस्पन्दन-पैकेट् प्रेषयतिपरन्तु Leader नोड् इत्येतत् अफलाइन नोड् प्रति व्यवहारवृत्तलेखान् न प्रेषयति ।
  • अ-नेता नोड् हृदयस्पन्दन-परिचय-पैकेट् न प्रेषयन्ति, परन्तु यदि अ-नेतृ-नोड् consensus_election_timeout-पश्चात् लीडर-नोड्-तः हृदयस्पन्दनं न प्राप्तवान् इति पश्यति तर्हि पुनः निर्वाचनं प्रवर्तते
  • जालव्यत्ययः अथवा असामान्यपुनर्प्रारम्भ इत्यादीनां अपवादानाम् कृते जालस्य पुनर्स्थापनानन्तरं दोषपूर्णः नोड् स्वयमेव समूहे सम्मिलितः भविष्यति ।
  • अतः दोषपरिचयस्य दृष्ट्या DN अधिकानि संचालन-रक्षण-विन्यास-अन्तरफलकानि प्रदाति, तथा च नगर-पार-नियोजन-परिदृश्येषु दोषाणां पहिचानं अधिकं सटीकं भविष्यति

2.3.2.दुर्घटनापुनर्प्राप्तिः

म.जी.आर

    • XCOM द्वारा कार्यान्वितः Paxos प्रोटोकॉलः स्मृतिस्थितौ अस्ति बहुमतस्य उपलब्ध्यर्थं स्थायित्वस्य आवश्यकता नास्ति ।यदि सर्वे नोड्स् लम्बन्ते तर्हि क्लस्टरस्य पुनः आरम्भस्य अनन्तरं तस्य पुनर्स्थापनार्थं मैनुअल् हस्तक्षेपस्य आवश्यकता भवति ।
    • यदि केवलं एकः नोड् क्रैश भवति, पुनः प्राप्तः च भवति, परन्तु Follower नोड् अधिकैः लेनदेन-वृत्तैः सह Leader-नोड्-तः पृष्ठतः भवति, तथा च Leader-इत्यत्र XCOM-सञ्चय-कृत-व्यवहार-वृत्तान्ताः स्वच्छाः भवन्ति, तर्हि एकमात्रः विकल्पः अस्ति यत् Global Recovery अथवा Clone प्रक्रियायाः उपयोगः भवति
    • XCOM cache आकारः group_replication_message_cache_size द्वारा नियन्त्रितः भवति, पूर्वनिर्धारितं 1GB अस्ति
    • वैश्विकपुनर्प्राप्तेः अर्थः अस्ति यत् यदा कोऽपि नोडः पुनः क्लस्टर्-सङ्गतिं करोति तदा अन्येभ्यः नोड्-भ्यः आवश्यकानि गम्यमान-व्यवहार-लॉग् (Binary Log) प्राप्य दत्तांशं पुनः प्राप्नोति ।इयं प्रक्रिया क्लस्टर् मध्ये न्यूनातिन्यूनम् एकस्मिन् नोड् इत्यस्य उपरि अवलम्बते यत् सर्वाणि आवश्यकानि व्यवहारवृत्तानि धारयति
    • क्लोन् क्लोन् प्लगिन् इत्यस्य उपरि अवलम्बते, यत् पुनर्प्राप्त्यर्थं यदा दत्तांशस्य परिमाणं बृहत् भवति अथवा बहवः लॉग्स् अनुपलब्धाः भवन्ति तदा उपयुज्यते ।एतत् सम्पूर्णस्य दत्तांशकोशस्य स्नैपशॉट् क्रैश्ड् नोड् मध्ये प्रतिलिख्य, तदनन्तरं नवीनतमेन लेनदेन-वृत्तलेखेन सह अन्तिम-समन्वयनं कृत्वा कार्यं करोति
    • ग्लोबल रिकवरी तथा क्लोन प्रक्रियाः प्रायः स्वचालिताः भवन्ति, परन्तु केषुचित् विशेषेषु सन्दर्भेषु, यथा संजालसमस्या अथवा अन्ययोः नोड्योः XCOM कैशः स्वच्छः अभवत्, हस्तहस्तक्षेपस्य आवश्यकता भवति

DN

    • X-Paxos प्रोटोकॉल Binlog स्थायित्वस्य उपयोगं करोति यदा दुर्घटनातः पुनः प्राप्तिः भवति तदा प्रस्तुताः लेनदेनाः प्रथमं पूर्णतया पुनर्स्थापिताः भविष्यन्ति । लम्बितव्यवहारस्य कृते, लेनदेनं प्रतिबद्धं कर्तुं वा पुनः रोल कर्तुं वा पूर्वं मास्टर-बैकअप-सम्बन्धं निर्धारयितुं XPaxos प्रोटोकॉल-स्तरस्य सम्झौतां प्राप्तुं प्रतीक्षा कर्तव्या सम्पूर्णा प्रक्रिया पूर्णतया स्वचालिता भवति ।सर्वे नोड्स् अधः सन्ति चेदपि पुनः आरम्भं कृत्वा क्लस्टरः स्वयमेव पुनः प्राप्तुं शक्नोति ।
    • यत्र Follower नोड् अनेकेषु लेनदेन-वृत्तेषु Leader-नोड्-तः पृष्ठतः भवति, तावत्पर्यन्तं यावत् Leader-मध्ये Binlog-सञ्चिका न विलोप्यते, तावत्पर्यन्तं Follower-नोड्-इत्येतत् निश्चितरूपेण गृह्णीयात्
    • अतः दुर्घटनापुनर्प्राप्तेः दृष्ट्या DN इत्यस्य हस्तहस्तक्षेपस्य सर्वथा आवश्यकता नास्ति ।

२.३.३

एक-मास्टर-मोड् मध्ये, MGR इत्यस्य XCOM तथा DN X-Paxos, एकः सशक्तः लीडर-मोड्, लीडरस्य चयनार्थं समानं मूलभूतं सिद्धान्तं अनुसरति - येषां लॉग्स् क्लस्टरेन सहमताः सन्ति, ते पुनः रोल कर्तुं न शक्यन्ते परन्तु यदा असहमति-लॉगस्य विषयः आगच्छति तदा भेदाः सन्ति

म.जी.आर

  • लीडर चयनं अधिकं भवति यत् अग्रे कोऽपि नोड् लीडर सेवारूपेण कार्यं करिष्यति इति ।अस्य लीडरस्य निर्वाचितसमये नवीनतमः सहमति-वृत्तलेखः अवश्यमेव नास्ति, अतः तस्य समूहे अन्येभ्यः नोड्-भ्यः नवीनतम-लॉग्स्-समन्वयनं करणीयम्, तथा च लॉग्-बन्धनानन्तरं पठन-लेखन-सेवाः प्रदातुं आवश्यकाः
  • अस्य लाभः अस्ति यत् नेतारस्य एव चयनं सामरिकं उत्पादं भवति, यथा भारः क्रमः च । MGR group_replication_member_weight पैरामीटर् इत्यस्य माध्यमेन प्रत्येकस्य नोड् इत्यस्य भारं नियन्त्रयति
  • दोषः अस्ति यत् नवनिर्वाचितस्य नेतारस्य एव महती प्रतिकृतिविलम्बः भवितुम् अर्हति तथा च लॉगं निरन्तरं ग्रहीतुं आवश्यकं भवति, अथवा बृहत् अनुप्रयोगविलम्बः भवितुम् अर्हति तथा च लॉग-अनुप्रयोगं निरन्तरं ग्रहीतुं आवश्यकं भवति यत् सः पठनं च प्रदातुं शक्नोति लेखनसेवाः।एतेन आरटीओ समयः दीर्घः भवति

DN

  • नेता निर्वाचनं प्रोटोकॉलस्य अर्थे भवति यस्य कोऽपि नोडः समूहे सर्वेषां बहुमतदलानां लॉग्स् भवति सः नेता इति निर्वाचितः भवितुम् अर्हति, अतः अयं नोडः पूर्वं अनुयायी वा लॉगरः वा आसीत्
  • Logger अन्यनोड्स् मध्ये लॉग्स् समन्वयनस्य अनन्तरं सक्रियरूपेण Leader भूमिकां त्यक्ष्यति ।
  • निर्दिष्टः नोडः नेता भवति इति सुनिश्चित्य, DN आशावादी भाररणनीतिं + अनिवार्यभाररणनीतिं उपयुज्य नेता भवितुं क्रमं सीमितं करोति, तथा च रणनीतिकबहुमततन्त्रस्य उपयोगं करोति यत् नूतनः गुरुः तत्क्षणमेव पठनलेखनं प्रदातुं शक्नोति इति सुनिश्चितं करोति शून्यविलम्बयुक्ताः सेवाः।
  • अतः नेताचयनस्य दृष्ट्या डीएन न केवलं एमजीआर इत्यस्य समानं रणनीतिकचयनस्य समर्थनं करोति, अपितु अनिवार्यभाररणनीतयः अपि समर्थयति ।

2.3.4.लॉगमेलनम्

लॉग् समीकरणस्य अर्थः अस्ति यत् प्राथमिक-द्वितीयक-दत्तांशकोशयोः मध्ये लॉग्-मध्ये लॉग्-प्रतिकृति-विलम्बः भवति, तथा च गौण-दत्तांशकोषस्य लॉग्-समीकरणस्य आवश्यकता वर्तते पुनः आरब्धानां पुनर्स्थापितानां च नोड्-समूहानां कृते पुनर्प्राप्तिः प्रायः स्टैण्डबाई-दत्तांशकोशेन आरभ्यते, मुख्यदत्तांशकोशेन सह तुलने च लॉग्-प्रतिकृतिविलम्बः पूर्वमेव अभवत्, तथा च लॉग्-इत्येतत् मुख्यदत्तांशकोशेन सह गृहीतुं आवश्यकम् ये नोड्स् भौतिकरूपेण लीडरतः दूराः सन्ति, तेषां कृते बहुमतं प्राप्तुं प्रायः तेषां सह किमपि सम्बन्धः नास्ति, तेषां सर्वदा प्रतिकृति-लॉग्-विलम्बः भवति, ते च सर्वदा लॉग्-सङ्गतिं कुर्वन्ति एतेषु परिस्थितिषु लॉगप्रतिकृतिविलम्बस्य समये समाधानं सुनिश्चित्य विशिष्टं अभियांत्रिकीकार्यन्वयनस्य आवश्यकता भवति ।

म.जी.आर

  • लेनदेन-वृत्तलेखाः सर्वे XCOM-सञ्चयस्य मध्ये सन्ति, तथा च संग्रहणं पूर्वनिर्धारितरूपेण केवलं 1G भवति अतः यदा अनुयायी-नोड् यः अनुरोध-वृत्तलेखानां प्रतिकृतिं कर्तुं दूरं पृष्ठतः भवति तदा संग्रहणस्य कृते स्वच्छता सुलभा भवति
  • अस्मिन् समये, पश्चात्तापं कुर्वन् अनुयायी स्वयमेव क्लस्टर्-तः बहिः निष्कासितः भविष्यति, ततः क्रैश-पुनर्प्राप्त्यर्थं उपरि उल्लिखितायाः Global Recovery अथवा Clone प्रक्रियायाः उपयोगं करिष्यति, ततः स्वयमेव क्लस्टर-मध्ये सम्मिलितः भविष्यतियदि भवन्तः सम्मुखीभवन्तियथा, संजालसमस्याः, अथवा अन्ययोः नोड्-योः XCOM-सञ्चयः स्वच्छः भवति, अस्मिन् सन्दर्भे समस्यायाः समाधानार्थं हस्त-हस्तक्षेपस्य आवश्यकता भवति ।
  • किमर्थं प्रथमं क्लस्टरं किक् आउट् कर्तव्यं यतः बहुलेखन मोड् मध्ये दोषपूर्णः नोड् कार्यक्षमतां बहु प्रभावितं करोति, तथा च Leader इत्यस्य cache इत्यस्य तस्मिन् कोऽपि प्रभावः नास्ति ।
  • किमर्थं वयं प्रत्यक्षतया Leader इत्यस्य स्थानीयं Binlog सञ्चिकां पठितुं न शक्नुमः यतः पूर्वं उल्लिखितः XCOM प्रोटोकॉलः पूर्णस्मृतौ अस्ति, तथा च Binlog तथा Relay Log इत्यत्र XCOM विषये कोऽपि प्रोटोकॉलसूचना नास्ति

DN

  • दत्तांशः सर्वः Binlog सञ्चिकायां अस्ति यावत् Binlog स्वच्छः न भवति तावत् यावत् तत् आग्रहेण प्रेषयितुं शक्यते तथा च क्लस्टरात् बहिः निष्कासनस्य सम्भावना नास्ति ।
  • मुख्यपुस्तकालयस्य Binlog सञ्चिकातः पुरातनव्यवहारवृत्तलेखानां पठनेन उत्पद्यमानं IO jitter न्यूनीकर्तुं, DN FIFO Cache तः अद्यतनतया संग्रहीतव्यवहारवृत्तलेखान् पठितुं प्राथमिकता ददाति FIFO Cache पैरामीटर् consensus_log_cache_size द्वारा नियन्त्रितः भवति, तथा च पूर्वनिर्धारितः ६४M इति
  • यदि FIFO Cache मध्ये पुरातनः लेनदेन-वृत्तलेखः अद्यतन-व्यवहार-वृत्तलेखेन समाप्तः अस्ति, तर्हि DN Prefetch Cache तः पूर्वं संग्रहीतं व्यवहार-वृत्तं पठितुं प्रयतते
  • यदि Prefetch Cache मध्ये आवश्यकं पुरातनं व्यवहारवृत्तं नास्ति तर्हि DN अतुल्यकालिकं IO कार्यं आरभ्य, Binlog सञ्चिकातः निर्दिष्टस्य लेनदेनवृत्तस्य पूर्वं पश्चात् च अनेकाः क्रमशः लॉग्स् बैचरूपेण पठित्वा Prefetch Cache मध्ये स्थापयित्वा प्रतीक्षेत DN इत्यस्य अग्रिमस्य पुनः प्रयासस्य पठनस्य कृते Pick
  • अतः लॉग्स् संतुलनस्य विषये DN इत्यस्य हस्तहस्तक्षेपस्य सर्वथा आवश्यकता नास्ति ।

2.4.स्टैण्डबाई डाटाबेस प्लेबैक विलम्ब

स्टैण्डबाई डाटाबेस् प्लेबैक् विलम्बः मुख्यदत्तांशकोशे समानः व्यवहारः सम्पन्नः भवति तथा च स्टैण्डबाई दत्तांशकोशे व्यवहारः प्रयुक्तः भवति इति समयस्य मध्ये विलम्बः अस्ति अपवादः भवति चेत् स्टैण्डबाई-दत्तांशकोशस्य स्वस्य दत्तांश-अनुप्रयोगं पूर्णं कर्तुं कियत्कालं भवति तथा च पठन-लेखन-सेवाः प्रदातुं कियत्कालं भवति इति प्रभावितं करोति ।

म.जी.आर

  • MGR स्टैण्डबाई दत्तांशकोशः मुख्यदत्तांशकोशात् RelayLog सञ्चिकां प्राप्नोति यदा एप्लिकेशनं प्रयोजयति तदा पुनः RelayLog पठितुं, सम्पूर्णं द्विचरणीयसमूहप्रस्तुतिप्रक्रियायाः माध्यमेन गन्तुं, तत्सम्बद्धदत्तांशं Binlog सञ्चिकां च उत्पादयितुं आवश्यकम्
  • अत्र लेनदेन-अनुप्रयोग-दक्षता मुख्य-दत्तांशकोशे लेनदेन-प्रस्तुति-दक्षतायाः समाना अस्ति

DN

  • DN बैकअप दत्तांशकोशः मुख्यदत्तांशकोशात् Binlog सञ्चिकां प्राप्नोति यदा Binlog पुनः पठितुं आवश्यकं भवति केवलं एकचरणीयसमूहप्रदानप्रक्रियायाः माध्यमेन गत्वा तत्सम्बद्धं दत्तांशं उत्पादयितुं आवश्यकम् ।
  • यतः DN सम्पूर्णं Crash Recover समर्थयति, अतः स्टैण्डबाई डाटाबेस् अनुप्रयोगस्य innodb_flush_log_at_trx_commit=1 सक्षमीकरणस्य आवश्यकता नास्ति, अतः तत् वस्तुतः द्विगुण-एक-विन्यासेन प्रभावितं न भवति
  • अतः स्टैण्डबाई डाटाबेस् प्लेबैक् विलम्बस्य दृष्ट्या DN स्टैण्डबाई डाटाबेस् प्लेबैक् दक्षता MGR इत्यस्मात् बहु अधिका भविष्यति ।

२.५ प्रमुखघटनानां प्रभावः

बृहत् लेनदेनं न केवलं साधारणव्यवहारस्य प्रस्तुतीकरणं प्रभावितं करोति, अपितु वितरितप्रणाल्यां सम्पूर्णस्य वितरितप्रोटोकॉलस्य स्थिरतां अपि प्रभावितं करोति गम्भीरप्रसङ्गेषु बृहत् लेनदेनेन सम्पूर्णं समूहं दीर्घकालं यावत् अनुपलब्धं भविष्यति

म.जी.आर

  • MGR इत्यस्य बृहत् लेनदेनस्य समर्थनार्थं किमपि अनुकूलनं नास्ति ।
  • यदा व्यवहारवृत्तलेखः बृहत् व्यवहारसीमाम् अतिक्रमति तदा प्रत्यक्षतया त्रुटिः निवेदिता भविष्यति तथा च व्यवहारः प्रस्तूय कर्तुं न शक्यते ।

DN

  • बृहत् लेनदेनस्य कारणेन वितरितप्रणालीनां अस्थिरतासमस्यायाः समाधानार्थं DN समस्यायाः समाधानार्थं बृहत् लेनदेनस्य विभाजनस्य + बृहत् वस्तुविभाजनस्य समाधानं स्वीकुर्वति DN बृहत् लेनदेनस्य लेनदेनस्य लॉगं तार्किकरूपेण + भौतिकरूपेण विभाजयिष्यति लघुखण्डाः, लेनदेनवृत्तस्य प्रत्येकं लघुखण्डं पूर्णं Paxos प्रतिबद्धप्रतिश्रुतिं उपयुङ्क्ते
  • बृहत् लेनदेनस्य विभाजनस्य समाधानस्य आधारेण DN बृहत् लेनदेनस्य आकारे किमपि प्रतिबन्धं न स्थापयति उपयोक्तारः तान् इच्छया उपयोक्तुं शक्नुवन्ति तथा च RPO=0 इति सुनिश्चितं कर्तुं शक्नुवन्ति ।
  • विस्तृतनिर्देशार्थं पश्यन्तु"PolarDB-X भण्डारण इञ्जिन कोर प्रौद्योगिकी | बृहत् लेनदेन अनुकूलनम्"
  • अतः डीएन बृहत्-प्रमाणस्य कार्याणि न प्रभावितं कृत्वा बृहत्-प्रमाणस्य कार्याणि सम्भालितुं शक्नोति ।

2.6.नियोजनप्रपत्रम्

म.जी.आर

  • MGR एकल-मास्टर-बहु-मास्टर-नियोजन-विधिं समर्थयति बहु-मास्टर-मोड्-मध्ये प्रत्येकं नोड्-इत्येतत् पठितुं लिखितुं च शक्यते, मुख्य-दत्तांशकोशं पठितुं लिखितुं च शक्यते, तथा च स्टैण्डबाई-दत्तांशकोशः केवलं पठितुं शक्यते । केवलम्‌।
  • MGR उच्च-उपलब्धता-नियोजनाय न्यूनातिन्यूनं त्रीणि नोड्-नियोजनानि आवश्यकानि सन्ति, अर्थात् न्यूनातिन्यूनं त्रीणि प्रतिकृतयः दत्तांशस्य लॉग-प्रतिनिधिः च लॉगर-विधिः समर्थितः नास्ति ।
  • MGR केवलं पठनीय-नोड्स्-विस्तारं समर्थयति, परन्तु समान-टोपोलॉजी-विस्तारं प्राप्तुं MGR + master-slave-प्रतिकृति-विधायाः संयोजनं समर्थयति ।

DN

  • DN एक-मास्टर-मोड्-नियोजनं समर्थयति एक-मास्टर-मोड्-मध्ये मुख्य-दत्तांशकोशं पठितुं लिखितुं च शक्यते, तथा च स्टैण्डबाई-दत्तांशकोशः केवलं पठनीयः एव भवितुम् अर्हति ।
  • DN उच्च-उपलब्धता-नियोजनाय न्यूनातिन्यूनं त्रीणि नोड्स् आवश्यकानि सन्ति, परन्तु log copy Logger form समर्थयति, अर्थात् Leader तथा Follower पूर्ण-विशेषतायुक्तानि प्रतिलिपानि सन्ति, Logger इत्यनेन सह तुलने, अस्मिन् केवलं logs सन्ति तथा च कोऽपि data नास्ति, तथा च भवितुं अधिकारः नास्ति निर्वाचित। अस्मिन् सन्दर्भे, त्रि-नोड् उच्च-उपलब्धता-नियोजनाय केवलं 2 प्रतिकृतानां दत्तांशस्य + 3 प्रतिलिपानां लॉग्स् इत्यस्य भण्डारण-उपरिभारस्य आवश्यकता भवति, येन एतत् न्यून-लाभ-नियोजनं भवति
  • DN केवलं पठनीय-नोड्-नियोजनं केवलं पठनीय-प्रतिलिपिं च Learner-प्रपत्रं समर्थयति, पूर्ण-विशेषता-प्रतिकृतीनां तुलने, केवलं Learner-प्रतिकृतीनां माध्यमेन, मुख्यपुस्तकालयस्य अधःप्रवाह-सदस्यता-उपभोगः साकारः भवति

2.7.विशेषतासारांशः

म.जी.आर

DN

प्रोटोकॉल दक्षता

लेनदेन प्रस्तुतीकरण समय

१.५~२.५ आरटीटी

१ आरटीटी

बहुमत दृढ़ता

XCOM स्मृति रक्षतु

बिन्लॉग दृढता

विश्वसनीयता

आरपीओ=0

पूर्वनिर्धारितरूपेण गारण्टी नास्ति

पूर्णतया गारण्टीकृतम्

दोषपरिचयः

सर्वे नोड् परस्परं जाँचयन्ति, जालभारः अधिकः भवति

हृदयस्पन्दनचक्रं समायोजितुं न शक्यते

मुख्यनोड् समये समये अन्येषां नोड्-परीक्षणं करोति

हृदयस्पन्दनचक्रमापदण्डाः समायोज्यः भवन्ति

बहुमत पतन पुनर्प्राप्ति

हस्त हस्तक्षेप

स्वचालित पुनर्प्राप्ति

अल्पसंख्यक दुर्घटना पुनर्प्राप्ति

अधिकांशतया स्वचालितं पुनर्प्राप्तिः, विशेषपरिस्थितौ हस्तहस्तक्षेपः

स्वचालित पुनर्प्राप्ति

स्वामिनं चिनुत

चयनस्य क्रमं स्वतन्त्रतया निर्दिशन्तु

चयनस्य क्रमं स्वतन्त्रतया निर्दिशन्तु

लॉग टाई

पश्चात्तापाः लॉग्स् XCOM 1GB cache अतिक्रमितुं न शक्नुवन्ति

BInlog सञ्चिकाः न विलोप्यन्ते

स्टैण्डबाई डाटाबेस प्लेबैक विलम्ब

द्वौ चरणौ + द्विगुणं एकं, अतीव मन्दम्

एकं चरणं + द्विगुणं शून्यं, द्रुततरम्

बृहत् व्यापार

पूर्वनिर्धारितसीमा १४३MB तः अधिका नास्ति

आकारसीमा नास्ति

आवेदनपत्रं

उच्च उपलब्धता व्ययः

पूर्णतया कार्यात्मकाः त्रीणि प्रतिकृतयः, ३ प्रतिकृतयः दत्तांशसञ्चयस्य उपरि

लॉगर लॉग् प्रतिलिपिः, दत्तांशसञ्चयस्य २ प्रतियाः

केवलं पठनीयः नोडः

स्वामी-दासप्रतिकृतिना सह कार्यान्वितम्

प्रोटोकॉलः Leaner केवलं पठनीयप्रतिलिपि कार्यान्वयनेन सह आगच्छति

3. परीक्षणतुलना

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 आधिकारिकजालस्थलस्य उपयोगं कुर्वन्तु

परिनियोजनविधिः

एकल मास्टर मोड

टीका:

  • MGR इत्यत्र पूर्वनिर्धारितरूपेण प्रवाहनियन्त्रणं सक्षमम् अस्ति, यदा तु PolarDB-X DN इत्यत्र पूर्वनिर्धारितरूपेण प्रवाहनियन्त्रणं निष्क्रियं भवति ।अतः MGR इत्यस्य group_replication_flow_control_mode पृथक् विन्यस्तं भवति येन MGR इत्यस्य कार्यक्षमता सर्वोत्तमा भविष्यति ।
  • MGR इत्यस्य गणनायाः समये स्पष्टः अतः पठनस्य अटङ्कः अस्ति, अतः MGR इत्यस्य replication_optimize_for_static_plugin_config पृथक् विन्यस्तं सक्षमं च भवति, येन MGR इत्यस्य केवलं पठनीयं प्रदर्शनं सर्वोत्तमम् भविष्यति

३.१ कार्यप्रदर्शनम्

दत्तांशकोशस्य चयनं कुर्वन् प्रथमं सर्वेषां ध्यानं कार्यप्रदर्शनपरीक्षणम् अस्ति । अत्र वयं OLTP परिदृश्येषु कार्यप्रदर्शनपरीक्षणं कर्तुं 16 सारणीनिर्माणार्थं, प्रत्येकस्मिन् 10 मिलियनदत्तांशयुक्तानि, तथा च भिन्न-भिन्न-OLTP-परिदृश्येषु भिन्न-भिन्न-समवर्ती-स्थितौ द्वयोः कार्यक्षमतायाः परीक्षणं तुलनां च कर्तुं आधिकारिक-सिस्बेन्च-उपकरणस्य उपयोगं कुर्मःवास्तविकनियोजनस्य भिन्नानि परिस्थितयः विचार्य वयं क्रमशः निम्नलिखितचतुर्णां परिनियोजनपरिदृश्यानां अनुकरणं कुर्मः:

  1. एकस्मिन् सङ्गणककक्षे त्रीणि नोड्स् नियोजिताः सन्ति यदा यन्त्राणि परस्परं ping कुर्वन्ति तदा 0.1ms इत्यस्य जालविलम्बः भवति ।
  2. एकस्मिन् नगरे त्रीणि केन्द्राणि, एकस्मिन् प्रदेशे त्रीणि सङ्गणककक्षाणि च त्रीणि नोड्-नियोजनं कुर्वन्ति सङ्गणक-कक्षेषु (उदाहरणार्थं: शाङ्घाई-नगरे त्रीणि सङ्गणक-कक्षाणि) 1ms-जालविलम्बः भवति ।
  3. द्वयोः स्थानयोः त्रीणि केन्द्राणि, द्वयोः स्थानयोः त्रीणि सङ्गणककक्षेषु त्रीणि नोड्स् नियोजिताः, एकस्मिन् नगरे सङ्गणककक्षयोः मध्ये १ms नेटवर्क् पिंगः, एकस्मिन् एव नगरस्य अन्यस्य च स्थानस्य मध्ये ३०ms नेटवर्क् विलम्बः (उदाहरणार्थं: शाङ्घाई/शाङ्घाई/शेन्झेन्)
  4. त्रीणि स्थानानि त्रीणि केन्द्राणि, त्रीणि नोड्स् त्रयः सङ्गणककक्षेषु त्रीणि स्थानानि (उदाहरणार्थं: शाङ्घाई/हाङ्गझौ/शेन्झेन्) नियोजिताः, हाङ्गझौ-शङ्घाई-योः मध्ये संजालविलम्बः प्रायः ५ms भवति, तथा च हाङ्गझौ/शाङ्घाईतः शेन्झेन्-नगरं यावत् दूरतमं दूरं ३०ms अस्ति .

दृष्टान्तरूपेण दर्शयतु : १.

क. चतुर्णां परिनियोजनपरिदृश्यानां कार्यप्रदर्शनस्य क्षैतिजतुलनं विचारयन्तु, त्रीणि स्थानानि च त्रीणि केन्द्राणि सर्वे 3 प्रतिकृतीनां परिनियोजनविधिं स्वीकुर्वन्ति।

ख परिनियोजन परिदृश्यम् .

  • MGR_0 MGR RPO = 0 इत्यस्य प्रकरणस्य कृते आँकडानां प्रतिनिधित्वं करोति
  • MGR_1 MGR RPO <> 0 इत्यस्य प्रकरणस्य कृते आँकडानां प्रतिनिधित्वं करोति
  • DN DN RPO = 0 इत्यस्य प्रकरणस्य दत्तांशं प्रतिनिधियति

३.१.१.समानः सङ्गणककक्षः

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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • केवलं पठनीयपरिदृश्ये, भवेत् MGR_1 (RPO<>0) अथवा MGR_0 (RPO=0) इत्यस्य तुलनां कृत्वा, DN तथा MGR इत्येतयोः मध्ये अन्तरं -5% तथा 10% मध्ये स्थिरं भवति, यत् मूलतः समानं गणयितुं शक्यते RPO 0 इत्यस्य बराबरः अस्ति वा इति केवलं पठनीयव्यवहारेषु कोऽपि प्रभावः नास्ति
  • मिश्रितपठन-लेखन-मात्र-लेखन-व्यवहार-परिदृश्ये MGR_1 (RPO<>0) इत्यस्य तुलने DN (RPO=0) इत्यस्य प्रदर्शने 5% तः 47% पर्यन्तं सुधारः भवति, तथा च DN इत्यस्य कार्यक्षमतायाः लाभः तदा स्पष्टः भवति यदा... समवर्ती न्यूना भवति, समवर्ती उच्चे भवति तदा लाभः अस्पष्टविशेषताः। यतो हि DN इत्यस्य प्रोटोकॉलदक्षता अधिका भवति यदा समवर्ती न्यूनता भवति, परन्तु उच्चसमवर्ततायाः अन्तर्गतं DN तथा MGR इत्येतयोः प्रदर्शनस्य हॉटस्पॉट् सर्वे सफाईयां भवन्ति
  • RPO=0 इत्यस्य समानपरिकल्पनायाः अन्तर्गतं मिश्रितपठन-लेखन-मात्र-व्यवहार-परिदृश्येषु MGR_0 इत्यस्य तुलने DN इत्यस्य कार्यक्षमतायां 2 गुणातः 46 गुणान् यावत् सुधारः भवति, तथा च यथा यथा समवर्तीता वर्धते तथा तथा DN इत्यस्य कार्यक्षमतायाः लाभः वर्धते न आश्चर्यं यत् MGR अपि पूर्वनिर्धारितरूपेण कार्यक्षमतायाः कृते RPO=0 परित्यजति ।

३.१.२.एकस्मिन् नगरे त्रीणि केन्द्राणि

टीपीएस तुलना

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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • केवलं पठनीयपरिदृश्ये, भवेत् MGR_1 (RPO<>0) अथवा MGR_0 (RPO=0) इत्यस्य तुलनां कृत्वा, DN तथा MGR इत्येतयोः मध्ये अन्तरं -7% तथा 5% मध्ये स्थिरं भवति, यत् मूलतः समानं गणयितुं शक्यते RPO 0 इत्यस्य बराबरः अस्ति वा इति केवलं पठनीयव्यवहारेषु कोऽपि प्रभावः नास्ति
  • मिश्रितपठन-लेखन-मात्र-लेखन-व्यवहार-परिदृश्ये MGR_1 (RPO<>0) इत्यस्य तुलने DN (RPO=0) इत्यस्य कार्यक्षमतायां 30% तः 120% पर्यन्तं सुधारः भवति, तथा च DN इत्यस्य कार्यक्षमतायाः लाभः समवर्ती भवति चेत् स्पष्टः भवति न्यूनं भवति, यदा च समवर्ती अधिका भवति तदा कार्यक्षमता श्रेष्ठा भवति Unobvious features. यतो हि DN इत्यस्य प्रोटोकॉलदक्षता अधिका भवति यदा समवर्ती न्यूनता भवति, परन्तु उच्चसमवर्ततायाः अन्तर्गतं DN तथा MGR इत्येतयोः प्रदर्शनस्य हॉटस्पॉट् सर्वे सफाईयां भवन्ति
  • RPO=0 इत्यस्य समानपरिकल्पनायाः अन्तर्गतं मिश्रितपठन-लेखन-मात्र-व्यवहार-परिदृश्येषु MGR_0 इत्यस्य तुलने DN इत्यस्य कार्यक्षमतायां 1 तः 14 गुणापर्यन्तं सुधारः भवति, तथा च यथा यथा समवर्तीता वर्धते तथा तथा DN इत्यस्य कार्यक्षमतायाः लाभः वर्धते न आश्चर्यं यत् MGR अपि पूर्वनिर्धारितरूपेण कार्यक्षमतायाः कृते RPO=0 परित्यजति ।

३.१.३।द्वौ स्थानौ त्रीणि केन्द्राणि च

टीपीएस तुलना

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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • केवलं पठनीयपरिदृश्ये, भवेत् MGR_1 (RPO<>0) अथवा MGR_0 (RPO=0) इत्यस्य तुलनां कृत्वा, DN तथा MGR इत्येतयोः मध्ये अन्तरं -4% तथा 7% मध्ये स्थिरं भवति, यत् मूलतः समानं गणयितुं शक्यते RPO 0 इत्यस्य बराबरः अस्ति वा इति केवलं पठनीयव्यवहारेषु कोऽपि प्रभावः नास्ति
  • मिश्रितपठन-लेखन-मात्र-लेखन-व्यवहार-परिदृश्ये, DN (RPO=0) इत्यस्य प्रदर्शने MGR_1 (RPO<>0) इत्यस्य तुलने 2 गुणातः 16 गुणापर्यन्तं सुधारः भवति, तथा च DN इत्यस्य कार्यक्षमतायाः लाभः समवर्ती भवति चेत् स्पष्टः भवति न्यूनं भवति, तथा च यदा समवर्तीता उच्चा भवति तदा लाभः अस्पष्टविशेषताः। यतो हि DN इत्यस्य प्रोटोकॉलदक्षता अधिका भवति यदा समवर्ती न्यूनता भवति, परन्तु उच्चसमवर्ततायाः अन्तर्गतं DN तथा MGR इत्येतयोः प्रदर्शनस्य हॉटस्पॉट् सर्वे सफाईयां भवन्ति
  • RPO=0 इत्यस्य समानपरिकल्पनानुसारं मिश्रितपठन-लेखन-मात्र-व्यवहार-परिदृश्येषु MGR_0 इत्यस्य तुलने DN इत्यस्य कार्यक्षमतायां 8 गुणा तः 29 गुणापर्यन्तं सुधारः भवति, तथा च यथा यथा समवर्तीता वर्धते तथा तथा DN इत्यस्य कार्यक्षमतायाः लाभः वर्धते न आश्चर्यं यत् MGR अपि पूर्वनिर्धारितरूपेण कार्यक्षमतायाः कृते RPO=0 परित्यजति ।

३.१.४।त्रयः स्थानानि च त्रीणि केन्द्राणि च

टीपीएस तुलना

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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • केवलं पठनीयपरिदृश्ये, भवेत् MGR_1 (RPO<>0) अथवा MGR_0 (RPO=0) इत्यस्य तुलनां कृत्वा, DN तथा MGR इत्येतयोः मध्ये अन्तरं -5% तथा 0% मध्ये स्थिरं भवति, यत् मूलतः समानं गणयितुं शक्यते RPO 0 इत्यस्य बराबरः अस्ति वा इति केवलं पठनीयव्यवहारेषु कोऽपि प्रभावः नास्ति
  • मिश्रितपठन-लेखन-मात्र-लेखन-व्यवहार-परिदृश्ये, DN (RPO=0) इत्यस्य प्रदर्शने MGR_1 (RPO<>0) इत्यस्य तुलने 2 गुणातः 5 गुणापर्यन्तं सुधारः भवति, तथा च DN इत्यस्य कार्यक्षमतायाः लाभः समवर्ती भवति चेत् स्पष्टः भवति न्यूनं भवति, तथा च यदा समवर्तीता उच्चा भवति तदा लाभः अस्पष्टविशेषताः। यतो हि DN इत्यस्य प्रोटोकॉलदक्षता अधिका भवति यदा समवर्ती न्यूनता भवति, परन्तु उच्चसमवर्ततायाः अन्तर्गतं DN तथा MGR इत्येतयोः प्रदर्शनस्य हॉटस्पॉट् सर्वे सफाईयां भवन्ति
  • RPO=0 इत्यस्य समानपरिकल्पनायाः अन्तर्गतं मिश्रितपठन-लेखन-मात्र-व्यवहार-परिदृश्येषु MGR_0 इत्यस्य तुलने DN इत्यस्य कार्यक्षमतायां 2 गुणातः 17 गुणापर्यन्तं सुधारः भवति, तथा च यथा यथा समवर्तीता वर्धते तथा तथा DN इत्यस्य कार्यक्षमतायाः लाभः वर्धते न आश्चर्यं यत् MGR अपि पूर्वनिर्धारितरूपेण कार्यक्षमतायाः कृते RPO=0 परित्यजति ।

३.१.५ परिनियोजनतुलना

विभिन्ननियोजनविधिषु कार्यप्रदर्शनपरिवर्तनानां स्पष्टतया तुलनां कर्तुं वयं उपर्युक्तपरीक्षायां 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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • परिनियोजनपद्धतेः विस्तारेण सह MGR_1 (RPO<>0) इत्यस्य TPS इत्यस्य तुलने एकस्मिन् एव नगरे क्रॉस्-कम्प्यूटर-कक्षस्य परिनियोजनस्य प्रदर्शनं 27.5% न्यूनीकृतम् of cross-city (three centers in two places, three centers in three places) deployment ७७%~८२% न्यूनता, यत् आरटी-नगरस्य पार-नगरनियोजनस्य वृद्धेः कारणम् अस्ति
  • DN (RTO=0) तुल्यकालिकरूपेण स्थिरं भवति, एकस्मिन् एव नगरे क्रॉस्-कम्प्यूटर-कक्षस्य परिनियोजनस्य, द्वयोः स्थानयोः त्रयाणां केन्द्राणां परिनियोजनस्य च कार्यक्षमता ४% तः १२% यावत् न्यूनीभूता । .परन्तु DN इत्यस्य Batch&Pipeline तन्त्रस्य धन्यवादेन समवर्तीतां वर्धयित्वा क्रॉस्-सिटी-प्रभावस्य समाधानं कर्तुं शक्यते उदाहरणार्थं त्रि-स्थान-त्रि-केन्द्र-वास्तुकला-अन्तर्गतं, >=512 समवर्ती, एकस्मिन् नगरे प्रदर्शन-थ्रूपुट् च द्वौ च स्थानानि त्रीणि च केन्द्राणि मूलतः संरेखितुं शक्यन्ते।
  • द्रष्टुं शक्यते यत् नगरान्तरनियोजनस्य MGR_1 (RPO<>0) इत्यत्र महत् प्रभावः भवति ।

3.1.6.प्रदर्शन जिटर

वास्तविकप्रयोगे वयं न केवलं कार्यप्रदर्शनदत्तांशं प्रति ध्यानं दद्मः, अपितु कार्यप्रदर्शनस्य jitter इत्यत्र अपि ध्यानं दातुं प्रवृत्ताः भवेम । अन्ततः यदि जिटर रोलरकोस्टर इव भवति तर्हि वास्तविकः उपयोक्तृअनुभवः अतीव दुर्बलः भविष्यति । वयं TPS वास्तविकसमयनिर्गमदत्तांशस्य निरीक्षणं प्रदर्शयामः च यत् sysbenc उपकरणं स्वयं प्रदर्शनजिटरस्य उत्पादननिरीक्षणदत्तांशस्य समर्थनं न करोति, वयं तुलनासूचकरूपेण भिन्नतायाः गणितीयगुणकस्य उपयोगं कुर्मः:

  • भिन्नतायाः गुणांकः (CV): भिन्नतायाः गुणांकः औसतेन विभक्तः मानकविचलनः भवति, विशेषतः यदा मध्यमान्तराणि बृहत् भवन्ति सीवी यावत् बृहत् भवति तावत् मध्यमस्य सापेक्षतया दत्तांशस्य उतार-चढावः अधिकः भवति ।

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%

परीक्षणपरिणामात् द्रष्टुं शक्यते- १.

  • MGR इत्यस्य TPS oltp_read_write परिदृश्ये अस्थिरस्थितौ अस्ति, तथा च एतत् अचानकं अकारणं तीव्ररूपेण पतति, एषा घटना बहुविधनियोजनपरिदृश्येषु बहुपरीक्षासु प्राप्ता अस्ति तुलने डीएन अतीव स्थिरः अस्ति ।
  • भिन्नतायाः गुणांकस्य CV गणयन् MGR इत्यस्य CV अतीव विशालः भवति, 6% तः 10% पर्यन्तं, अपि च यदा एकस्मिन् एव सङ्गणककक्षे विलम्बः न्यूनतमः भवति तदा 10% अधिकतमं मूल्यं प्राप्नोति, यदा DN इत्यस्य CV तुल्यकालिकरूपेण स्थिरः भवति, 2% तः 4 %, तथा च DN इत्यस्य प्रदर्शनं MGR इत्यस्मात् अधिकं स्थिरं भवति Sex मूलतः द्विगुणं अधिकं भवति
  • द्रष्टुं शक्यते यत् MGR_1 (RPO<>0) इत्यस्य कार्यक्षमतायाः जिटरः तुल्यकालिकरूपेण बृहत् अस्ति

३.२. आरटीओ

वितरितदत्तांशकोशस्य मूलविशेषता उच्चा उपलब्धता अस्ति । एकस्मिन् सङ्गणककक्षे एकेन मास्टरेन सह द्वौ बैकअपौ च नियोजितौ 3 नोड्स इत्यस्य विशिष्टनियोजनरूपस्य कृते वयं निम्नलिखितत्रिषु परिदृश्येषु उपयोगितापरीक्षां कर्तुं प्रयत्नम् अकरोम:

  • मुख्यदत्तांशकोशं बाधित्वा, ततः पुनः आरभत, प्रक्रियायाः समये उपलब्धतां पुनः स्थापयितुं क्लस्टरस्य कृते RTO समयं अवलोकयन्तु ।
  • कस्यापि स्टैण्डबाई दत्तांशकोशस्य बाधां कुर्वन्तु ततः प्रक्रियायाः समये प्राथमिकदत्तांशकोशस्य उपलब्धताप्रदर्शनं अवलोकयितुं पुनः आरभ्यताम् ।

3.2.1.मुख्यदत्तांशकोशस्य अवकाशसमयः + पुनः आरम्भः

यदा भारः नास्ति तदा लीडरं मारयन्तु तथा च क्लस्टरस्य प्रत्येकस्य नोड् इत्यस्य स्थितिपरिवर्तनस्य निरीक्षणं कुर्वन्तु तथा च सः लेखनीयः अस्ति वा इति ।

म.जी.आर

DN

सामान्यतः आरभ्य

0

0

नेतारं मारयतु

0

0

असामान्यः नोडसमयः प्राप्तः

5

5

३ नोड्स् २ नोड् यावत् न्यूनीकर्तुं समयः

23

8

म.जी.आर

DN

सामान्यतः आरभ्य

0

0

नेतारं मारयन्तु, स्वयमेव उपरि आकर्षयन्तु

0

0

असामान्यः नोडसमयः प्राप्तः

5

5

३ नोड्स् २ नोड् यावत् न्यूनीकर्तुं समयः

23

8

२ नोड् पुनर्स्थापनम् ३ नोड् समयः

37

15

परीक्षणपरिणामात् द्रष्टुं शक्यते यत् कोऽपि दबावस्य परिस्थितौ : १.

  • DN इत्यस्य RTO 8-15s भवति, 2 नोड् यावत् न्यूनीकर्तुं 8s, 3 नोड् पुनः स्थापयितुं 15s च भवति;
  • MGR इत्यस्य RTO 23-37s भवति
  • आरटीओ प्रदर्शनं डीएन समग्रतया एमजीआर इत्यस्मात् उत्तमम् अस्ति

3.2.2.स्टैण्डबाई डाटाबेस डाउनटाइम + पुनः आरम्भः

oltp_read_write परिदृश्ये 16 थ्रेड् इत्यस्य समवर्ती तनावपरीक्षां कर्तुं sysbench इत्यस्य उपयोगं कुर्वन्तु, चित्रे 10 तमे सेकेण्ड् मध्ये, मैन्युअल् रूपेण एकं स्टैण्डबाई नोड् मारयन्तु तथा च sysbench इत्यस्य वास्तविकसमयस्य आउटपुट् TPS आँकडानां अवलोकनं कुर्वन्तु ।

परीक्षणपरिणामचार्टात् द्रष्टुं शक्यते : १.

  • स्टैण्डबाई-दत्तांशकोशस्य बाधायाः अनन्तरं MGR इत्यस्य मुख्यदत्तांशकोशस्य TPS महत्त्वपूर्णतया न्यूनीकृतः, सामान्यस्तरं प्रति प्रत्यागन्तुं पूर्वं प्रायः २० सेकेण्ड् यावत् स्थापितः । लॉग् विश्लेषणस्य अनुसारम् अत्र द्वौ प्रक्रिया स्तः - दोषपूर्णः नोड् अप्राप्यः जातः इति ज्ञात्वा दोषपूर्णं नोड् MGR क्लस्टरात् बहिः पादं पातयति एतेन परीक्षणेन एकः दोषः पुष्टीकृतः यः MGR समुदाये दीर्घकालं यावत् प्रचलति यद्यपि 3 नोड् मध्ये केवलं 1 नोड् अनुपलब्धः अस्ति।सम्पूर्णः समूहः किञ्चित्कालं यावत् तीव्रं क्षोभं अनुभवति स्म, अनुपलब्धः च अभवत् ।
  • एक-मास्टर MGR इत्यस्य एकस्य नोड्-विफलतायाः समस्यायाः समाधानार्थं सम्पूर्णं उदाहरणं च अनुपलब्धं भवितुं समुदायेन समस्यायाः समाधानार्थं 8.0.27 तः MGR paxos एक-लीडर-कार्यं प्रवर्तयति स्म, परन्तु पूर्वनिर्धारितरूपेण अवरितम् अस्ति अत्र वयं group_replication_paxos_single_leader इत्येतत् चालू कुर्मः तथा च अस्मिन् समये स्टैण्डबाई डाटाबेस् मध्ये बाधां कृत्वा मुख्यदत्तांशकोशस्य कार्यक्षमता स्थिरं भवति तथा च किञ्चित् सुधारं कृतवान् कारणं नेटवर्क् लोड् इत्यस्य न्यूनीकरणेन सह सम्बद्धं भवितुमर्हति
  • DN कृते, स्टैण्डबाई-दत्तांशकोशस्य बाधितस्य अनन्तरं, मुख्यदत्तांशकोशस्य TPS तत्क्षणमेव प्रायः 20% वर्धितः, ततः स्थिरः अभवत्, तथा च क्लस्टरः सर्वदा उपलब्धः आसीत्एतत् MGR इत्यस्य विपरीतम् अस्ति यत् स्टैण्डबाई दत्तांशकोशं बाधित्वा मुख्यदत्तांशकोशे केवलं प्रत्येकं समये अवशिष्टं स्टैण्डबाई दत्तांशकोशं प्रति लॉग्स् प्रेषयितुं आवश्यकं भवति, तथा च संजालपैकेट् प्रेषणप्राप्तिः प्रक्रिया अधिका कार्यक्षमा भवति

परीक्षणं निरन्तरं कुर्वन्तः वयं स्टैण्डबाई-दत्तांशकोशं पुनः आरभ्य पुनः स्थापयामः तथा च मुख्यदत्तांशकोशस्य TPS-दत्तांशस्य परिवर्तनं अवलोकयामः ।

परीक्षणपरिणामचार्टात् द्रष्टुं शक्यते : १.

  • एमजीआर ५ सेकेण्ड् मध्ये २ नोड् तः ३ नोड् यावत् पुनः प्राप्तवान् ।परन्तु मुख्यपुस्तकालयः अनुपलब्धः इति अपि स्थितिः अस्ति, यत् प्रायः १२ सेकेण्ड् यावत् भवति ।यद्यपि स्टैण्डबाई नोड् अन्ततः क्लस्टर् मध्ये सम्मिलितः, तथापि MEMBER_STATE स्थितिः सर्वदा RECOVERING आसीत्, यत् सूचयति यत् अस्मिन् समये दत्तांशः अनुसृतः भवति ।
  • group_replication_paxos_single_leader इत्यस्य सक्षमीकरणस्य अनन्तरं परिदृश्ये, स्टैण्डबाई डाटाबेस् पुनः आरम्भः अपि सत्यापितः भवति फलतः, ​​MGR 10 सेकेण्ड् मध्ये 2 नोड् तः 3 नोड् यावत् पुनः प्राप्तः भवति ।परन्तु अद्यापि प्रायः ७ सेकेण्ड् यावत् अनुपलब्धः समयः आसीत् ।इदं प्रतीयते यत् एषः पैरामीटर् एक-मास्टर-एमजीआर-इत्यस्य एकस्य नोड्-विफलतायाः, सम्पूर्णस्य दृष्टान्तस्य च अनुपलब्धतायाः समस्यायाः पूर्णतया समाधानं कर्तुं न शक्नोति
  • DN कृते, स्टैण्डबाई-दत्तांशकोशः १० सेकेण्ड्-मध्ये २ नोड्-तः ३ नोड्-पर्यन्तं पुनः प्राप्तः भवति, प्राथमिकदत्तांशकोशः च उपलब्धः एव तिष्ठति । अत्र TPS मध्ये अल्पकालिकं उतार-चढावः भविष्यति यतोहि पुनः आरब्धस्य स्टैण्डबाई-दत्तांशकोशस्य लॉग-प्रतिकृति-विलम्बः पृष्ठतः अस्ति, तथा च पश्चात्ताप-लॉग्स् मुख्य-दत्तांशकोशात् आकर्षयितुं आवश्यकम् अस्ति main database इति लॉग समीक्षायाः अनन्तरं समग्रं प्रदर्शनं स्थिरं भविष्यति ।

३.३. आर पी ओ

MGR बहुमतविफलता RPO<>0 परिदृश्यस्य निर्माणार्थं वयं MGR इत्यत्र दोष-इञ्जेक्शन-परीक्षणं कर्तुं समुदायस्य स्वकीयायाः MTR Case पद्धतेः उपयोगं कुर्मः ।

  1. --echo
  2. --echo ############################################################
  3. --echo # 1. Deploy a 3 members group in single primary mode.
  4. --source include/have_debug.inc
  5. --source include/have_group_replication_plugin.inc
  6. --let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
  7. --let $rpl_group_replication_single_primary_mode=1
  8. --let $rpl_skip_group_replication_start= 1
  9. --let $rpl_server_count= 3
  10. --source include/group_replication.inc
  11.  
  12. --let $rpl_connection_name= server1
  13. --source include/rpl_connection.inc
  14. --let $server1_uuid= `SELECT @@server_uuid`
  15. --source include/start_and_bootstrap_group_replication.inc
  16.  
  17. --let $rpl_connection_name= server2
  18. --source include/rpl_connection.inc
  19. --source include/start_group_replication.inc
  20.  
  21. --let $rpl_connection_name= server3
  22. --source include/rpl_connection.inc
  23. --source include/start_group_replication.inc
  24.  
  25. --echo
  26. --echo ############################################################
  27. --echo # 2. Init data
  28. --let $rpl_connection_name = server1
  29. --source include/rpl_connection.inc
  30. CREATE TABLE t1 (c1 INT PRIMARY KEY);
  31. INSERT INTO t1 VALUES(1);
  32.  
  33. --source include/rpl_sync.inc
  34. SELECT * FROM t1;
  35.  
  36. --let $rpl_connection_name = server2
  37. --source include/rpl_connection.inc
  38. SELECT * FROM t1;
  39.  
  40. --let $rpl_connection_name = server3
  41. --source include/rpl_connection.inc
  42. SELECT * FROM t1;
  43.  
  44. --echo
  45. --echo ############################################################
  46. --echo # 3. Mock crash majority members
  47.  
  48. --echo # server 2 wait before write relay log
  49. --let $rpl_connection_name = server2
  50. --source include/rpl_connection.inc
  51. SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
  52.  
  53. --echo # server 3 wait before write relay log
  54. --let $rpl_connection_name = server3
  55. --source include/rpl_connection.inc
  56. SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
  57.  
  58.  
  59. --echo # server 1 commit new transaction
  60. --let $rpl_connection_name = server1
  61. --source include/rpl_connection.inc
  62. INSERT INTO t1 VALUES(2);
  63. # server 1 commit t1(c1=2) record
  64. SELECT * FROM t1;
  65. 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;
  66. --echo # server 1 crash
  67. --source include/kill_mysqld.inc
  68.  
  69. --echo # sleep enough time for electing new leader
  70. sleep 60;
  71.  
  72. --echo 
  73. --echo # server 3 check
  74. --let $rpl_connection_name = server3
  75. --source include/rpl_connection.inc
  76. SELECT * FROM t1;
  77. 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;
  78. --echo # server 3 crash and restart
  79. --source include/kill_and_restart_mysqld.inc
  80.  
  81. --echo # sleep enough time for electing new leader
  82. sleep 60;
  83.  
  84. --echo 
  85. --echo # server 2 check
  86. --let $rpl_connection_name = server2
  87. --source include/rpl_connection.inc
  88. SELECT * FROM t1;
  89. 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;
  90. --echo # server 2 crash and restart
  91. --source include/kill_and_restart_mysqld.inc
  92.  
  93. --echo # sleep enough time for electing new leader
  94. sleep 60;
  95.  
  96. --echo
  97. --echo ############################################################
  98. --echo # 4. Check alive members, lost t1(c1=2) record
  99.  
  100. --echo # server 3 check
  101. --let $rpl_connection_name= server3
  102. --source include/rpl_connection.inc
  103. 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;
  104. --echo # server 3 lost t1(c1=2) record
  105. SELECT * FROM t1;
  106.  
  107. --echo 
  108. --echo # server 2 check
  109. --let $rpl_connection_name = server2
  110. --source include/rpl_connection.inc
  111. 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;
  112. --echo # server 2 lost t1(c1=2) record
  113. SELECT * FROM t1;
  1. !include ../my.cnf
  2.  
  3. [mysqld.1]
  4. loose-group_replication_member_weight=100
  5.  
  6. [mysqld.2]
  7. loose-group_replication_member_weight=90
  8.  
  9. [mysqld.3]
  10. loose-group_replication_member_weight=80
  11.  
  12. [ENV]
  13. SERVER_MYPORT_3=		@mysqld.3.port
  14. SERVER_MYSOCK_3=		@mysqld.3.socket

केस रनिंग् परिणामाः निम्नलिखितरूपेण सन्ति ।

  1.  
  2. ############################################################
  3. # 1. Deploy a 3 members group in single primary mode.
  4. include/group_replication.inc [rpl_server_count=3]
  5. Warnings:
  6. Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
  7. 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.
  8. [connection server1]
  9. [connection server1]
  10. include/start_and_bootstrap_group_replication.inc
  11. [connection server2]
  12. include/start_group_replication.inc
  13. [connection server3]
  14. include/start_group_replication.inc
  15.  
  16. ############################################################
  17. # 2. Init data
  18. [connection server1]
  19. CREATE TABLE t1 (c1 INT PRIMARY KEY);
  20. INSERT INTO t1 VALUES(1);
  21. include/rpl_sync.inc
  22. SELECT * FROM t1;
  23. c1
  24. 1
  25. [connection server2]
  26. SELECT * FROM t1;
  27. c1
  28. 1
  29. [connection server3]
  30. SELECT * FROM t1;
  31. c1
  32. 1
  33.  
  34. ############################################################
  35. # 3. Mock crash majority members
  36. # server 2 wait before write relay log
  37. [connection server2]
  38. SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
  39. # server 3 wait before write relay log
  40. [connection server3]
  41. SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
  42. # server 1 commit new transaction
  43. [connection server1]
  44. INSERT INTO t1 VALUES(2);
  45. SELECT * FROM t1;
  46. c1
  47. 1
  48. 2
  49. 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;
  50. CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
  51. group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
  52. group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
  53. group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
  54. # server 1 crash
  55. # Kill the server
  56. # sleep enough time for electing new leader
  57.  
  58. # server 3 check
  59. [connection server3]
  60. SELECT * FROM t1;
  61. c1
  62. 1
  63. 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;
  64. CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
  65. group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
  66. group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
  67. # server 3 crash and restart
  68. # Kill and restart
  69. # sleep enough time for electing new leader
  70.  
  71. # server 2 check
  72. [connection server2]
  73. SELECT * FROM t1;
  74. c1
  75. 1
  76. 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;
  77. CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
  78. group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
  79. group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
  80. # server 2 crash and restart
  81. # Kill and restart
  82. # sleep enough time for electing new leader
  83.  
  84. ############################################################
  85. # 4. Check alive members, lost t1(c1=2) record
  86. # server 3 check
  87. [connection server3]
  88. 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;
  89. CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
  90. group_replication_applier		NULL	OFFLINE			
  91. # server 3 lost t1(c1=2) record
  92. SELECT * FROM t1;
  93. c1
  94. 1
  95.  
  96. # server 2 check
  97. [connection server2]
  98. 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;
  99. CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
  100. group_replication_applier		NULL	OFFLINE			
  101. # server 2 lost t1(c1=2) record
  102. SELECT * FROM t1;
  103. c1
  104. 1

लुप्तसङ्ख्याः पुनः प्रदर्शयति इति प्रकरणस्य अनुमानतः तर्कः यथा भवति ।

  1. MGR इत्यस्मिन् एकल-मास्टर-मोड्, सर्वर 1/2/3 इत्यस्मिन् 3 नोड् सन्ति, यत्र सर्वर 1 मुख्यदत्तांशकोशः अस्ति तथा च 1 अभिलेखं c1=1 आरभते
  2. Relay Log इति लेखनं कुर्वन् Fault injection Server 2/3 लम्बते
  3. Server 1 नोड् इत्यनेन सह सम्बद्धः, c1=2 इत्यस्य अभिलेखं लिखितवान्, तथा च लेनदेनप्रतिबद्धता अपि सफलतां प्रत्यागच्छत् ।
  4. ततः Mock server1 असामान्यतया क्रैश भवति (यन्त्रस्य विफलता, पुनः स्थापयितुं न शक्यते, तथा च अभिगन्तुं न शक्यते अस्मिन् समये, Server 2/3 बहुमतं निर्मातुं अवशिष्टम् अस्ति ।
  5. सामान्यतया सर्वर 2/3 पुनः आरभत (त्वरितपुनर्प्राप्तिः), परन्तु सर्वर 2/3 क्लस्टरं उपयोगयोग्यस्थितौ पुनः स्थापयितुं न शक्नोति ।
  6. Server 2/3 नोड् इत्यनेन सह सम्बद्धं कुर्वन्तु तथा च database records इत्यस्य प्रश्नं कुर्वन्तु केवलं c1=1 इत्यस्य अभिलेखः एव दृश्यते (Server 2/3 इत्यनेन c1=2 इत्यस्य हानिः कृता अस्ति) ।

उपर्युक्तप्रकरणस्य अनुसारं MGR कृते, यदा बहुसंख्यकं सर्वरं निष्क्रियं भवति तथा च मुख्यदत्तांशकोशः अनुपलब्धः भवति, तदा स्टैण्डबाईदत्तांशकोशस्य पुनर्स्थापनानन्तरं RPO<>0 इत्यस्य दत्तांशहानिः भविष्यति, तथा च सफलप्रतिबद्धतायाः अभिलेखः यः आसीत् मूलतः ग्राहकं प्रति प्रत्यागतं नष्टं भवति।

DN कृते बहुमतस्य प्राप्त्यर्थं बहुमतेन लॉग्स् स्थातुं आवश्यकं भवति, अतः उपर्युक्तपरिदृश्ये अपि दत्तांशः न नष्टः भविष्यति तथा च RPO=0 गारण्टी कर्तुं शक्यते

3.4.स्टैण्डबाई डाटाबेस प्लेबैक विलम्ब

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 इत्यस्य स्टैण्डबाई डाटाबेक् प्लेबैकस्य समाप्तिसमयः MGR इत्यस्य समयस्य उपभोगः केवलं 3% तः 4% पर्यन्तं भवति । सक्रिय/स्टैण्डबाई स्विचओवरस्य समयसापेक्षतायै एतत् महत्त्वपूर्णम् अस्ति ।
  • यथा यथा लेखनस्य संख्या वर्धते तथा तथा MGR इत्यस्य अपेक्षया DN इत्यस्य स्टैण्डबाई डाटाबेस् प्लेबैक् विलम्बतालाभः निरन्तरं निर्वाहितः भवति तथा च अतीव स्थिरः भवति ।
  • स्टैण्डबाई डाटाबेस प्लेबैक विलम्बस्य कारणानां विश्लेषणं कृत्वा, MGR इत्यस्य स्टैण्डबाई डाटाबेस प्लेबैक रणनीति EVENTUAL इत्यस्य पूर्वनिर्धारितमूल्येन सह group_replication_consistency स्वीकुर्वति, अर्थात् RO तथा RW लेनदेनाः निष्पादनात् पूर्वं पूर्वव्यवहारस्य अनुप्रयोगस्य प्रतीक्षां न कुर्वन्ति एतेन मुख्यदत्तांशकोशस्य अधिकतमं लेखनप्रदर्शनं सुनिश्चितं कर्तुं शक्यते, परन्तु स्टैण्डबाईदत्तांशकोशविलम्बः तुल्यकालिकरूपेण बृहत् भविष्यति (मुख्यदत्तांशकोशस्य उच्चप्रदर्शनलेखनस्य विनिमयरूपेण स्टैण्डबाईदत्तांशकोशविलम्बं तथा RPO=0 बलिदानं कृत्वा, वर्तमानसीमितकार्यं चालू कृत्वा of MGR can balance performance and स्टैण्डबाई दत्तांशकोशः विलम्बितः अस्ति, परन्तु मुख्यदत्तांशकोशस्य कार्यक्षमतायाः सम्झौता भविष्यति)

3.5.परीक्षासारांशः

म.जी.आर

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 इत्यस्य २५ गुणा भवति ।

पैरामीटर्

कील पैरामीटर
  • group_replication_flow_control_mode प्रवाहनियन्त्रणं पूर्वनिर्धारितरूपेण सक्षमं भवति तथा च कार्यक्षमतां सुधारयितुम् अवरम्भयितुं विन्यस्तं करणीयम् ।
  • replication_optimize_for_static_plugin_config स्थिरप्लग-इन् अनुकूलनं पूर्वनिर्धारितरूपेण निष्क्रियं भवति तथा च कार्यक्षमतां सुधारयितुम् चालू करणीयम् अस्ति
  • group_replication_paxos_single_leader पूर्वनिर्धारितरूपेण निष्क्रियं भवति तथा च मुख्यदत्तांशकोशस्य स्थिरतां सुधारयितुम् यदा स्टैण्डबायदत्तांशकोशः अधः भवति तदा चालू करणीयम् अस्ति ।
  • group_replication_consistency पूर्वनिर्धारितरूपेण निष्क्रियं भवति तथा च RPO=0 इत्यस्य गारण्टीं न ददाति यदि RPO=0 आवश्यकं भवति तर्हि AFTER विन्यस्तं कर्तव्यम् ।
  • पूर्वनिर्धारितं group_replication_transaction_size_limit 143M अस्ति, यत् बृहत् लेनदेनस्य सम्मुखीकरणे वर्धयितुं आवश्यकम् अस्ति ।
  • binlog_transaction_dependency_tracking COMMIT_ORDER इत्यत्र पूर्वनिर्धारितं भवति MGR इत्यस्य WRITESET इत्यत्र समायोजितस्य आवश्यकता वर्तते यत् स्टैण्डबाई डाटाबेस प्लेबैक प्रदर्शनं सुदृढं भवति ।

पूर्वनिर्धारितविन्यासः, विन्यासस्य अनुकूलनार्थं व्यावसायिकानां आवश्यकता नास्ति

4. सारांशः

गहनतया तकनीकीविश्लेषणस्य कार्यप्रदर्शनस्य च तुलनायाः अनन्तरंPolarDB-X स्वविकसितस्य X-Paxos प्रोटोकॉलस्य अनुकूलितस्य डिजाइनस्य च श्रृङ्खलायाः सह DN इत्यनेन MySQL MGR इत्यस्य अपेक्षया कार्यप्रदर्शनस्य, सम्यक्त्वस्य, उपलब्धतायाः, संसाधनस्य उपरितनस्य च दृष्ट्या बहवः लाभाः प्रदर्शिताः तथापि MySQL पारिस्थितिकीतन्त्रे अपि महत्त्वपूर्णं स्थानं धारयति , विभिन्नानि परिस्थितयः यथा स्टैण्डबाई डाटाबेस आउटेज जिटर, क्रॉस्-मशीन रूम आपदा पुनर्प्राप्ति प्रदर्शनस्य उतार-चढावः, स्थिरता च विचारणीयाः अतः यदि भवान् MGR इत्यस्य सदुपयोगं कर्तुम् इच्छति तर्हि व्यावसायिकतकनीकी तथा संचालन तथा अनुरक्षणदलेन सुसज्जितः भवितुमर्हति समर्थनम्‌।

यदा बृहत्-परिमाणेन, उच्च-समवर्ती, उच्च-उपलब्धता-आवश्यकतानां सामना भवति तदा PolarDB-X भण्डारण-इञ्जिनस्य अद्वितीयाः तकनीकीलाभाः सन्ति, उत्तमं प्रदर्शनं च भवतिPolarDB-XDN-आधारितस्य केन्द्रीकृतस्य (मानकसंस्करणस्य) कार्याणां कार्यक्षमतायाः च मध्ये उत्तमः संतुलनः भवति, येन एतत् अत्यन्तं प्रतिस्पर्धात्मकं दत्तांशकोशसमाधानं भवति ।

व्यक्तिगत प्रोफाइल

सः ३० वर्षाणाम् अधिकं कालात् प्रौद्योगिक्याः शोधकार्यं कर्तुं समर्पितः अस्ति, तथा च जावा, लिनक्स, जावास्क्रिप्ट्, php, css इत्यादिषु विविधभाषासु प्रवीणः अस्ति, मुक्तस्रोतक्षेत्रे सः बहु योगदानं कृतवान् अस्ति विकासक दस्तावेजीकरणस्थानकं भविष्ये सन्दर्भार्थं प्रौद्योगिकीविकासे केचन विषयाः साझां कर्तुं सर्वे तत् पश्यन्तु

मम सम्पर्कसूचना

मेल