ইনোডাব_ফ্লুশ_লগ_আট_আরএক্সএক্স_কমিট = 2 ব্যবহার করা কি নিরাপদ?


54

আমি ঘুরেছিলাম innodb_flush_log_at_trx_commit = 2এবং খুব দ্রুত লেখার গতি পেয়েছি । তবে এটি কি নিরাপদ প্রোডাকশন ওয়েব সাইটে ব্যবহার করা যাবে?

উত্তর:


57

আপনি এক সেকেন্ডের লেনদেনের পরিমাণ হারাতে পারেন। ডিফল্ট মানটি 1, যা ইনোডিবি এসিডি কমপ্লায়েন্ট রাখতে সহায়তা করে ।

মাইএসকিউএল ডকুমেন্টেশন অনুসারে ইনোডাব_ফ্লুশ_লগ_আট_আরটিএক্সএক্সমিট

যদি ইনোডাব_ফ্লুশ_লগ_এট_আরটিএক্সএক্সকমিটের মান 0 হয় তবে লগ বাফারটি প্রতি সেকেন্ডে একবার লগ ফাইলে লেখা হয় এবং লগ ফাইলে ফ্লাশ টু ডিস্ক অপারেশন করা হয়, তবে লেনদেনের প্রতিশ্রুতিতে কিছুই করা হয় না। যখন মান 1 (ডিফল্ট) হয়, প্রতিটি লেনদেন কমিটে লগ বাফারটি লগ ফাইলটিতে লেখা হয় এবং লগ ফাইলটিতে ডিস্ক অপারেশন ফ্লাশ করা হয়। যখন মান 2 হয়, প্রতিটি কমিটের সময় লগ বাফারটি ফাইলটিতে লেখা থাকে, তবে ফ্লাশ টু ডিস্ক অপারেশন এতে সঞ্চালিত হয় না। যাইহোক, লগ ফাইলটিতে ফ্লাশিং প্রতি সেকেন্ডে একবার একবার হয় যখন মান 2 হয় তবে নোট করুন যে প্রক্রিয়া শিডিয়ুলিংয়ের কারণে প্রতি সেকেন্ডে একবারে ফ্লাশিং প্রতি সেকেন্ডে 100% হওয়ার নিশ্চয়তা দেয় না।

সম্পূর্ণ এসিডি সম্মতির জন্য ডিফল্ট মান 1 প্রয়োজন 1 আপনি 1 এর চেয়ে আলাদা মান নির্ধারণ করে আরও ভাল পারফরম্যান্স অর্জন করতে পারেন তবে তারপরে আপনি ক্র্যাশে এক সেকেন্ডের মূল্য লেনদেন হারাতে পারেন। 0 এর মান সহ যে কোনও mysqld প্রক্রিয়া ক্র্যাশ লেনদেনের শেষ দ্বিতীয়টি মুছতে পারে। 2 এর মান সহ, কেবলমাত্র একটি অপারেটিং সিস্টেম ক্রাশ বা পাওয়ার আউটেজ লেনদেনের শেষ দ্বিতীয়টি মুছতে পারে। InnoDB এর ক্র্যাশ পুনরুদ্ধার মান নির্বিশেষে কাজ করে।

লেনদেনের সাথে InnoDB ব্যবহার করে একটি প্রতিলিপি সেটআপে সর্বাধিক সম্ভাব্য স্থায়িত্ব এবং ধারাবাহিকতার জন্য, আপনার মাস্টার সার্ভার my.cnf ফাইলে ইনোডবি_ফ্লুশ_লগ_্যাট_আরএক্স_কমিট = 1 এবং সিঙ্ক_বিনলগ = 1 ব্যবহার করুন।

সতর্কতা

অনেক অপারেটিং সিস্টেম এবং কিছু ডিস্ক হার্ডওয়্যার ফ্লাশ-থেকে-ডিস্ক অপারেশনকে বোকা করে। তারা মাইএসকিএলডকে বলতে পারে যে ফ্লাশটি ঘটেছিল, যদিও তা হয়নি। তারপরে লেনদেনের স্থায়িত্বটি সেটিং 1 এর সাথেও গ্যারান্টিযুক্ত নয় এবং সবচেয়ে খারাপ ক্ষেত্রে কোনও বিদ্যুৎ বিভ্রাট এমনকি ইনোডিবি ডাটাবেসকে দূষিত করতে পারে। এসসিএসআই ডিস্ক নিয়ামক বা ডিস্কে ব্যাটারি ব্যাকড ডিস্ক ক্যাশে ব্যবহার করে ফাইল ফ্লাশ গতি বাড়িয়ে তোলে এবং অপারেশনটিকে আরও নিরাপদ করে তোলে। আপনি ইউনিক্স কমান্ড hdparm ব্যবহার করে হার্ডওয়্যার ক্যাশে ডিস্ক রাইটিং ক্যাচিং অক্ষম করতে ব্যবহার করতে পারেন বা হার্ডওয়্যার বিক্রেতার সাথে নির্দিষ্ট অন্য কোনও কমান্ড ব্যবহার করতে পারেন।

এর উপর ভিত্তি করে, 1 টির চেয়ে অন্য মানগুলি ইনোডিবি-তে 1 সেকেন্ডের লেনদেনের মূল্য হ্রাস করার ঝুঁকিতে ফেলেছে বা কোনও লেনদেনের জন্য মূল্যবান ডেটা মূল্যায়ণ করে।

ডকুমেন্টেশন এছাড়াও ব্যবহার বলে sync_binlog=1

সিঙ্ক_বিনলগে মাইএসকিউএল ডকুমেন্টেশন অনুসারে

1 এর মান হ'ল নিরাপদ পছন্দ কারণ ক্রাশের ঘটনায় আপনি বাইনারি লগ থেকে সর্বাধিক একটি বিবৃতি বা লেনদেন হারাতে পারেন। তবে এটি ধীর গতির পছন্দ (ডিস্কের ব্যাটারি ব্যাকযুক্ত ক্যাশে না থাকলে, যা সিনক্রোনাইজেশনটিকে খুব দ্রুত করে তোলে)।

আপনার নিরাপদ পছন্দ

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

যদি আপনি সম্ভাব্য ডেটা হ্রাস (1 সেকেন্ডের মূল্য পর্যন্ত) মনে না করেন তবে আপনি যদি পুরস্কার (দ্রুত লেখার গতি) এর পক্ষে মূল্যবান হন তবে আপনি নিজের ঝুঁকিতে 0 বা 2 ব্যবহার করতে পারেন।


3
রোল্যান্ডো: শেষ কয়েক লাইনের জন্য +1 সিঙ্ক_বিনলগ = 1 ...
আবদুল মানাফ

@ আবদুল মনাফ, সর্বদা গতির চেয়ে ডেটা অখণ্ডতার জন্য যান। আপনি যদি ডেটা অখণ্ডতার জন্য গতি ত্যাগ করতে চান তবে আপনি ডেটা সমস্যা মোকাবেলায় নিজেকে আরও বেশি সময় হারাতে দেখবেন।
পেসারিয়ার

1
@ রোল্যান্ডোমাইএসকিউএলডিবিএ, "এক সেকেন্ডের লেনদেনের মূল্য হারাতে", আপনি কি বোঝাতে চেয়েছেন যে একজন সফল commit আসলে হারিয়ে যেতে পারে?
পেসারিয়ার

1
পেসারিয়ার, হ্যাঁ "ডিস্কে ফ্লাশ করা" যাওয়ার পরে কেবলমাত্র ডেটা ডিস্কে লেখার নিশ্চয়তা দেওয়া হয়। ততক্ষণে এটি কেবল র‌্যামের স্মৃতিতে থাকতে পারে।
এমিল ভিকস্ট্রম

2
@ রোল্যান্ডো মাই এসকিউএলডিবিএ আপনি গুরুতরভাবে মানুষ হন। আপনি যদি ফুলটাইম মাইএসকিএল পরামর্শ জিগ ব্যতীত অন্য কিছু করেন তবে আপনার সম্ভবত ক্যারিয়ারের পথ পরিবর্তন করা উচিত।
sjas

25

innodb_flush_log_at_trx_commitযেমন উদ্দেশ্য সঙ্গে ব্যবহার করা হয় ..

মান innodb_flush_log_at_trx_commit 0 হলে লগ বাফারটি প্রতি সেকেন্ডে একবার লগ ফাইলে লেখা হয় এবং ফ্লাশ টু ডিস্ক অপারেশন লগ ফাইলে সঞ্চালিত হয়, তবে কোনও লেনদেনের প্রতিশ্রুতিতে কিছুই করা হয় না।

যখন মান 1 (ডিফল্ট) হয়, প্রতিটি লেনদেন কমিটে লগ বাফারটি লগ ফাইলটিতে লেখা হয় এবং লগ ফাইলটিতে ডিস্ক অপারেশন ফ্লাশ করা হয়।

যখন মান 2 হয়, প্রতিটি কমিটের সময় লগ বাফারটি ফাইলটিতে লেখা থাকে, তবে ফ্লাশ টু ডিস্ক অপারেশন এতে সঞ্চালিত হয় না। যাইহোক, লগ ফাইলটিতে ফ্লাশিং প্রতি সেকেন্ডে একবার একবার হয় যখন মান 2 হয় তবে নোট করুন যে প্রক্রিয়া শিডিয়ুলিংয়ের কারণে প্রতি সেকেন্ডে একবারে ফ্লাশিং প্রতি সেকেন্ডে 100% হওয়ার নিশ্চয়তা দেয় না।

সম্পূর্ণ এসিডি সম্মতির জন্য ডিফল্ট মান 1 প্রয়োজন 1 আপনি 1 এর চেয়ে আলাদা মান নির্ধারণ করে আরও ভাল পারফরম্যান্স অর্জন করতে পারেন তবে তারপরে আপনি ক্র্যাশে এক সেকেন্ডের মূল্য লেনদেন হারাতে পারেন। 0 এর মান সহ যে কোনও mysqld প্রক্রিয়া ক্র্যাশ লেনদেনের শেষ দ্বিতীয়টি মুছতে পারে। 2 এর মান সহ, কেবলমাত্র একটি অপারেটিং সিস্টেম ক্রাশ বা পাওয়ার আউটেজ লেনদেনের শেষ দ্বিতীয়টি মুছতে পারে। InnoDB এর ক্র্যাশ পুনরুদ্ধার মান নির্বিশেষে কাজ করে।

আমার মতে innodb_flush_log_at_trx_commit2 ব্যবহার করা কোনও সমস্যা হওয়া উচিত নয় ut তবে 1 ব্যবহার করা সবচেয়ে নিরাপদ।


3
আমি কেবল লক্ষ্য করেছি যে আপনি আমার পরে কেবল উত্তরটি একই উত্তর দিয়েছিলেন মাত্র 18 সেকেন্ড। +1 !!!
রোল্যান্ডোমাইএসকিউএলডিবিএ

24

আমার মতামত অন্যান্য থেকে পৃথক। innodb_flush_log_at_trx_commit = 0 যদি: এটি আমার বিকাশ কম্পিউটার বা হোম মিনি ডাটাবেস যেখানে কোনও সংবেদনশীল ডেটা নেই।

ইনোডাব_ফ্লুশ_লগ_্যাট_আরএক্সএক্সকমিট = 2 যদি: এটি ব্লগ / পরিসংখ্যান / ই-কমার্স (দিনে ~ 100x শপ সহ) ইত্যাদি etc.

ইনোডব_ফ্লুশ_লগ_্যাট_আরএক্সএক্সকমিট = 1 যদি: আপনার প্রচুর গ্রাহক বা আপনার যেমন ব্যাংকের মতো অর্থ লেনদেনের সাথে কাজ করা দরকার। সুতরাং এবার গতি ও সুরক্ষা পেতে আপনার ডেটাফ্লোটি বেশ কয়েকটি সার্ভারের মধ্যে ভাগ করে নেওয়া উচিত।

আমি 2 টি পছন্দ করি কারণ এটির লেখার গতি ~ 75x রয়েছে এবং হার্ডওয়্যার ব্যর্থ হলে এটি কেবলমাত্র ব্যর্থ হয়।

যাইহোক আপনার আরও বেশি লেখার গতি বা 1 সেকেন্ড পর্যন্ত তথ্য কী প্রয়োজন তা জানতে হবে?


1
+1 এর জন্য75x faster write speed and it fails ONLY if hardware fails.
নমন গালা

3
75x দ্রুত? হদফ ঘ.
পেসারিয়ার

5
আমার নিজস্ব মানদণ্ড: 5000 UPDATEসহ innodb_flush_log_at_trx_commit = 1: 179 সেকেন্ড সহ innodb_flush_log_at_trx_commit = 2: 1.12 সেকেন্ড। এটি আমার ক্ষেত্রে 160x দ্রুত লেখার গতি।
কেভিন

ভাল উত্তর. মনে করার মতো একটি বিষয় হ'ল - যদি আপনার মেশিনটি সাফল্যপূর্ণ লেনদেনের পরে ক্র্যাশ হয়ে যায়, তবে ইন্নাডব_ফ্লুশ_লগ_এ্যাট_আরএক্সএক্সমিট = 2 দিয়ে লেনদেনটি ডিস্কে লিখিত না হওয়ার সম্ভাবনা রয়েছে এবং তবুও সাফল্য আপনার অ্যাপ্লিকেশনটিতে নির্দেশিত হয়েছে (অর্থাত্ mysqld একটি নেটওয়ার্ক প্যাকেট প্রেরণে পরিচালনা করে যা লেনদেন সফলভাবে সমাপ্ত হয়) আপনার অ্যাপ্লিকেশনটিতে ড্রাইভারটির কাছে), সেই সুযোগটি খুব কম
ভ্লাদিস্লাভ ভ্যানট্রব

crash
শরীফ

2

আমি উত্তর দেওয়ার চেষ্টা করছি, এর উদ্দেশ্য কী innodb_flush_log_at_trx_commit?

InnoDB এর বেশিরভাগ অপারেশন মেমোরিতে ( InnoDB Buffer Pool) করে। সমস্ত পরিবর্তিত ডেটা InnoDB transaction log fileটিকেট স্টোরেজ (হার্ড ডিস্ক) এ লিখে এবং তারপরে ফ্লাশ করা (লিখিত) হয়।

ডেটা সুরক্ষার জন্য ( Durability from ACID), InnoDB- কে প্রতিটি লেনদেনের পরিবর্তিত ডেটা স্থায়ী সঞ্চয়স্থানে সংরক্ষণ করতে হবে। একই সময়ে, প্রতিটি লেনদেনের জন্য ডিস্ক প্রতিশ্রুতিবদ্ধ ব্যয়বহুল প্রক্রিয়া।

ডিস্ক I / O একটি ব্লকিং প্রক্রিয়া এবং এটি খুব ধীর গতির, এটি ধীর গতির ডিস্ক, আরও এটি InnoDB transaction per seconds(ডিস্কের মাধ্যমে আউটপুট) কমিয়ে দেবে ।

InnoDB innodb_flush_log_at_trx_commitএই ফ্লাশ অপারেশনের ফ্রিকোয়েন্সি নিয়ন্ত্রণ করতে ভেরিয়েবল সরবরাহ করে। মানের উপর ভিত্তি করে, InnoDB ফ্লাশ অপারেশন ভিন্নভাবে আচরণ করে।

(অন্যান্য উত্তরে ইতিমধ্যে ব্যাখ্যা করা হয়েছে)

0 - লগ ফাইল লিখুন এবং প্রতি সেকেন্ডে ডিস্কে ফ্লাশ করুন (পারফরম্যান্স লাভের জন্য ডেটা লগ ফাইলের জন্য বাফার পুলে নেই)। 1 - কোনও লেনদেনের সময় ডিস্কে ফ্লাশ করুন - ডিফল্ট (ডেটা সুরক্ষার জন্য - এসিডি সম্মতি) 2 - প্রতিটি লেনদেনের জন্য ফাইল লগ করতে লিখুন এবং প্রতি সেকেন্ডে ডিস্কে ফ্লাশ করুন। (কর্মক্ষমতা লাভের জন্য)

অ্যাপ্লিকেশন প্রয়োজনীয়তার উপর নির্ভর করে ( Performance Vs data safety), আপনি এই পরিবর্তনশীল সেট করতে পারেন। 0 এবং 2 এর মধ্যে পার্থক্য - উভয়ই কর্মক্ষমতা বৃদ্ধি করবে, মান 2 লেনদেনের ফাইলে ডেটা সঞ্চয় করে এবং ক্র্যাশ বা ব্যর্থতার ক্ষেত্রে পুনরুদ্ধারযোগ্য হতে পারে, তবে 0-এ নয়।

অনেক ক্ষেত্রে ফ্লাশ থেকে ডিস্কের অর্থ হ'ল ডেটা InnoDB buffer pool (memory) to Operating systems cacheআসলে স্টোরেজ ডিস্কে স্থায়ী নয় (স্থায়ী সঞ্চয়স্থান) লেখা হয়। ব্যর্থতার ক্ষেত্রে, সবচেয়ে খারাপ ক্ষেত্রে, আপনি এক সেকেন্ড পর্যন্ত ডেটা হারাতে পারেন)

পারফরম্যান্স লাভ পরিবেশের উপর নির্ভর করে এবং আপনি বেঞ্চমার্ক এবং সনাক্ত করতে পারেন। একটি প্রতিরূপ পরিবেশে, ডেটা সুরক্ষা এবং ধারাবাহিকতার জন্য, সেট innodb_flush_log_trx_commit = 1এবং sync_binlog=1

কর্মক্ষমতা যদি অ্যাপ্লিকেশনটির মূল লক্ষ্য হয় তবে লোগো ফ্লাশিংয়ের ফ্রিকোয়েন্সি নিয়ন্ত্রণ করতে ইনোডিবি একটি পরিবর্তনশীল সরবরাহ করে innodb_flush_log_at_timeout- যা আপনাকে লগ ফ্লাশিং ফ্রিকোয়েন্সি রেঞ্জ সেট করতে দেয় 1 to 2700 seconds, ডিফল্টরূপে এটি 1 হয়।

সচেতন থাকুন, যখন আপনি ফ্লাশিং ব্যবধানটি এন সেকেন্ড পর্যন্ত বাড়ান, পারফরম্যান্স লাভটি এন সেকেন্ড পর্যন্ত ডেটা সুরক্ষায় আপস করে আসে। উদাহরণস্বরূপ - আপনি যদি প্রতি 5 সেকেন্ডে ফ্লাশিং সেট করেন - থ্রুপুট লাভ খুব বেশি তবে বিদ্যুৎ ব্যর্থতা বা সিস্টেম ক্রাশের ক্ষেত্রে আপনি 5 সেকেন্ডের ডেটা হারাবেন।

এই নিবন্ধটি InnoDB ফ্লাশিং এবং লেনদেনের প্রতিশ্রুতিবদ্ধ ক্রিয়াকলাপ সম্পর্কে আলোচনা করবে ।

আপনি আরএসএসে মোড 2 করার পরে আপনি পরিবর্তন করতে পারেন:

আপনি অ্যাডস মোড 2 করার পরে পরিবর্তন করতে পারে

previewchanges

কিছু ক্ষেত্রে যেমন আপনি যদি প্রতিলিপি মাল্টি এজেড করতে পারেন তেমন পরিবর্তনযোগ্য:

এফওয়াইআই কিছু ক্ষেত্রে অবিশ্বাস্য


1

যদি আপনার হার্ডওয়্যার ব্যর্থ হয়, আপনি আপনার সমস্ত ডেটা আলগা করতে পারেন, তাই আমি কোনও উদ্বেগ ছাড়াই পরম = 2 ব্যবহার করি। যাইহোক আপনি সংবেদনশীল (অর্ডার, ভার্চুয়াল অর্থ, ...) এবং নিয়মিত (পরিসংখ্যান, কার্ট, ...) ডেটা 2 ডিবি সার্ভারের মধ্যে ভাগ করতে পারেন এবং সেগুলি নিরাপদ এবং দ্রুত রাখতে পারেন। ডাটাবেসের মধ্যে লেনদেনের জন্য আপনি http://dev.mysql.com/doc/refman/5.7/en/xa.html ব্যবহার করতে পারেন


"আপনার সমস্ত ডেটা হারাবেন", বা আপনি কি বোঝাতে চেয়েছিলেন যে লেনদেনগুলি গত কয়েক সেকেন্ড বা তার পরে অনুসন্ধান করা হয়েছিল?
NiCk নিউম্যান

1
একটি হার্ডওয়্যার ব্যর্থতার অর্থ একটি সম্পূর্ণ হার্ড ড্রাইভ হারাতে পারে, সুতরাং "আপনার সমস্ত ডেটা হারাবেন"। সুতরাং আপনার যদি কোনও রেপ্লিকেশন সেটআপ না থাকে তবে আপনার ডেটা আপনি যেভাবেই কোনওভাবে ব্যাকআপ রাখবেন তার করুণায় নেই, সুতরাং এই উত্তরটি যে
বক্তব্যটি দিচ্ছিল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.