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

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

MySQL लॉग्स् इत्यस्य सामग्री अतीव महत्त्वपूर्णा अस्ति तथा च प्रायः साक्षात्कारस्य समये पृष्टा भवति। तत्सह, log-सम्बद्धं ज्ञानं निपुणतां प्राप्तुं MySQL इत्यस्य अन्तर्निहितसिद्धान्तान् अवगन्तुं अपि साहाय्यं करिष्यति तथा च आवश्यकतायां समस्यानां निवारणं समाधानं च कर्तुं साहाय्यं करिष्यति
MySQL मध्ये सामान्यलॉगप्रकारेषु मुख्यतया निम्नलिखितवर्गाः (InnoDB भण्डारणइञ्जिनस्य कृते) अन्तर्भवन्ति:

• Error log (error log): MySQL इत्यस्य स्टार्टअप, रनिंग, शटडाउन प्रक्रियाः अभिलेखयति ।
• द्विचक्रीय लॉग् (binarylog, binlog): मुख्यतया SQL कथनानि अभिलेखयति ये आँकडाधारदत्तांशं परिवर्तयन्ति ।
• सामान्यप्रश्नवृत्तान्तः : सर्वे SQL अभिलेखाः MySQL सर्वरं प्रति प्रेषिताः क्लायन्ट् इत्यनेन यः संयोजनं स्थापितवान् यतः SQL इत्यस्य राशिः तुल्यकालिकरूपेण बृहत् अस्ति, अतः पूर्वनिर्धारितरूपेण सक्षमः नास्ति तथा च अनुशंसितः नास्ति ।
• मन्द क्वेरी लॉग् (sow querylog): क्वेरी निष्पादनसमयः long_query_time सेकण्ड् अतिक्रमति, SQL मन्द क्वेरी समस्यानां समाधानं कुर्वन् उपयुज्यते ।
• लेनदेन-वृत्तलेखः (redo log and undo log): redo log एकः redo log अस्ति, undo log च एकः rollback log अस्ति ।
• रिले लॉग् : रिले लॉग् प्रतिकृतिप्रक्रियायाः समये उत्पन्नः लॉग् अस्ति । तथापि, relay log master-slave replication इत्यस्मिन् slave database इत्यस्य उद्देश्यं भवति ।
• DDL log (metadatalog): DDL कथनैः क्रियमाणाः मेटाडाटाक्रियाः

द्विचक्रीय-लॉग् (binlog) तथा लेनदेन-लॉग् (redo log and undo log) अधिकं महत्त्वपूर्णाः सन्ति, अस्माकं ध्यानस्य आवश्यकता वर्तते ।

1. मन्दं प्रश्नवृत्तम्

मन्दप्रश्नवृत्तान्तः सर्वान् प्रश्नकथनानि अभिलेखयति येषां निष्पादनसमयः long_query_time (पूर्वनिर्धारितं 10s, सामान्यतया 1s इति सेट् भवति) प्रायः SQL मन्दप्रश्नसमयः (SQL निष्पादनसमयः अतीव दीर्घः) समस्यायाः समाधानं कुर्वन् उपयुज्यते
मन्द SQL अन्वेषणं SQL कथनानां कार्यक्षमतां अनुकूलितुं प्रथमं सोपानम् अस्ति ततः मन्द SQL विश्लेषणं कर्तुं निष्पादनयोजनायाः विषये सूचनां प्राप्तुं च EXPLAIN आदेशस्य उपयोगं कुर्वन्तु ।
मन्दप्रश्नवृत्तान्तः पूर्वनिर्धारितरूपेण निष्क्रियः अस्ति वा इति परीक्षितुं "slow_query_log" इत्यादीनां show चरानाम् उपयोगं कर्तुं शक्नुवन्ति ।

SET GLOBAL slow_query_log=ON इत्यनेन चालू कर्तुं शक्यते

long_query_time पैरामीटर् परिभाषयति यत् मन्दप्रश्नरूपेण परिभाषितुं पूर्वं कियत्कालं भवति ।

इदं परिवर्तयितुं अपि शक्यते: set global long_query_time = 12

वास्तविकपरियोजनासु मन्दप्रश्नवृत्तान्तः तुल्यकालिकरूपेण विशालः भवितुम् अर्हति तथा च तस्य प्रत्यक्षविश्लेषणं असुविधाजनकं भवति वयं आधिकारिकं MySQL मन्दप्रश्नविश्लेषणं ट्यूनिङ्गसाधनं च उपयोक्तुं शक्नुमः । mysqldumpslow इति इति . मम ब्लॉगः अपि केवलं mysqldumpslow साधनेन सह सम्बद्धः अस्ति:

[MySQL] mysqldumpslow साधन--मन्दप्रश्नलॉगसञ्चिकानां सारांशः-CSDN ब्लॉगः

1.1 वर्तमानस्य मन्दप्रश्नवक्तव्यस्य संख्यां कथं पृच्छितव्यम्?

MySQL मध्ये एकः चरः अस्ति यः वर्तमानं मन्दप्रश्नवाक्यानां संख्यां अभिलेखयति भवान् show global status इत्यस्य उपयोगं कर्तुं शक्नोति यथा'%slo
w_queries%' द्रष्टुं आदेशः।

१.२ मन्दप्रश्नानां अनुकूलनं कथं करणीयम्

MySQL अस्मान् प्रदातिव्याख्यातिनिष्पादनयोजनायाः विषये सूचनां प्राप्तुं आदेशः।
निष्पादनयोजना MySQL क्वेरी अनुकूलकेन अनुकूलितस्य अनन्तरं SQL कथनस्य विशिष्टं निष्पादनविधिं निर्दिशति । प्रायः SQL प्रदर्शनविश्लेषणं अनुकूलनं च इत्यादिषु परिदृश्येषु निष्पादनयोजनानां उपयोगः भवति । EXPLAIN इत्यस्य परिणामानां माध्यमेन भवान् दत्तांशसारणीयाः प्रश्नक्रमः, दत्तांशप्रश्नक्रियायाः संचालनप्रकारः, के अनुक्रमणिकाः मारयितुं शक्यन्ते, के अनुक्रमणिकाः वास्तवतः मारिताः भविष्यन्ति, प्रत्येकस्मिन् दत्तांशे कति पङ्क्तयः अभिलेखाः इत्यादीनि सूचनां ज्ञातुं शक्नुवन्ति table इति पृष्टं भवति, अन्याः च सूचनाः। विशेषतः, वयं अधोलिखितानां केषाञ्चन सामान्यविधिनाम् माध्यमेन SQL अनुकूलितुं शक्नुमः:

1. SELECT * इत्यस्य उपयोगं परिहरन्तु ।
SELECT * अधिकं CPU उपभोगं करोति ।
SELECT *निष्प्रयोजनक्षेत्राणि संजालबैण्डविड्थसंसाधनस्य उपभोगं तथा च आँकडासंचरणसमयं वर्धयन्ति, विशेषतः बृहत्क्षेत्राणि (यथा varchar,
blob、text)。
SELECT * अनुक्रमणिका अनुकूलनं कवरं कर्तुं MySQL अनुकूलकस्य उपयोगं कर्तुं न शक्नोति (MySQL अनुकूलकस्य आधारेण "कवरिंग अनुक्रमणिका" रणनीतिः अत्यन्तं द्रुतगतिः कुशलश्च अस्ति, तथा च उद्योगे अत्यन्तं अनुशंसिता प्रश्नानुकूलनविधिः अस्ति)
SELECT <field list> इत्यनेन सारणीसंरचनापरिवर्तनस्य प्रभावः न्यूनीकर्तुं शक्यते ।

2. पृष्ठांकन अनुकूलन

साधारणं पेजिंग् तुल्यकालिकरूपेण अल्पं समयं लभते यदा दत्तांशस्य परिमाणं अल्पं भवति ।

यदि दत्तांशस्य परिमाणं बृहत् भवति, कोटिकोटिः वा दशकोटिः अपि भवति तर्हि साधारणं पेजिंग् अतीव दीर्घकालं यावत् भवति ।

कथं अनुकूलनं कर्तव्यम्?उपर्युक्तं SQL कथनं उपप्रश्नरूपेण परिवर्तयितुं शक्नुवन्ति ।

वयं प्रथमं सीमायाः प्रथममापदण्डस्य अनुरूपं प्राथमिककुंजीमूल्यं पृच्छामः, ततः अस्य प्राथमिककुंजीमूल्यस्य आधारेण फ़िल्टरं सीमां च कुर्मः, येन कार्यक्षमता द्रुततरं भविष्यति परन्तु एषा पद्धतिः केवलं तदा एव कार्यं करोति यदा ids सकारात्मकक्रमे सन्ति ।

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

3. न्यूनानि संयोजनानि कुर्वन्तु

अलीबाबा विकास पुस्तिका: १.

भवन्तः झीहु इत्यत्र चर्चां पठितुं शक्नुवन्ति:

https://www.zhihu.com/प्रश्न/68258877https://www.zhihu.com/प्रश्न/682588774. विदेशीयकीलानां, झरनाणां च उपयोगः न कर्तव्यः इति अनुशंसितम्

अलीबाबा जावा विकास पुस्तिका: १.

5. समुचितं क्षेत्रप्रकारं चिनोतु

6. UNION इत्यस्य स्थाने UNION ALL इत्यस्य उपयोगं कर्तुं प्रयतध्वम्

UNION द्वयोः परिणामसमूहयोः सर्वान् आँकडान् अस्थायीसारणीयां स्थापयति ततः deduplication ऑपरेशनं करिष्यति, यत् अधिकं समयग्राहकं भवति, अधिकं CPU संसाधनं च उपभोगयति
UNION ALL परिणामसमूहस्य द्वितीयकं न करिष्यति, तथा च प्राप्तेषु दत्तांशेषु द्वितीयकवस्तूनि सन्ति ।
परन्तु यदि वास्तविकव्यापारपरिदृश्ये द्वितीयकदत्तांशस्य अनुमतिः नास्ति तर्हि UNION इत्यस्य उपयोगः अद्यापि कर्तुं शक्यते ।

7. बैच-सञ्चालनम्

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

8. अनुक्रमणिकानां सम्यक् उपयोगं कुर्वन्तु

अस्मिन् खण्डे बहु सामग्री अस्ति, यस्य परिचयः पश्चात् पृथक् ब्लोग् मध्ये भविष्यति ।

2. binlog द्विचक्रीय लॉग

binlog (बाइनरी लॉग् एकः द्विचक्रीय लॉग् सञ्चिका अस्ति) मुख्यतया सर्वाणि कार्याणि अभिलेखयति ये MSQL आँकडाधारे परिवर्तितानि सन्ति (दत्तांशकोशेन निष्पादितानि सर्वाणि DDL तथा DML कथनानि), सारणीसंरचनापरिवर्तनानि (CREATE, ALTER, DROP TABLE.), सारणीदत्तांशं च सन्ति modifications ( INSERT.UPDATE, DELETE..), परन्तु SELECT, SHOW इत्यादीनि क्रियाणि न समाविष्टानि ये दत्तांशकोशे परिवर्तनं न जनयन्ति ।

सर्वेषां द्विचक्रीयवृत्तानां सूचीं द्रष्टुं भवान् show binary logs इति आदेशस्य उपयोगं कर्तुं शक्नोति:

२.१ बिन्लॉग् प्रारूपम्

द्विचक्रीय-अभिलेखन-विधयः ३ प्रकाराः सन्ति : १.

• कथनविधिः: प्रत्येकं SQL कथनं यत् आँकडानां परिवर्तनं करोति, तत् binlog मध्ये अभिलेखितं भविष्यति, यथा सम्मिलितं, अद्यतनं, विलोपनं च।·
• पङ्क्तिविधिः (अनुशंसितः): प्रत्येकस्य पङ्क्तिस्य विशिष्टानि परिवर्तनघटनानि binlog मध्ये अभिलेखितानि भविष्यन्ति । · २.
• मिश्रितविधिः : Statement मोड् तथा Row मोड् इत्येतयोः मिश्रणम् । कथनविधिः पूर्वनिर्धारितरूपेण उपयुज्यते, तथा च कतिपयेषु विशेषपरिदृश्येषु स्वयमेव Row मोड् प्रति गच्छति ।

Row मोड् इत्यनेन सह तुलने स्टेट्मेण्ट् मोड् इत्यस्मिन् log सञ्चिका लघुतरं भवति, डिस्क IO दबावः अपि लघुः भवति, कार्यक्षमता च श्रेष्ठा भवति । तथापि तस्य सटीकता Row mode इत्यस्मात् दुर्बलतरम् अस्ति ।

MySQL 5.1.5 इत्यस्मात् पूर्वं binlog इत्यस्य प्रारूपं केवलं STATEMENT आसीत् 5.1.5 इत्यनेन ROW प्रारूपेण binlog इत्यस्य समर्थनं कर्तुं आरब्धम् । MySQL 5.7.7 इत्यस्मात् पूर्वं पूर्वनिर्धारितरूपेण Statement mode इत्यस्य उपयोगः भवति स्म । MySQL5.7.7 पूर्वनिर्धारितरूपेण Row mode इत्यस्य उपयोगं करोति ।

binlog द्वारा प्रयुक्तं प्रारूपं द्रष्टुं '%binlog format%' इत्यादीनां show चरानाम् उपयोगं कर्तुं शक्नुवन्ति;

२.२ बिन्लोग् इत्यस्य भूमिका

binlog इत्यस्य मुख्यं अनुप्रयोगपरिदृश्यं master-slave प्रतिकृतिः अस्ति Master-slave, master-master, master-slave च सर्वे binlog इत्यस्मात् अविभाज्यः सन्ति, येन दत्तांशस्य समन्वयः भवति तथा च दत्तांशस्य स्थिरता सुनिश्चिता भवति ।

स्वामी-दास-प्रतिकृतिस्य सिद्धान्तः अधोलिखिते चित्रे दर्शितः अस्ति ।

1. मुख्यपुस्तकालयः दत्तांशकोशे दत्तांशपरिवर्तनं binlog इत्यत्र लिखति
2. दासपुस्तकालयं मुख्यपुस्तकालयेन सह संयोजयन्तु
3. दासपुस्तकालयः मुख्यपुस्तकालयात् अद्यतनं binlog अनुरोधयितुं I0 थ्रेड् निर्मास्यति ।
4. मुख्यपुस्तकालयः binlog प्रेषयितुं binlog dump thread निर्मास्यति, तथा च slave library मध्ये I/0 thread प्राप्तुं उत्तरदायी भवति 5. slave library इत्यस्य I/0 thread प्राप्तं binlog रिले मध्ये लिखिष्यति वृत्त।
6. पुस्तकालयस्य SQL थ्रेड् तः रिले लॉग् पठन्तु तथा च स्थानीयरूपेण आँकडानां समन्वयनं कुर्वन्तु (अर्थात् पुनः SQL निष्पादयन्तु)

२.३ बिन्लॉग् फ्लशिंग् इत्यस्य समयं कथं चिन्वितव्यम् ?

InnoDB भण्डारणइञ्जिनस्य कृते, व्यवहारस्य निष्पादनस्य समये, लॉग् प्रथमं binlogcache मध्ये लिखितं भविष्यति यदा व्यवहारः प्रस्तूयते तदा एव binlogcache मध्ये लॉग् डिस्क मध्ये binlog सञ्चिकायां स्थास्यति स्मृतौ लेखनं द्रुततरं भवति, एतत् अपि कार्यक्षमतायाः कारणात् क्रियते ।

यतः व्यवहारस्य binlog विभक्तुं न शक्यते, व्यवहारः कियत् अपि विशालः भवतु, एकवारं लिखितव्यः, अतः प्रणाली प्रत्येकं सूत्राय binlog cache इत्यस्य रूपेण स्मृतिखण्डं आवंटयिष्यति वयं binlog_cache_size पैरामीटर् इत्यस्य माध्यमेन एकस्य थ्रेड् इत्यस्य binlogcache आकारं नियन्त्रयितुं शक्नुमः यदि भण्डारणसामग्री एतत् पैरामीटर् अतिक्रमति तर्हि अस्थायीरूपेण डिस्क (swap) इत्यत्र संगृहीतं भवितुमर्हति ।

अतः binlog कदा डिस्कं प्रति फ्लश भवति?
·0: अनिवार्य आवश्यकता नास्ति, प्रणाली कदा डिस्क मध्ये लिखितव्यम् इति निर्णयं करिष्यति।
·1: प्रत्येकं व्यवहारः प्रस्तूयते तदा binlog डिस्कमध्ये लिखितव्यम्:
·N: प्रत्येकं N लेनदेनं डिस्कं प्रति Binlog लिखितं भविष्यति।हानिः जोखिमः

MySQL5.7 इत्यस्मात् पूर्वं sync_binlog इत्यस्य पूर्वनिर्धारितं मूल्यं 0 आसीत् । MySQL5.7 इत्यस्य अनन्तरं sync_binlog इत्यस्य पूर्वनिर्धारितं मूल्यं 1. सामान्यतया, sync_binlog इत्यस्य मूल्यं 0 इति सेट् कर्तुं न अनुशंसितम् । यदि कार्यप्रदर्शनस्य आवश्यकताः तुल्यकालिकरूपेण अधिकाः सन्ति अथवा डिस्क IO अटङ्कः भवति तर्हि sync_binlog इत्यस्य मूल्यं समुचितरूपेण वर्धयितुं शक्यते तथापि एतेन दत्तांशहानिः वर्धते ।

२.४ केषु परिस्थितिषु binlog पुनः उत्पन्नं भविष्यति ?

निम्नलिखितत्रयस्थितीनां सम्मुखीभवने MySQL नूतनं लॉग् सञ्चिकां पुनः जनयिष्यति, सञ्चिकाक्रमाङ्कः च वर्धितः भविष्यति ।

• MySQL सर्वरः स्थगयति अथवा पुनः आरभते
• flush logs आदेशस्य उपयोगानन्तरं
• binlog सञ्चिकायाः ​​आकारः max binlog size चरस्य सीमां अतिक्रम्य ।

3. redo log redo log

वयं जानीमः यत् InnoD8 भण्डारणइञ्जिनं पृष्ठानां एककेषु भण्डारणस्थानं प्रबन्धयति । डिस्क IO ओवरहेड् न्यूनीकर्तुं Buffer Pool इति क्षेत्रम् अपि अस्ति, यत् स्मृतौ विद्यते । यदा अस्माकं दत्तांशसम्बद्धं पृष्ठं Buffer Pool मध्ये नास्ति तदा MSQL प्रथमं डिस्क मध्ये पृष्ठं Buffer Pool मध्ये कैश करिष्यति, येन पश्चात् वयं प्रत्यक्षतया Buffer Pool मध्ये पृष्ठं संचालितं कुर्मः, येन पठन-लेखन-प्रदर्शने महती उन्नतिः भवति .

व्यवहारस्य प्रतिबद्धतायाः अनन्तरं, Buffer Pool मध्ये तत्सम्बद्धपृष्ठे अस्माकं परिवर्तनं डिस्कं प्रति न स्थास्यति । अस्मिन् समये यदि MySQL सहसा दुर्घटना भवति तर्हि अस्मिन् व्यवहारे परिवर्तनं प्रत्यक्षतया अन्तर्धानं भविष्यति वा?
स्पष्टतया न, यदि एवम् अस्ति तर्हि स्पष्टतया व्यवहारस्य स्थायित्वस्य उल्लङ्घनं करिष्यति।

MySQLInnoDB इञ्जिन् लेनदेनस्य स्थायित्वं सुनिश्चित्य redo log इत्यस्य उपयोगं करोति । मुख्यं कार्यं redo log करोति पृष्ठसंशोधनं अभिलेखयति, यथा कस्मिन्चित् पृष्ठे एकस्मिन् निश्चिते आफ्सेट् मध्ये कियन्तः बाइट् परिवर्तिताः सन्ति तथा च विशिष्टा परिवर्तिता सामग्री का अस्ति इति । redo log इत्यस्मिन् प्रत्येकं अभिलेखे सारणीस्थानसङ्ख्या, दत्तांशपृष्ठसङ्ख्या, आफ्सेट्, विशिष्टः परिवर्तितः दत्तांशः च भवति, तथा च परिवर्तितदत्तांशस्य दीर्घतां अपि अभिलेखयितुं शक्नोति (पुनः कर्तुं लॉगप्रकारस्य आधारेण)
यदा व्यवहारः प्रतिबद्धः भवति तदा वयं फ्लशिंग् रणनीत्यानुसारं redo log इत्येतत् डिस्कं प्रति फ्लश करिष्यामः एवं प्रकारेण MySQL क्रैश भवति चेदपि पुनः आरभ्य डिस्क मध्ये लिखितुं असफलं दत्तांशं पुनः प्राप्तुं शक्यते, तस्मात् स्थायित्वं सुनिश्चितं भवति व्यवहारस्य । अन्येषु शब्देषु, redo log MySQL crash recovery क्षमताम् अयच्छति ।

1. दत्तांशस्य स्थायित्वं सुनिश्चितं कुर्वन्तु (Durability) .

Redo Log सर्वाणि परिवर्तनक्रियाः दत्तांशकोशे अभिलेखयति । यदा आँकडाधारः लेखनक्रियाः (INSERT, UPDATE, DELETE) करोति तदा एतानि क्रियाणि प्रथमं Redo Log मध्ये अभिलेखितानि भविष्यन्ति ततः दत्तांशसञ्चिकायां प्रयुक्तानि भविष्यन्ति । एवं प्रकारेण, यदि दत्तांशसंशोधनक्रियायाः पूर्णतया डिस्कमध्ये लिखितुं पूर्वं प्रणाली विफलं भवति चेदपि, Redo Log इत्यनेन दत्तांशः नष्टः न भवति इति सुनिश्चितं कर्तुं शक्नोति । पुनर्प्राप्तेः समये, दत्तांशकोशः दत्तांशस्य स्थिरतां सुनिश्चित्य Redo Log तः एतानि असमाप्तसंशोधनक्रियाणि पुनः करिष्यति ।

2. आँकडा पुनर्प्राप्तिः (Recovery) २.

Redo Log इत्यनेन प्रणालीदुर्घटनायाः अथवा अप्रत्याशितविद्युत्विच्छेदस्य अनन्तरं दत्तांशकोशं सुसंगतस्थितौ पुनः प्राप्तुं साहाय्यं करोति । पुनर्प्राप्तिप्रक्रियायाः समये, दत्तांशकोशः Redo Log इत्यस्मिन् अभिलेखानां जाँचं करिष्यति तथा च दत्तांशं पुनः प्राप्तुं सर्वाणि प्रस्तुतानि परन्तु निरन्तरं न कृतानि आँकडासंशोधनानि दत्तांशसञ्चिकासु पुनः प्रयोजयिष्यति

3. लेखनप्रदर्शने सुधारं कुर्वन्तु

लेखनक्रियाणां कार्यक्षमतां सुधारयितुम्, दत्तांशकोशाः प्रायः परिवर्तनक्रियाः तत्क्षणमेव डिस्कमध्ये लिखितुं न अपितु अस्थायीरूपेण स्मृतौ संग्रहीतुं कैशिंग्-तन्त्राणां (बफर-पूल-इत्यादीनां) उपयोगं कुर्वन्ति Redo Log इत्यस्य अस्तित्वेन एतत् संग्रहणतन्त्रं सम्भवं भवति, यतः यावत् Redo Log इत्यस्य स्थायित्वं सुनिश्चितं भवति तावत् यावत् cache इत्यस्मिन् दत्तांशः डिस्कमध्ये न लिखितः अपि दत्तांशहानिः नास्ति

व्यवहारं कुर्वन्, log buffer मध्ये redo log डिस्कं प्रति फ्लश भविष्यति भवान् innodb_flush_log_at इत्यस्य उपयोगं कर्तुं शक्नोति
commit पैरामीटर् नियन्त्रणम् । अस्माभिः सम्यक् फ्लशनीतिं innodb_flush_log_at_trx_commit सेट् कर्तुं ध्यानं दातव्यं MySQL मध्ये विन्यस्तस्य फ्लश रणनीत्याः आधारेण, MySQL इत्यस्य अधः गमनस्य अनन्तरं लघुदत्तांशहानिसमस्याः भवितुम् अर्हन्ति ।

innodb_flush_log_at_trx_commit MySQL InnoDB भण्डारणइञ्जिन् मध्ये इदं महत्त्वपूर्णं विन्यासमापदण्डं भवति यदा लेनदेनं प्रस्तुतं भवति तदा लॉगस्य फ्लश (फ्लश) तथा लेखन (लेखन) रणनीतयः निर्धारयति, अतः आँकडानां स्थायित्वं कार्यक्षमतां च प्रभावितं करोति अस्य त्रयः मूल्यानि सन्ति, यथा 0, 1, 2. प्रत्येकं मूल्यं भिन्नं ब्रशिंग् रणनीतिं प्रतिनिधियति ।

• innodb_flush_log_at_trx_commit = 0

  • वर्णेतु : यदा कश्चन व्यवहारः प्रतिबद्धः भवति तदा लॉग् लॉग् बफर मध्ये लिख्यते, परन्तु तत्क्षणं डिस्क मध्ये न । लॉग् सञ्चिकाः प्रति सेकण्ड् डिस्क मध्ये लिख्यन्ते, लॉग् बफर च प्रति सेकण्ड् फ्लश भवति ।
  • लाभ: उच्चतरं प्रदर्शनं यतः डिस्क I/O क्रियाः न्यूनीकृताः भवन्ति ।
  • अभावः: यदा प्रणाली दुर्घटना भवति तदा अन्तिमे १ सेकेण्ड् मध्ये सर्वे व्यवहाराः नष्टाः भवितुम् अर्हन्ति ।
  • प्रयोज्य दृश्य: उच्चप्रदर्शनस्य आवश्यकताभिः सह अनुप्रयोगपरिदृश्यानां कृते उपयुक्तः तथा च शिथिलदत्तांशस्थायित्वस्य आवश्यकताभिः सह।

• innodb_flush_log_at_trx_commit = 1

  • वर्णेतु : प्रत्येकं व्यवहारः प्रतिबद्धः भवति तदा लॉग् तत्क्षणमेव डिस्क मध्ये लिख्यते तथा च लॉग् बफरः तत्क्षणमेव डिस्क मध्ये फ्लश भवति । इदं सर्वाधिकं सुरक्षितं सेटिंग् अस्ति तथा च व्यवहारस्य स्थायित्वं सुनिश्चितं करोति ।
  • लाभ: सर्वोच्चसुरक्षा, यत् प्रत्येकं प्रस्तुतं व्यवहारं निरन्तरं भवति इति सुनिश्चितं करोति, तथा च प्रस्तूयमाणाः व्यवहाराः प्रणाली दुर्घटनाम् अभवत् अपि न नष्टाः भविष्यन्ति।
  • अभावः: न्यूनतरं प्रदर्शनं यतः प्रत्येकं प्रतिबद्धं डिस्क I/O कार्यं प्रेरयति ।
  • प्रयोज्य दृश्य: अनुप्रयोगपरिदृश्यानां कृते उपयुक्तं येषु उच्चदत्तांशस्थायित्वस्य आवश्यकता भवति, यथा वित्तीयप्रणाली, ई-वाणिज्यम् इत्यादयः।

• innodb_flush_log_at_trx_commit = 2

  • वर्णेतु : प्रत्येकं व्यवहारः प्रतिबद्धः भवति तदा लॉग् लॉग् बफर मध्ये लिखितः भवति तथा च तत्क्षणमेव डिस्क मध्ये फ्लश भवति, परन्तु तत्क्षणं लॉग् सञ्चिकायां न लिख्यते । लॉग् सञ्चिकाः प्रति सेकण्ड् एकवारं डिस्क मध्ये लिख्यन्ते ।
  • लाभ: एकं निश्चितपर्यन्तं कार्यक्षमतां सुधारयति तथा च यत् दत्तांशं नष्टं भवितुम् अर्हति (1 सेकण्डस्य अन्तः लेनदेनं अधिकतमं नष्टं भवति) तस्य परिमाणं न्यूनीकरोति।
  • अभावः: यदा प्रणाली दुर्घटना भवति तदा अन्तिम १ सेकेण्ड् मध्ये व्यवहाराः नष्टाः भवितुम् अर्हन्ति ।
  • प्रयोज्य दृश्य: अनुप्रयोगपरिदृश्यानां कृते उपयुक्तं येषां कार्यक्षमतायाः आँकडानां स्थायित्वस्य च विषये कतिपयानि संतुलनस्य आवश्यकतानि सन्ति।

ब्रश रणनीत्याः सारांशः

• 0: उत्तमं प्रदर्शनं, परन्तु सर्वाधिकं जोखिमं, अन्तिमे १ सेकेण्ड् मध्ये सर्वे व्यवहाराः नष्टाः भवितुम् अर्हन्ति।
• 1: सर्वाधिकं सुरक्षितं, प्रत्येकं प्रतिबद्धं व्यवहारं निरन्तरं भवति इति सुनिश्चितं करोति, तथा च कार्यप्रदर्शनं तुल्यकालिकरूपेण न्यूनं भवति।
• 2: कार्यप्रदर्शनस्य सुरक्षायाश्च मध्ये सम्झौता।

4. दत्तांशहानिः भवति

1. redo log log buffer मध्ये लिखितम् अस्ति परन्तु अद्यापि page cache मध्ये न लिखितम् अस्मिन् समये, database crash भवति तथा data hani भवति (इयं data loss तदा भवितुम् अर्हति यदा flush नीतेः innodb_flush log_at trx_commit इति मूल्यं भवति 0);

2. redo log पृष्ठसञ्चये लिखितम् अस्ति परन्तु अद्यापि डिस्क मध्ये न लिखितम् अस्ति तथा च ऑपरेटिंग् सिस्टम् क्रैश भविष्यति तथा च डेटा हानिः भवितुम् अर्हति (एतत् दत्तांशहानिः तदा भवितुम् अर्हति यदा flush नीतेः innodb2 flush log_at trx_commit इत्यस्य मूल्यं भवति २).

5. binlog तथा redolog इत्येतयोः मध्ये किं भेदः अस्ति ?

• बिन्लॉग् मुख्यतया आँकडाधारपुनर्प्राप्त्यर्थं उपयुज्यते, यत् दत्तांशस्तरीयदत्तांशपुनर्प्राप्तेः अन्तर्गतं भवति मास्टर-दासप्रतिकृतिः binlog इत्यस्य सर्वाधिकं सामान्यं अनुप्रयोगपरिदृश्यं भवति Redolog इत्यस्य उपयोगः मुख्यतया लेनदेनस्य स्थायित्वं सुनिश्चित्य भवति, यत् लेनदेनस्तरीयदत्तांशपुनर्प्राप्तेः अन्तर्भवति
• Redolog InnoDB इञ्जिन् कृते अद्वितीयं भवति, तथा च binlog सर्वेषां भण्डारण इञ्जिनस्य कृते सामान्यम् अस्ति, यतः binlog MySQL इत्यस्य Server स्तरेन कार्यान्वितं भवति ।
• Redolog इति भौतिकं लॉग् अस्ति, यत् मुख्यतया कस्यचित् पृष्ठस्य परिवर्तनं अभिलेखयति । Binlog एकः तार्किकः लॉग् अस्ति, यः मुख्यतया दत्तांशकोशेन निष्पादितान् सर्वान् DDL तथा DML कथनान् अभिलेखयति ।
• बिन्लोग् योजयित्वा लिख्यते, आकारस्य सीमा नास्ति । Redolog लेखनार्थं लूप् लेखनविधिं उपयुङ्क्ते, नियत आकारेण सह अन्ते यावत् लेखनं कुर्वन्, लूप् मध्ये लॉग्स् लिखितुं आरम्भं प्रति आगमिष्यति ।

4. undo log undo log

Undo Log (rollback log) एकः लॉगः अस्ति यस्य उपयोगः आँकडाकोषप्रणाल्यां आँकडासंशोधनसञ्चालनानां अभिलेखनार्थं भवति । Undo Log लेनदेनस्य रोलबैक् इत्यत्र प्रमुखां भूमिकां निर्वहति Undo Log इत्यस्य माध्यमेन लेनदेनस्य आरम्भात् पूर्वं स्थितिं प्रति दत्तांशं पुनः स्थापयितुं शक्यते, येन लेनदेनस्य परमाणुता सुनिश्चिता भवति ।

Undo Log इत्यनेन व्यवहारानां परमाणुत्वं कथं सुनिश्चितं भवति

व्यवहारस्य परमाणुत्वस्य अर्थः अस्ति यत् व्यवहारस्य सर्वाणि कार्याणि सर्वाणि निष्पादितानि वा निष्पादितानि वा । Undo Log निम्नलिखित तन्त्राणां माध्यमेन लेनदेनस्य परमाणुत्वं सुनिश्चितं करोति ।

1. पूर्ववतीकरणक्रियाः अभिलेखयन्तु लेनदेनस्य निष्पादनस्य समये, दत्तांशस्य कोऽपि परिवर्तनक्रियाः वास्तविकसंशोधनात् पूर्वं पूर्ववतवृत्ते तत्सम्बद्धं पूर्ववतक्रियां अभिलेखयिष्यति । यथा, यदि कश्चन व्यवहारः अभिलेखपङ्क्तेः मूल्यं अद्यतनं करोति तर्हि अद्यतनीकरणात् पूर्वं पुरातनं मूल्यं Undo Log इत्यत्र अभिलेखितं भविष्यति ।

2. रोलबैक लेनदेन यदि केनचित् कारणेन (यथा त्रुटिः अथवा स्पष्टरोलबैक्) व्यवहारः विफलः भवति तर्हि दत्तांशकोशप्रणाली Undo Log पठति तथा च अभिलेखितस्य पूर्ववतक्रियायाः अनुसारं लेनदेनस्य आरम्भात् पूर्वं दत्तांशं पुनः स्थापयति एवं प्रकारेण भवन्तः सुनिश्चितं कर्तुं शक्नुवन्ति यत् असफलव्यवहारस्य दत्तांशकोशे कोऽपि प्रभावः नास्ति, अतः व्यवहारस्य परमाणुत्वं सुनिश्चितं भवति ।

उद्धरण:

पठन-लेखन पृथक्करणस्य विस्तृतव्याख्या तथा उप-दत्तांशकोशस्य तथा सारणी |