হাই ট্র্যাফিকের ডাটাবেস সার্ভারে খুব বেশি হার্ড ড্রাইভ থাকা কি খারাপ?


12

উচ্চ ট্র্যাফিক উত্পাদন ডেটাবেস সার্ভারের জন্য মাইএসকিউএল সহ উবুন্টু সার্ভার চালানো। মাইএসকিউএল উদাহরণ ব্যতীত অন্য কোনও কিছুই মেশিনে চলছে না।

আমরা ডিবি সার্ভারে প্রতিদিনের ডাটাবেস ব্যাকআপগুলি সঞ্চয় করি, হার্ড ডিস্কটি তুলনামূলকভাবে খালি রাখার কোনও কার্যকারিতা হিট বা কারণ আছে কি? যদি ডিস্কটি ডেটাবেস এবং সমস্ত ব্যাকআপের সাথে 86% + পর্যন্ত পূর্ণ হয় তবে এটি কি কার্য সম্পাদনকে ক্ষতি করে?

সুতরাং 86-90% + সম্পূর্ণ ক্ষমতা সহ চলমান ডিবি সার্ভারটি কি কোনও 10% পূর্ণ ডিস্কের সাথে চালিত সার্ভারের চেয়ে কোনও উপায়ে কম সঞ্চালন করবে?

সার্ভারে মোট ডিস্কের আকার 1 টিবি ছাড়িয়ে গেছে তাই বেসিক ও / এস অদলবদল এবং এর জন্যও ডিস্কের 10% পর্যাপ্ত হওয়া উচিত।


1
মূল হিসাবে একই বিভাগে মাইএসকিউএল ডেটা (/)? আপনি সত্যিই এটি পূরণ করতে চান না; ক্র্যাশ শহর।
গ্রেভিফেস

1
আমি মনে করি না যতক্ষণ ডেটা ভালভাবে পরিচালিত হচ্ছে ততক্ষণ ডিস্কের জায়গা সাফ করার কোনও অন্তর্নিহিত কারণ রয়েছে। যার কথা বললে, আপনি কেন স্থানীয়ভাবে ব্যাক আপ করছেন? আমি প্রথমে যা করব তা হ'ল সেই ব্যাকআপগুলি অন্য বাক্সে ফেলে দেওয়া।
বেনসি

মনে রাখবেন যে প্রায় পূর্ণ একটি ডিস্কে ডেটাবেসের উপর নির্ভর করে পরিষেবাগুলির জন্য ডাউনটাইম ঝুঁকি থাকে। ডিবি ডিস্ক পূর্ণ হলে ডিবি বন্ধ হবে। সুতরাং কম স্থান বামে উচ্চ ডাউনটাইম ঝুঁকির ফলে হবে।
মিঃটি

উত্তর:


11

সবার আগে আপনি আপনার ডাটাবেস হিসাবে একই শারীরিক ড্রাইভ বা RAID গ্রুপে আপনার ডাটাবেস ব্যাকআপ রাখতে চান না। এর কারণ হ'ল ডিস্ক ব্যর্থতা (আপনি যদি কোনও RAID সুরক্ষা ব্যতীত চলমান) বা একটি বিপর্যয়কর RAID ব্যর্থতা (আপনি যদি RAID-1 বা RAID-5 ব্যবহার করছেন) আপনাকে আপনার ডাটাবেস এবং আপনার ডাটাবেস ব্যাকআপ হারিয়ে ফেলবে।

ডিস্ক কর্মক্ষমতা সম্পর্কে আপনার প্রশ্নটি কীভাবে ডিস্কের ডেটা অ্যাক্সেস করা যায় তার উপর নির্ভর করে একটি ডিস্ক ড্রাইভ কীভাবে পূর্ণ। স্পিনিং ডিস্কের জন্য দুটি শারীরিক কারণ রয়েছে যা I / O সম্পাদনাকে প্রভাবিত করে। তারা হ'ল:

  • সময় সন্ধান করুন - যে সময়টি ডিস্ক ড্রাইভকে তার বর্তমান ট্র্যাক অবস্থান থেকে অনুরোধকৃত ডেটা রয়েছে এমন ট্র্যাকের দিকে নিয়ে যাওয়ার জন্য সময় নেয়

  • ঘূর্ণনকালীন বিলম্বিতা - যা ড্রাইভটি স্পিন হিসাবে পঠিত শীর্ষে পৌঁছতে কাঙ্ক্ষিত ডেটার জন্য গড় সময় লাগে - 15 কে আরপিএম ড্রাইভের জন্য এটি 2 এমএস (মিলিসেকেন্ড)

আপনার ড্রাইভটি কতটা পরিপূর্ণ তা আপনার সার্ভারের আই / ওএসের অভিজ্ঞতা অর্জনের গড় সময়কে প্রভাবিত করতে পারে। উদাহরণস্বরূপ, যদি আপনার ড্রাইভটি পূর্ণ থাকে এবং আপনার কাছে ডাটাবেস টেবিলগুলি থাকে যা ডিস্কের প্লাটারগুলির চূড়ান্ত বিপরীত প্রান্তে ড্রাইভের উপরে শারীরিকভাবে অবস্থিত থাকে, তবে আপনি যখন এই টেবিলগুলির প্রত্যেকটি থেকে আই / ওএস অ্যাক্সেসের তথ্য গ্রহণ করবেন তখন যাঁরা আই / ওএস অনুভব করবেন ড্রাইভের সর্বাধিক সন্ধানের সময়

এটি বলা হচ্ছে, তবে, যদি আপনার ড্রাইভটি পূর্ণ থাকে এবং আপনার অ্যাপ্লিকেশনটি ড্রাইভে থাকা কেবলমাত্র একটি ছোট্ট ভগ্নাংশ অ্যাক্সেস করে এবং এই সমস্ত ডেটা ড্রাইভের সাথে স্বচ্ছলভাবে অবস্থিত হয়, তবে এই আই / ওসটি সময় সন্ধানের মাধ্যমে সামান্য প্রভাবিত হবে ।

দুর্ভাগ্যক্রমে, এই প্রশ্নের উত্তর হ'ল "আপনার মাইলেজটি পৃথক হবে", এর অর্থ হল আপনার অ্যাপ্লিকেশন কীভাবে ডেটা অ্যাক্সেস করে এবং সেই ডেটাটি কোথায় অবস্থিত তা নির্ধারণ করবে যে আপনার আই / ও কর্মক্ষমতাটি কী হবে।

এছাড়াও, @ গ্রাফিফেস দ্বারা উল্লিখিত হিসাবে, আপনার ডাটাবেস থেকে আপনার অপারেটিং সিস্টেম স্টোরেজ প্রয়োজনীয়তা পৃথক করা "সেরা অনুশীলন" হবে। আবার, এটি ডিস্ক পৃষ্ঠের মাথার গতি কমিয়ে আনতে সহায়তা করবে কারণ একই ড্রাইভে উভয়ই চালনা অপারেটিং সিস্টেম এবং ড্রাইভের ডাটাবেস অঞ্চলের মধ্যে ধ্রুবক অনুসন্ধান করতে পারে কারণ অপারেটিং সিস্টেম এবং ডাটাবেস সফ্টওয়্যার উভয়ই I / O অনুরোধ করে make


8

এখানে দুটি টি কোণ বিবেচনা করতে হবে: পারফরম্যান্স এবং দৃust়তা।

পারফরম্যান্স অনুযায়ী, সাধারণত আলাদা আলাদা ডিস্ক স্পিন্ডেল (বা RAID গ্রুপ / ড্রাইভ সেট) রাখার পরামর্শ দেওয়া হয়:

  1. ওএস স্টাফ (বাইনারি, লগ, হোম ডিরেক্টরি ইত্যাদি)
  2. অদলবদল (যদি আপনি স্যুপ ব্যবহারের প্রত্যাশা না করেন তবে (1) এর সাথে একত্রিত হতে পারে)
  3. প্রোডাকশন ডিবি
  4. প্রোডাকশন ডিবির লেনদেন লগ (যদি ব্যবহৃত হয়)
  5. ডাটাবেস ডাম্প / ব্যাকআপ

এর পিছনে যুক্তিটি বেশ সহজবোধ্য: আপনি "অন্যান্য জিনিস" দ্বারা ডিস্কের দাবিতে DB সম্পাদন প্রভাবিত করতে চান না (উদাহরণস্বরূপ, যদি মেশিনটি ভারীভাবে অদলবদল শুরু করে এবং ডিবি ডেটা থেকে ডিস্কের অন্য দিকে সোয়াপ পার্টিশনটি থাকে তবে আপনি দীর্ঘ ডিস্কের সাথে লড়াই করতে চাইছে)।


দৃ rob়তার দৃষ্টিকোণ থেকে আপনি একই ধরণের ব্রেকডাউন চান, তবে ভিন্ন কারণের জন্য: অন্যরা যেমন উল্লেখ করেছে যে আপনি আপনার ডিবি এবং এর ব্যাকআপ উভয়ই নিতে ব্যর্থ ডিস্ক চান না (যদিও বাস্তবে আপনার ব্যাকআপগুলি অনুলিপি করা উচিত) সার্ভারটি যে কোনও উপায়ে বিপর্যয় ঘটায়)।

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


দুঃখের বিষয় যে /ডিফল্টরূপে অনেকগুলি ডিগ্রো একটি উবারের সাথে পার্টিশন সেটআপ করে ।
গ্রেভিফেস

@ গ্রাফিফেস সম্মত - আমি জানি এখন উবুন্টু (12.04) আপনাকে এটির জন্য এবং সঠিকভাবে বিভাগিত বিভাজন বিন্যাসের মধ্যে পছন্দ দেয়। এটির ডিফল্টটি কী তা নিশ্চিত নন, তবে আইএমএইচও এটি ইউনিক্স সম্প্রদায়ের ক্ষতি করার ক্ষেত্রে লিনাক্সের সবচেয়ে খারাপ কাজগুলির মধ্যে একটি হতে পারে: হাজার হাজার "সিসাদমিন" যারা মনে করেন যে একটি একক বিশাল /পার্টিশন পুরোপুরি ঠিক আছে এবং পুনরায় প্রশিক্ষণ করতে হবে ...
voretaq7

5

আমি ডেটাবেস এবং অস্থায়ী (নীচে দেখুন) ব্যাকআপগুলিকে রুট (/) এর চেয়ে পৃথক পার্টিশনে স্থানান্তরিত করার পরামর্শ দেব।

এছাড়াও, আপনার (ধরে নেওয়া) সংকুচিত ডেটাবেস ডাম্প ব্যাকআপগুলির জন্য একটি বুদ্ধিমান রোটেশন / রিটেনশন স্কিম নিয়ে আসুন। স্থানীয় ডিস্কে ব্যাকআপের অনেকগুলি অনুলিপি রাখার (সাধারণত) কোনও কারণ নেই। দুর্যোগ পুনরুদ্ধারের জন্য কিছুই করে না এবং যখন অফ-সাইট স্থানান্তরিত হয়, তখন ডিস্ক থেকে সরিয়ে ফেলা উচিত।

এটি বেশ মানক অপারেটিং পদ্ধতি procedure


4

এটি আমাকে নেট অ্যাপের একটি বাগের কথা মনে করিয়ে দিয়েছে যেখানে ফাইল সিস্টেমগুলি সম্পূর্ণরূপে তাদের কার্যক্ষমতা হ্রাস পেয়েছিল (অর্ধেকের মতো)। (স্বীকার করেছেন যে কয়েক বছর আগে ছিল)।

প্রত্যেকে যেমন বলেছিল উত্তরটি এটি নির্ভর করে তবে এটির মাধ্যমে এটি চিন্তা করা মূল্যবান।

সম্পূর্ণ ফাইল সিস্টেমের প্রধান অবক্ষয় হ'ল ফ্রি আইওডগুলির তালিকাটি সম্ভবত খণ্ডিত এবং সমস্ত জায়গাতেই রয়েছে।

ডাটাবেসের জন্য হার্ড ডিস্কে তিন ধরণের ডেটা বসে।

  1. আপনার আসল ডাটাবেস ফাইল। এটি একটি বৃহত পূর্বনির্ধারিত ফাইল হবে যা সাধারণত বড় অংশগুলিতে বৃদ্ধি পায় (উদাহরণস্বরূপ 10%)।
  2. লগস, আপনার লেনদেন লগ যা অবিচ্ছিন্নভাবে লিখিত হচ্ছে, মুছে ফেলা হচ্ছে, লিখিত, ইত্যাদি ...
  3. মেমরিতে চলতে পারে না এমন বড় প্রশ্নের জন্য অস্থায়ী ফাইল।

(1) কেবলমাত্র আপনার ফাইল সেটের জন্য আরও স্থান বরাদ্দ করার সময় মুক্ত স্থান প্রয়োজন needs যদি আপনার ডাটাবেসটি বাড়ছে না তবে এটি একটি কম ডিস্ক স্পেস ফাইল সিস্টেম দ্বারা অকার্যকর হওয়া উচিত। যদিও এটি বরাদ্দ করা হয়, এটি এমন একটি খুব বড় অংশের জন্য জিজ্ঞাসা করতে পারে যা আপনার তাত্ক্ষণিকভাবে আপনার ডাটাবেসকে টুকরো টুকরো করে ফেলার এবং কোনও মেমরির জন্য প্রস্তুত করার জন্য যখন ডেটা প্রয়োজন তখন অনুসন্ধান করার কারণ তৈরি করে any

(২) লগগুলিতে একটি নির্লজ্জ প্রয়োগ, যেখানে এটি স্থান বরাদ্দ পরিচালনার জন্য ওএস ব্যবহার করে এবং এটি মুছে ফেলার ফলে ক্ষতিগ্রস্থ হবে। আপনার ডাটাবেসটি কেবল পঠিত নয় ধরে নেওয়া, লগগুলির একটি অবিরাম প্রবাহ থাকবে, তারা প্রায়শই একটি হার্ড ডিস্কের জায়গাতে খণ্ডিত হবে। শেষ পর্যন্ত এটি আপনার লেখার কার্যকারিতা ক্ষতিগ্রস্থ করবে।

()) টেম্পডিবি, যদি ডিবির কাছে যদি রোধযোগ্য লেখাগুলি প্রশ্নের প্রয়োজন হয় না, বা পর্যাপ্ত র‌্যাম না থাকে তবে আপনার কম পড়া ডিস্ক স্পেসের চেয়ে বড় সমস্যা দেখা দিয়েছে কারণ এমনকি আপনার পড়ার পারফরম্যান্স তখন ডিস্ককে আবদ্ধ হতে পারে। আপনি যদি মাইএসকিউএলকে টেম্পডিবিয়ের জন্য ডিস্কের স্থান বরাদ্দ করতে এবং হার্ডডিস্কটি ফুরিয়ে যায় তবে আপনি আউটেজের ঝুঁকিও চালান।

ব্যাকআপ সম্পর্কে ...

  1. আমি যে এন্টারপ্রাইজটিতে কাজ করেছি সেগুলি একই মেশিনে ব্যাকআপ রাখে। যখন এটি পুনরুদ্ধার আসে (কে ব্যাকআপগুলির বিষয়ে চিন্তা করে, এটি সেই গণনাটি পুনরুদ্ধার করে)। কিছুই ঠিক একই ডিস্কে ডিবি ফাইল থাকার গতি হারাতে পারে না।
  2. আশা করি সুস্পষ্ট, ব্যাকআপগুলি কেবল স্থানীয় নয়।

সংক্ষেপে আমি বলব আপনি আপনার ডিবি সরবরাহ করে বেঁচে থাকবেন ভারী লেখা নয়। যদি এটি হয় তবে লো ডিস্ক স্পেস একটি সমস্যা। তবে আমি যদি আপনি হয়ে থাকি তবে আমি নিম্নলিখিতটির চেয়ে খুব শীঘ্রই নিম্নলিখিতগুলিতে কাজ করব।

  1. নিশ্চিত করা হচ্ছে আমার যথেষ্ট পরিমাণে র‌্যাম রয়েছে
  2. আপনার ডিবি থেকে লগগুলি এবং সমস্ত ক্ষণস্থায়ী ডেটা আলাদা করা।
  3. আপনার ওএসকে পৃথক করে, আপনার মাইএসকিউএল ইনস্টল করে বাকি থেকে।

আপনি যদি 1 এর জন্য পারেন তবে আলাদা স্পিন্ডল এবং নিয়ন্ত্রক ব্যবহার করুন।

এর পরে পৃথক স্পিন্ডল রয়েছে

একটি দরিদ্র মানুষের পৃথক পার্টিশন অনুসরণ করে।


0

আমি যখন আমার প্রতিলিপি সার্ভারগুলির মধ্যে একটিতে সমস্ত ডিস্ক স্থান ব্যবহার করেছি তখন আমার একইরকম সমস্যা হয়েছিল। তাত্ক্ষণিক প্রভাবটি ক্র্যাশের প্রতিরূপের জন্য ছিল এবং তারপরে আমি মাইএসকিউএল এ লগ ইন করতে পারিনি কারণ mysqld.sock ফাইলটি খোলা যায় নি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.