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

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

---

1. आधारभूतसंरचना : SQL क्वेरी स्टेट्मेण्ट् कथं निष्पादितं भवति ?

अवलोकनम्

सामान्यतया MySQL द्वयोः स्तरयोः विभक्तुं शक्यते

• सर्वर लेयर
  MySQL इत्यस्य अधिकांशं मूलसेवाकार्यं आच्छादयति
  • संयोजकः
  • क्वेरी कैश
  • विश्लेषक
  • अनुकूलकः
  • एक्ट्यूएटर
  • सर्वाणि अन्तर्निर्मितकार्यं (यथा तिथिः, समयः, गणितीयगुप्तलेखनकार्यम् इत्यादयः)
  • भण्डारणइञ्जिनेषु क्षमताः
    • संगृहीत प्रक्रिया
    • प्रवर्त्यम्
    • दृश्यं
    • ……
• भण्डारण इञ्जिन स्तर
  प्लग-इन् आर्किटेक्चर, दत्तांशसञ्चयस्य पुनर्प्राप्तेः च उत्तरदायी
  • इनोदब
  • ममिसम्
  • स्मृति

संयोजकः

mysql -h$ip -P$port -u$user -p
1

संयोजनादेशे mysql इति क्लायन्ट्-उपकरणं सर्वरेण सह संयोजनं स्थापयितुं उपयुज्यते ।क्लासिक TCP हस्तप्रहारं सम्पन्नं कृत्वा, संयोजकः
भवतः परिचयस्य प्रमाणीकरणं आरभ्यतुं प्रवृत्तम् अस्ति अस्मिन् समये भवता प्रविष्टं उपयोक्तृनाम गुप्तशब्दं च उपयुज्यते ।

• यदि उपयोक्तृनाम अथवा गुप्तशब्दः अशुद्धः अस्ति तर्हि भवान् "Access denied for user" इति त्रुटिं प्राप्स्यति, ततः क्लायन्ट् प्रोग्राम्
  निष्पादनं समाप्तं कुर्वन्तु।
• यदि उपयोक्तृनाम गुप्तशब्दप्रमाणीकरणं च गच्छति तर्हि संयोजकः भविष्यतिअनुमतिः सारणी तत्र भवतः काः अनुमतिः सन्ति इति ज्ञातव्यम्।तदनन्तरं अस्मिन् सन्दर्भे
  अनुमतिनिर्णयतर्कः अस्मिन् समये पठितानां अनुमतिनां उपरि निर्भरं भविष्यति ।

यदि क्लायन्ट् बहुकालं यावत् निष्क्रियः अस्ति तर्हि संयोजकः स्वयमेव तस्य संयोजनं विच्छिन्दति । एषः समयः wait_timeout इति पैरामीटर् द्वारा नियन्त्रितः भवति, पूर्वनिर्धारितं मूल्यं च 8 घण्टाः अस्ति ।

यदि ग्राहकः संयोजनस्य विच्छेदनानन्तरं पुनः अनुरोधं प्रेषयति तर्हि सः त्रुटिस्मरणं प्राप्स्यति: Lost connection to MySQL server during query . यदि भवान् अस्मिन् समये निरन्तरं कर्तुम् इच्छति तर्हि पुनः संयोजयितुं ततः अनुरोधं निष्पादयितुं आवश्यकम् ।

दत्तांशकोशे दीर्घकालं यावत् संयोजनस्य अर्थः अस्ति यत् संयोजनस्य सफलतायाः अनन्तरं यदि क्लायन्ट् अनुरोधं निरन्तरं करोति तर्हि सदैव समानं संयोजनं उपयुज्यते । लघुसंयोजनस्य अर्थः अस्ति यत् कतिपयानां प्रश्नानां निष्पादनानन्तरं संयोजनं विच्छिन्नं भवति, अग्रिमप्रश्नानां कृते नूतनं पुनः स्थापितं भवति ।

संयोजनस्थापनस्य प्रक्रिया प्रायः जटिला भवति, अतः अहं सुझावमिदं ददामि यत् भवन्तः उपयोगकाले संयोजनस्थापनस्य क्रियाः न्यूनीकर्तुं प्रयतन्ते अर्थात् दीर्घसंयोजनानां उपयोगं कर्तुं प्रयतन्ते

परन्तु सर्वेषां दीर्घकालीनसंयोजनानां उपयोगानन्तरं भवान् पश्यति यत् कदाचित् MySQL द्वारा आकृष्टा स्मृतिः अतीव शीघ्रं वर्धतेनिष्पादनकाले MySQL द्वारा अस्थायीरूपेण प्रयुक्ता स्मृतिः संयोजनवस्तुनि प्रबन्धिता भवति । . यदा संयोजनं विच्छिन्नं भवति तदा एते संसाधनाः मुक्ताः भविष्यन्ति ।अतः यदिदीर्घसंयोजनानां सञ्चयेन अत्यधिकं स्मृतिप्रयोगः भवितुम् अर्हति ।, प्रणाल्याः (OOM) बलात् मारितः आसीत् ।

एतस्याः समस्यायाः समाधानं कथं करणीयम् ? भवन्तः निम्नलिखितविकल्पद्वयं विचारयितुं शक्नुवन्ति ।

• समये समये दीर्घसंयोजनानि विच्छिन्दन्तु . किञ्चित्कालं यावत् तस्य उपयोगानन्तरं, अथवा स्मृतिं गृह्णाति विशालः प्रश्नः निष्पादितः इति कार्यक्रमेन निर्धारितस्य अनन्तरं, संयोजनं विच्छिन्नं भवति, ततः प्रश्नः आवश्यकः भवति ततः पुनः संयोजितः भवति
• यदि भवान् MySQL 5.7 अथवा नूतनतरस्य उपयोगं करोति तर्हि भवान् निष्पादयितुं शक्नोति mysql_reset_connection संयोजनसंसाधनानाम् पुनः आरम्भं कर्तुं। अस्याः प्रक्रियायाः पुनः संयोजनस्य अनुमतिसत्यापनस्य च आवश्यकता नास्ति, परन्तु यदा एतत् एव निर्मितम् आसीत् तदा एव स्थितिं प्रति संयोजनं पुनः स्थापयिष्यति ।

क्वेरी कैश

MySQL इत्यनेन क्वेरी-अनुरोधं प्राप्तस्य अनन्तरं प्रथमं क्वेरी-सञ्चयं गमिष्यति यत् एतत् स्टेट्मेण्ट् पूर्वं निष्पादितम् अस्ति वा इति । पूर्वं निष्पादितानि कथनानि तेषां परिणामानि च प्रत्यक्षतया स्मृतौ कील-मूल्ययुग्मरूपेण संग्रहीतुं शक्यन्ते । कुञ्जी प्रश्नकथनम्, मूल्यं च प्रश्नपरिणामम् । यदि भवतः प्रश्नः अस्मिन् संग्रहे प्रत्यक्षतया कुञ्जीम् अन्वेष्टुं शक्नोति, तर्हि मूल्यं प्रत्यक्षतया क्लायन्ट् प्रति प्रत्यागमिष्यति ।

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

परन्तु अधिकांशतः अहं करिष्यामिभवन्तः query caching इत्यस्य उपयोगं न कुर्वन्तु इति अनुशंसितम् ,किमर्थम्‌? यतः प्रश्नसञ्चयेन प्रायः लाभात् अधिकं हानिः भवति ।

प्रश्नसञ्चयः बहुवारं अमान्यः भवति यावत् सारणीयाः अद्यतनं भवति तावत् अस्मिन् सारणीयां सर्वे प्रश्नसञ्चयः स्वच्छाः भविष्यन्ति । अतः सम्भवति यत् भवान् परिणामान् रक्षितुं कष्टं गृहीतवान्, अपि च भवता तेषां उपयोगात् अपि पूर्वं, ते अद्यतनेन निर्मूलिताः अभवन् । भारी अपडेट् दबावयुक्तानां दत्तांशकोशानां कृते प्रश्नसञ्चयस्य हिट् रेट् अतीव न्यूनः भविष्यति । यावत् भवतः व्यवसाये स्थिरसारणी नास्ति यत् केवलं एकवारं दीर्घकालं यावत् अद्यतनं भविष्यति। यथा, यदि एतत् प्रणालीविन्याससारणी अस्ति, तर्हि अस्मिन् सारणीयां प्रश्नः प्रश्नसञ्चयस्य कृते उपयुक्तः अस्ति ।

सौभाग्येन MySQL इत्येतत् "use on demand" इति पद्धतिम् अपि प्रदाति । भवान् query_cache_type पैरामीटर् DEMAND इत्यत्र सेट् कर्तुं शक्नोति येन पूर्वनिर्धारित SQL कथनानां कृते क्वेरी कैशे इत्यस्य उपयोगः न भवति । येषां कथनानां कृते भवान् निश्चितः अस्ति यत् भवान् क्वेरी-सञ्चयस्य उपयोगं कर्तुम् इच्छति, तत् स्पष्टतया निर्दिष्टुं SQL_CACHE इत्यस्य उपयोगं कर्तुं शक्नोति, यथा निम्नलिखित-कथनम्:

select SQL_CACHE * from T where ID=10；
1

have to be aware of अस्ति, .MySQL 8.0 संस्करणं प्रत्यक्षतया सम्पूर्णं क्वेरी कैश फंक्शन् विलोपयति, यस्य अर्थः अस्ति यत् 8.0 तः आरभ्य एतत् कार्यं पुनः उपलब्धं न भविष्यति ।

विश्लेषक

यदि क्वेरी कैशे न हिट् भवति तर्हि स्टेट्मेण्ट् इत्यस्य वास्तविकं निष्पादनं आरभ्यते । प्रथमं MySQL इत्यनेन ज्ञातव्यं यत् भवान् किं कर्तुम् इच्छति, अतः तस्य SQL स्टेट्मेण्ट् पार्स् करणीयम् ।

अनुकूलकः

एक्ट्यूएटर

2. Logging system: SQL update statement कथं निष्पादितं भवति?

redo log

अहं न जानामि यत् भवन्तः अद्यापि "Kong Yiji" इति लेखं स्मर्यन्ते वा। यदि ऋणं दत्तवन्तः जनाः बहवः न सन्ति तर्हि सः ग्राहकस्य नाम खातं च फलकस्य उपरि लिखितुं शक्नोति। परन्तु यदि ऋणलेखायुक्ताः जनाः बहु सन्ति तर्हि सदैव एतादृशाः समयाः भविष्यन्ति यदा प्रशंसकमण्डलं तेषां निरीक्षणं कर्तुं न शक्नोति अस्मिन् समये दुकानदारस्य ऋणलेखानां अभिलेखनार्थं विशेषरूपेण एकं लेजरं भवितुमर्हति।

यदि कोऽपि ऋणं दातुम् इच्छति वा ऋणं दातुम् इच्छति तर्हि सामान्यतया दुकानदारस्य विकल्पद्वयं भवति ।

• एकः उपायः अस्ति यत् प्रत्यक्षतया लेजरं उद्घाट्य क्रेडिट् खातं योजयित्वा घटयितुं वा;
• अन्यः उपायः अस्तिप्रथमं अस्मिन् समये गुलाबीफलके लेखाः लिखन्तु, ततः समयस्य समाप्तेः अनन्तरं खातापुस्तकानि बहिः निष्कास्य गणनां कुर्वन्तु ।。

यदा व्यापारः प्रफुल्लितः भवति, काउण्टरः व्यस्तः भवति तदा दुकानदारः अवश्यमेव चयनं करिष्यतिउत्तरम् , यतः पूर्वक्रिया अतीव कष्टप्रदः अस्ति। प्रथमं भवद्भिः अस्य व्यक्तिस्य कुलऋणलेखस्य अभिलेखः अन्वेष्टव्यः । चिन्तयतु, तत्र दशकशः सघनरूपेण सङ्गृहीताः पृष्ठाः सन्ति, नाम अन्वेष्टुं दुकानदारस्य पठनचक्षुषः उपरि शनैः शनैः अन्वेषणं कर्तव्यं भवेत्, ततः परं सः गणनां कर्तुं एबाकसं बहिः आनयिष्यति, अन्ते च परिणामं पुनः लिखिष्यति लेजर इति ।

एषा समग्रप्रक्रिया चिन्तयितुं कष्टप्रदा अस्ति। तदपेक्षया प्रथमं गुलाबीफलके लिखितुं सुकरं भवति । चिन्तयतु, यदि दुकानदारस्य गुलाबीफलकस्य साहाय्यं नास्ति तर्हि प्रत्येकं लेखालेखनं कृत्वा लेजरं परिवर्तयितव्यं भवति किं कार्यक्षमता असह्यरूपेण न्यूना नास्ति?

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

गुलाबीफलकस्य लेजरस्य च सहकार्यस्य सम्पूर्णा प्रक्रिया वस्तुतः MySQL मध्ये प्रायः उल्लिखिता एव । WAL तन्त्रज्ञान,WAL पूर्णं नाम अस्तिWrite-Ahead Logging, मुख्यविषयः अस्तिप्रथमं लॉग् लिखन्तु, ततः डिस्क मध्ये लिखन्तु, अर्थात् प्रथमं गुलाबीफलकं लिखन्तु, ततः यदा भवन्तः व्यस्ताः न सन्ति तदा खातापुस्तकं लिखन्तु।

विशेषतः यदा अभिलेखस्य अद्यतनीकरणस्य आवश्यकता भवति तदा InnoDB इञ्जिन् प्रथमं अभिलेखं redo log (pink board) इत्यत्र लिखति तथा च स्मृतिः अद्यतनं करिष्यति । तस्मिन् एव काले InnoDB इञ्जिन् समुचितसमये संचालन-अभिलेखं डिस्क-मध्ये अद्यतनं करिष्यति, तथा च एतत् अद्यतनं प्रायः तदा क्रियते यदा प्रणाली तुल्यकालिकरूपेण निष्क्रियं भवति, यथा दुकानदारः बन्दीकरणानन्तरं करोति

यदि अद्यत्वे बहवः ऋणलेखाः न सन्ति तर्हि दुकानदारः वस्तुनां क्रमणं कर्तुं समापनसमयपर्यन्तं प्रतीक्षितुं शक्नोति । परन्तु यदि कस्मिन्चित् दिने ऋणलेखाः बहु सन्ति तथा च गुलाबीफलकं पूर्णं भवति तर्हि अस्माभिः किं कर्तव्यम्? अस्मिन् समये दुकानदारेन स्वकार्यं स्थापयित्वा गुलाबीफलके केचन क्रेडिट्-अभिलेखाः लेजर्-पत्रे अद्यतनं कर्तव्यम् आसीत्, ततः गुलाबी-फलकात् एतान् अभिलेखान् मेटयित्वा नूतनानां खातानां कृते स्थानं कल्पयितुम् अभवत्

तथैव InnoDB इत्यस्य redo log इत्यस्य नियतः आकारः अस्ति उदाहरणार्थं, एतत् 4 सञ्चिकानां समुच्चयरूपेण विन्यस्तुं शक्यते, प्रत्येकं सञ्चिकायाः ​​आकारः 1GB भवति ततः एषा "pink board" कुलम् 4GB कार्याणि अभिलेखयितुं शक्नोति । आरम्भादेव लेखनं आरभत, ततः लूप् मध्ये लेखनार्थं आरम्भं प्रति आगच्छन्तु, यथा अधोलिखिते चित्रे दर्शितम् अस्ति ।

write pos इत्येतत् वर्तमानस्य अभिलेखस्य स्थितिः अस्ति । चेकपॉइण्ट् वर्तमानं मेटनीयं स्थानम् अस्ति, अपि च अग्रे गच्छति, लूप् अपि करोति, अभिलेखं मेटयितुं पूर्वं, अभिलेखं दत्तांशसञ्चिकायां अद्यतनं कर्तव्यम् ।

write pos तथा checkpoint इत्येतयोः मध्ये यः स्थानं भवति सः "pink board" इत्यस्य रिक्तः भागः अस्ति यस्य उपयोगेन नूतनानां कार्याणां अभिलेखनं कर्तुं शक्यते । यदि write pos चेकपोस्ट् गृह्णाति तर्हि तस्य अर्थः अस्ति यत् "pink board" पूर्णः अस्ति, तथा च अस्मिन् समये कोऽपि नूतनः अपडेट् कर्तुं न शक्यते भवद्भिः प्रथमं चेकपोस्ट् अग्रे सारयितुं केचन अभिलेखाः स्थगितव्याः, मेटयितव्याः च

redo log इत्यनेन InnoDB इत्यनेन सुनिश्चितं कर्तुं शक्यते यत् यदि दत्तांशकोशः असामान्यरूपेण पुनः आरभते तथापि पूर्वं प्रदत्ताः अभिलेखाः न नष्टाः भविष्यन्तिcrash-safe。

दुर्घटना-सुरक्षितस्य अवधारणां अवगन्तुं अस्माकं पूर्वस्य क्रेडिट्-अभिलेखस्य उदाहरणं चिन्तयन्तु । यावत् यावत् ऋण-अभिलेखः गुलाबी-फलके अथवा लेजर-पत्रे लिखितः भवति, यद्यपि पश्चात् दुकानदारः तत् विस्मरति, यथा सहसा कतिपयान् दिनानि यावत् व्यापारं स्थगयति, तथापि सः लेजर-मध्ये विद्यमानस्य दत्तांशस्य माध्यमेन ऋण-लेखं स्पष्टीकर्तुं शक्नोति तथा च पुनः व्यापारं प्रारभ्य गुलाबी फलकम्।

binlog

यथा वयं पूर्वं उक्तवन्तः, समग्ररूपेण MySQL इत्यस्य वस्तुतः द्वौ भागौ स्तः: एकः सर्वर-स्तरः, यः मुख्यतया MySQL इत्यस्य कार्यात्मक-स्तरस्य कार्याणि करोति, अन्यः इञ्जिन-स्तरः, यः भण्डारण-सम्बद्धानां विशिष्टानां विषयाणां उत्तरदायी भवतिउपरि वयं यस्य गुलाबीफलकस्य विषये चर्चां कृतवन्तःredo log इति InnoDB इञ्जिनस्य अद्वितीयः लॉग् अस्ति,तथा Server स्तरस्य स्वकीयः log अपि अस्ति, यत् binlog (archive log) इति कथ्यते ।。

अहं मन्ये भवन्तः पृच्छन्ति, किमर्थं द्वौ लकौ स्तः ?

यतः आरम्भे MySQL मध्ये InnoDB इञ्जिन् नासीत् । MySQL इत्यस्य स्वकीयं इञ्जिनं MyISAM अस्ति, परन्तु MyISAM इत्यस्य दुर्घटना-सुरक्षितक्षमता नास्ति, तथा च binlog logs केवलं संग्रहणार्थं उपयोक्तुं शक्यते । InnoDB इत्यस्य परिचयः MySQL इत्यत्र अन्येन कम्पनीना प्लग-इन्-रूपेण कृतः यतः केवलं binlog इत्यस्य उपरि अवलम्ब्य क्रैश-सुरक्षितक्षमता नास्ति, अतः InnoDB अन्यस्य लॉग्-प्रणाल्याः अर्थात् redo log इत्यस्य उपयोगं करोति, क्रैश-सुरक्षित-क्षमताम् प्राप्तुं

एतयोः लॉगयोः निम्नलिखित त्रयः भेदाः सन्ति ।

1. redo log InnoDB इञ्जिन् कृते अद्वितीयं भवति binlog MySQL इत्यस्य सर्वर लेयर द्वारा कार्यान्वितं भवति तथा च सर्वैः इञ्जिनैः उपयोक्तुं शक्यते ।
2. redo log इति भौतिकं लॉग् अस्ति, "कस्मिन्चित् दत्तांशपृष्ठे किं किं परिवर्तनं कृतम्" इति अभिलेखयति;binlog इति तार्किकं लॉग् अस्ति, यत् अभिलेखितं तत् अस्य कथनस्य मूलतर्कः अस्ति, यथा "ID=2 इत्यनेन सह पङ्क्तिस्य c क्षेत्रे 1 योजयतु" ।
3. redo log इति लूप् मध्ये लिखितम् अस्ति, अन्तरिक्षं समाप्तं भविष्यति;binlog अतिरिक्तरूपेण लिखितुं शक्यते . "लेखनं योजयतु" इत्यस्य अर्थः अस्ति यत् binlog सञ्चिकायाः ​​निश्चितं आकारं प्राप्तस्य अनन्तरं सा अग्रिमे परिवर्तनं करिष्यति, पूर्ववृत्तं न अधिलेखयिष्यति ।

एतयोः लॉगयोः अवधारणात्मकं अवगमनेन सह, एतत् सरलं अपडेट् स्टेट्मेण्ट् निष्पादयन्ते सति एक्जीक्यूटिव् इत्यस्य InnoDB इञ्जिन् इत्यस्य च आन्तरिकप्रक्रियाः पश्यामः ।

1. निष्पादकः प्रथमं ID=2 इति रेखां प्राप्तुं इञ्जिनं अन्वेषयति । ID प्राथमिकं कुञ्जी अस्ति, इञ्जिनं च प्रत्यक्षतया वृक्षसन्धानस्य उपयोगं करोति एतां पङ्क्तिं अन्वेष्टुं । यदि ID=2 युक्ता पङ्क्तिः यत्र स्थिता अस्ति तत् दत्तांशपृष्ठं पूर्वमेव स्मृतौ अस्ति तर्हि तत् प्रत्यक्षतया निष्पादकं प्रति प्रत्यागमिष्यति अन्यथा प्रथमं डिस्कतः स्मृतौ पठितव्यं ततः प्रत्यागन्तुम्;
2. निष्पादकः इञ्जिनेन दत्तं पङ्क्तिदत्तांशं प्राप्नोति, अस्मिन् मूल्ये 1 योजयति, उदाहरणार्थं, पूर्वं N आसीत्, परन्तु अधुना N+1 अस्ति, दत्तांशस्य नूतनां पङ्क्तिं प्राप्नोति, ततः एतत् लिखितुं इञ्जिन-अन्तरफलकं आह्वयति दत्तांशस्य नूतना पङ्क्तिः।
3. इञ्जिनम् एतां नूतनां दत्तांशपङ्क्तिं स्मृतौ अद्यतनं करोति तथा च अद्यतनकार्यं redo log मध्ये अभिलेखयति redo log इत्यस्मिन्‌सज्जी करोतु राज्यम्‌। ततः निष्पादकं सूचयन्तु यत् निष्पादनं सम्पन्नम् अस्ति तथा च व्यवहारः कदापि प्रस्तुतुं शक्यते।
4. निष्पादकः अस्य ऑपरेशनस्य binlog जनयति, स्थापयति च binlog डिस्कं प्रति लिखितम्。
5. निष्पादकः इञ्जिनस्य commit transaction interface आह्वयति, इञ्जिन् च... redo log प्रस्तुतं कर्तुं परिवर्तनं (प्रविश्) स्थितिः, अद्यतनं सम्पन्नम् अस्ति ।

अत्र अहम् अस्य update statement इत्यस्य execution flow chart ददामि चित्रे प्रकाशपेटिका InnoDB इत्यस्य अन्तः निष्पादितम् इति सूचयति, तथा च dark box इत्यनेन executor मध्ये निष्पादितम् इति सूचयति ।

update कथन निष्पादन प्रक्रिया

भवान् अवलोकितवान् स्यात् यत् अन्तिमत्रयपदार्थाः किञ्चित् "वृत्ताकाराः" दृश्यन्ते redo log इत्यस्य लेखनं द्वयोः चरणयोः विभक्तम् अस्ति: prepare and commit इति

द्विचरणीयप्रतिबद्धता

किमर्थं आवश्यकं "द्विचरणीयं निवेदनम्" ?एतेन द्वयोः लॉगयोः भेदः अनुमन्यतेतार्किकरूपेण सुसंगतः . एतस्याः समस्यायाः व्याख्यानार्थं लेखस्य आरम्भे यः प्रश्नः अस्ति तस्मात् आरम्भः करणीयः यत् अर्धमासस्य अन्तः दत्तांशकोशं कस्यापि सेकण्डस्य अवस्थायां कथं पुनः स्थापयितव्यम्?

यथा वयं पूर्वं उक्तवन्तः, binlog सर्वाणि तार्किकक्रियाणि अभिलेखयिष्यति, "लेखनं योजयतु" इति रूपं च स्वीकुर्यात् । यदि भवतः DBA प्रतिज्ञायते यत् अर्धमासस्य अन्तः पुनः स्थापयितुं शक्यते, तर्हि बैकअप-प्रणाली निश्चितरूपेण गत-अर्ध-मासे सर्वाणि binlogs रक्षिष्यति, तथा च प्रणाली सम्पूर्णस्य दत्तांशकोशस्य नियमित-बैकअपं करिष्यति अत्र "नियमितः" व्यवस्थायाः महत्त्वे निर्भरं भवति, यत् दिवसे एकवारं सप्ताहे एकवारं वा भवितुम् अर्हति ।

यदा भवद्भिः निर्दिष्टसेकेण्ड् मध्ये पुनःस्थापनीयं भवति, उदाहरणार्थं, एकस्मिन् दिने अपराह्णे द्वौ वादने, तदा भवन्तः पश्यन्ति यत् मध्याह्ने अकस्मात् सारणी विलोपिता अभवत्, तथा च भवन्तः दत्तांशं पुनः प्राप्तुं प्रवृत्ताः सन्ति, तदा भवन्तः एतत् कर्तुं शक्नुवन्ति:

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

ठीकम्, दत्तांशपुनर्प्राप्तिप्रक्रियायाः विषये चर्चां कृत्वा पुनः आगत्य वृत्तान्तस्य "द्विचरणप्रतिबद्धतायाः" आवश्यकता किमर्थम् इति चर्चां कुर्मः । अत्र वयं व्याख्यानार्थं विरोधाद् प्रमाणं अपि प्रयोक्तुं शक्नुमः।

यतः redo log तथा binlog द्वौ स्वतन्त्रौ तर्कौ स्तः, यदि द्विचरणीय-प्रतिबद्धता न उपयुज्यते तर्हि redo log प्रथमं लिखितव्यं ततः binlog लिखितव्यं, अथवा विपरीतक्रमः स्वीक्रियताम् एतयोः विधियोः काः समस्याः सन्ति इति पश्यामः ।

अद्यापि पूर्वस्य अपडेट् स्टेट्मेण्ट् उदाहरणरूपेण उपयुज्यताम् । ID=2 इत्यनेन सह वर्तमानपङ्क्तौ c क्षेत्रस्य मूल्यं 0 इति कल्पयतु, अपि च कल्पयतु यत् अद्यतनकथनस्य निष्पादनकाले प्रथमस्य लॉगस्य लेखनस्य अनन्तरं परन्तु द्वितीयस्य लॉगस्य लेखनात् पूर्वं किं भविष्यति?

• प्रथमं redo log इति लिखन्तु ततः binlog इति लिखन्तु ।
  मानातु यत् MySQL प्रक्रिया असामान्यरूपेण पुनः आरभ्यते यदा redo log लिख्यते परन्तु binlog लिखितुं पूर्वं । यथा वयं पूर्वं उक्तवन्तः, redo log लिखितस्य अनन्तरं, यदि सिस्टम् क्रैश भवति चेदपि, दत्तांशः पुनः प्राप्तुं शक्यते, अतः पुनर्प्राप्तेः अनन्तरं अस्मिन् पङ्क्तौ c इत्यस्य मूल्यं 1 भवति । परन्तु यतः binlog समाप्तेः पूर्वं दुर्घटना अभवत्, अतः एतत् कथनं अस्मिन् समये binlog मध्ये न अभिलेखितम् । अतः यदा पश्चात् लॉग् इत्यस्य बैकअप क्रियते तदा एतत् कथनं रक्षिते binlog मध्ये न समाविष्टं भविष्यति । ततः भवन्तः पश्यन्ति यत् यदि भवन्तः अस्थायी पुस्तकालयस्य पुनर्स्थापनार्थं एतत् binlog उपयोक्तुं प्रवृत्ताः सन्ति, यतः अस्य कथनस्य binlog नष्टं भवति, अस्थायी पुस्तकालयः अस्मिन् समये अद्यतनं न भविष्यति, पुनर्स्थापिते पङ्क्तौ c इत्यस्य मूल्यं 0 अस्ति, यत् अस्ति मूलपुस्तकालयस्य मूल्यं यथा भिन्नम्।
• प्रथमं binlog लिखन्तु ततः log redo कुर्वन्तु ।
  यदि binlog लिखितस्य अनन्तरं क्रैश भवति, यतः redo log अद्यापि न लिखितम्, तर्हि क्रैश पुनर्प्राप्तेः अनन्तरं व्यवहारः अमान्यः भविष्यति, अतः अस्मिन् पङ्क्तौ c इत्यस्य मूल्यं 0 अस्ति परन्तु "Change c from 0 to 1" इति लॉग् binlog मध्ये अभिलेखितः अस्ति । अतः यदा पश्चात् पुनर्स्थापनार्थं binlog इत्यस्य उपयोगः भवति तदा पुनर्स्थापिते पङ्क्तौ c इत्यस्य मूल्यं 1 भवति, यत् मूलदत्तांशकोशे मूल्यात् भिन्नम् अस्ति ।
  द्रष्टुं शक्यते यत् यदि "two-phase commit" इत्यस्य उपयोगः न भवति तर्हि दत्तांशकोशस्य स्थितिः तस्य लॉग् इत्यस्य उपयोगेन पुनर्स्थापितस्य पुस्तकालयस्य स्थितिः असङ्गता भवितुम् अर्हति ।

भवान् वदिष्यति, किम् एषा संभावना अतीव न्यूना?

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

सरलतया वक्तुं शक्यते यत्, redo log तथा binlog इत्येतयोः उपयोगः व्यवहारस्य commit स्थितिं प्रतिनिधितुं शक्यते, andद्विचरणीयं निवेदनं राज्यद्वयं तार्किकरूपेण सुसंगतं स्थापयितुं भवति।。