লেনদেন লগ ব্যাকআপস সিরিয়াল বা সমান্তরাল?


15

আমরা এসকিউএল সার্ভার 2012 মানক সংস্করণ ব্যবহার করে যাচ্ছি। ব্যাকআপ এবং রক্ষণাবেক্ষণের জন্য একটি সহজ, আরও নমনীয় কাঠামো সরবরাহ করতে আমি ওলা হ্যালেনগ্রেনের স্ক্রিপ্টগুলি ব্যবহার করতে পারি happen

এই প্রশ্ন ওলার স্ক্রিপ্টগুলি সম্পর্কে এতটা নয় যেমন তারা সেরা অনুশীলন সম্পর্কে। আমি বুঝতে পারি চূড়ান্ত উত্তরটি "এটি আপনার সংস্থার প্রয়োজনীয়তার উপর নির্ভর করে"। তবে আমি আমাদের সংস্থার প্রয়োজনীয়তা সম্পর্কে যা বুঝি তা কীভাবে সর্বোত্তমভাবে পূরণ করতে পারি সে সম্পর্কে সম্প্রদায়ের পরামর্শ নেওয়ার চেষ্টা করছি।

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

সুতরাং, এটি কি সত্য যে ওলার স্ক্রিপ্টগুলি সিরিয়ালে চালিত হয় এবং ব্যর্থতা ক্রমাগত ব্যাকআপগুলি বন্ধ করে দেয়?

এবং প্রতিটি ডাটাবেসের জন্য একটি চাকরি করা কি ভাল? বা একটি একক কাজ যে সব করে? আমার প্রবণতা পৃথক চাকরীর দিকে, তবে আমি বুঝতে চাই যে এসকিউএল সার্ভার ডিবিএ সাধারণভাবে কী করে থাকে।


1
আমি ডাটাবেস প্রতি একটি কাজের দিকে ঝুঁকছি যেহেতু এটি সেভাবে আরও পরিচালিত হয় তবে আমি "কন্ট্রোল ফ্রিক" বা তাই আমাকে বলা হয়েছিল ... সম্ভবত আপনার কাছে এমন একটি ডাটাবেস রয়েছে যা 15 মিনিটের ডেটা হ্রাস করতে পারে, তবে আর একটিতে কেবল 5 মিনিট সময় লাগতে পারে, কেবল শুরু করার জন্য।
ম্যাক্স ভার্নন

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

@ ম্যাক্স ভার্নন - সম্ভবত তবে কিছু মতামত ভিত্তিক প্রশ্নগুলি বৈধ। আমি কেবল শিখা যুদ্ধ শুরু করার চেয়ে প্রশ্নগুলি জিজ্ঞাসা করার চেষ্টা করি ask প্লাস আমি আমার সমস্ত চাকরিতে দুর্ঘটনাজনিত / জুনিয়র ডিবিএ হওয়ার প্রবণতা রেখেছি। প্রথম ডিবি 2 এবং এখন এসকিউএল সার্ভার। সুতরাং আমার কাছ থেকে শেখার কোনও সিনিয়র নেই। আমার একমাত্র সম্পদ হল সম্প্রদায়। সুতরাং আমি মনে করি এর মতো একটি প্রশ্ন ন্যায্য। এটি আমার এবং অন্যান্য দুর্ঘটনাজন / জুনিয়রদের থেকে এটি শিখতে দেয়।
ক্রিস অ্যালডরিচ

সম্ভবত প্রতি 10 মিনিটে লগ ব্যাকআপ নেবেন যাতে প্রকৃত বিলম্বটি 15 মিনিটের বেশি কখনও না হয়?
usr

উত্তর:


6

আমার কি এমন একটি কাজ সেট আপ করা উচিত যা ALL_DATABASES ব্যবহার করে? বা প্রতিটি ডাটাবেসের জন্য একটি কাজ স্থাপন করা এবং সমান্তরালভাবে সেগুলি বন্ধ করে দেওয়া কি আরও ভাল?

আমি এমন একটি কাজ সেটআপ করার পরামর্শ দেব যা লেনদেনের লগগুলিকে ব্যাকআপ করবে (সিরিয়ালি)। এটিও নিশ্চিত করবে যে ব্যাকআপ আই / ও ব্যবহারের ভারী নয় because কারণ আপনি একবারে ডাটাবেসের জন্য ব্যাকআপ চালাচ্ছেন।

সমান্তরালে দৌড়াদৌড়ি দিয়ে কী কী সমস্যা হতে পারে

  1. ধরুন আপনার কাছে 50 টি ডাটাবেস রয়েছে এবং আপনার সমস্ত ডাটাবেসের লেনদেনের লগ ব্যাক-এর সময়সূচী হয় এবং তারা সমস্ত সমান্তরালে চলতে শুরু করে এটি অবশ্যই I / O এর প্রচুর ব্যবহার করতে চলেছে। এবং যদি ডিস্কের উপর এটি ফাইলগুলির ব্যাক আপ করে থাকে তবে অন্যান্য ডেটা ফাইল থাকতে পারে আপনি অল্পই দেখবেন। আমি দেখেছি যখন ব্যাকআপটি ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে।

  2. আবার ধরুন আপনার কাছে 50 টি ডাটাবেস থাকলে এসকিউএল সার্ভার এজেন্টে 50 টি কাজ পরিচালনা করা কঠিন হবে না এবং যদি আপনার এসকিউএল সার্ভার এজেন্ট খোলার সময় এবং প্রচুর কাজ দেখতে পান তবে আমার শর্তটি কী হবে যদি আমি 100-200 ডাটাবেসগুলি পাই না তবে, শুধু সহজ রাখুন। আমি নিশ্চিত যে একই মামলাটি আপনার সাথেই থাকবে।

সিরিয়ালটির খারাপ দিকটি হ'ল প্রতিটি ক্রমাগত ব্যাকআপ অন্যটি সম্পূর্ণ না হওয়া পর্যন্ত অপেক্ষা করে। এটি ব্যাকআপগুলির মধ্যে সম্ভাব্য সময়ের পরিমাণ বাড়িয়ে তুলতে পারে (অর্থাত্ 15 মিনিটেরও বেশি)।

লেনদেন লগ ব্যাকআপগুলি বেশিরভাগই ছোট এবং আপনার যদি ব্যস্ত ডাটাবেস প্রচুর লগ রেকর্ড তৈরি করে তবে আপনার ব্যাকআপের ফ্রিকোয়েন্সি পরিবর্তন করতে হবে need প্রায়শই আমি দেখেছি লেনদেনের লগ ব্যাকআপ জরিমানা সম্পূর্ণ হয় যখন 15 মিনিট হয়। আমি মনে করি না যে আপনার জন্য উদ্বেগের বিষয় হওয়া উচিত।

এছাড়াও আমার উদ্বেগটি হ'ল যে এক ব্যাকআপে ব্যর্থতা অন্যকে ঘটতে বাধা দেয় এবং আমিও তা চাই না

আমি বলব শুধু এটি সম্পর্কে চিন্তা করবেন না। লেনদেন লগ ব্যাকআপগুলি ব্যর্থ হতে পারে যদি আপনি কিছু ভুল না করেন। ভুল হতে পারে

  1. চাকরিরত মালিককে এডি থেকে সরানো হয়েছে

  2. কেউ ডাটাবেসের পুনরুদ্ধারের মডেলটি পরিবর্তন করেছে।

  3. অপর্যাপ্ত ডিস্ক স্থান

উপরে বাদে লেনদেন লগ ব্যাক ব্যর্থ হওয়ার কোনও কারণ আমি দেখিনি। এটির খুব দৃust় আপনি এটির উপর নির্ভর করতে পারেন।


6

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

নীচের সমস্ত শর্ত সত্য হলে কেবল সমান্তরালভাবে ব্যাকআপগুলি চালানো উপকারী হবে:

  • আপনার ডাটাবেস এবং লগ ফাইলগুলি সমস্ত অনন্য স্বাধীন স্পিন্ডলে রয়েছে (বা কোনও সংমিশ্রমে শক্ত স্টেট ডিস্কে রয়েছে)

    • শুধু টি-লগ ব্যাকআপের জন্য, কেবল লগ ফাইলগুলিতে এই প্রয়োজনীয়তাটি পূরণ করা প্রয়োজন।
  • প্রতিটি ডাটাবেসের জন্য আপনার ব্যাকআপ লক্ষ্যগুলি পৃথক স্পিনডেলে থাকে।

  • আপনি এসকিউএল সার্ভার উদাহরণ এবং মিডিয়াগুলির মধ্যে ভাগ করা সান এইচবিএ বা আইএসসিএসআই বা অন্যান্য ব্যান্ডউইথ ব্যবহার করছেন না।

  • অর্থাত্ ডাটাবেস এ পড়া এবং ব্যাকআপ এ লেখা থেকে আইওপিএস, ডাটাবেস বি পড়া এবং ব্যাকআপ বি লেখার মতো একই ডিস্ক ব্যবহার করবেন না

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

একটি ব্যাকআপ ব্যর্থ হওয়া এবং বাকীটি সফল হওয়ার বিষয়ে চিন্তা করবেন না - যদি কোনওরকম ব্যর্থ হয় তবে আপনাকে যে কোনও উপায়ে সবকিছু পরীক্ষা করে নেওয়া দরকার এবং ব্যাকআপ ব্যর্থ হওয়ার জন্য আমি কেবল একবার ব্যর্থ হয়েছি:

  • ডিস্ক ব্যর্থতা

  • হাইপারব্যাক / লাইটস্পিড / তৃতীয় পক্ষের সংক্ষেপণ সফ্টওয়্যার ব্যর্থতা (যদি আপনার এসকিউএল এবং ডিস্কের মধ্যে সফ্টওয়্যার ব্যর্থ হয়)

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

  • নেটওয়ার্ক ব্যর্থতা (যদি ডাটাবেস ফাইলগুলি বা আরও বেশি সম্ভাবনা থাকে ব্যাকআপ ফাইলগুলি নেটওয়ার্কে থাকে)

  • অনুমতিসমূহ

    • ব্র্যান্ড নতুন ইনস্টলগুলির সাথে সর্বাধিক সাধারণ

    • বা ব্র্যান্ড নতুন ব্যাকআপ অবস্থান

    • এসকিউএল সার্ভার পরিষেবা ব্যবহারকারী পরিবর্তন করা (যা সাধারণ ব্যাকআপের জন্য অনুমতি প্রয়োজন)

    • এসকিউএল সার্ভার পরিষেবা ব্যবহারকারীর লক আউট করা হচ্ছে কারণ এটি কেবলমাত্র এক এসকিউএল সার্ভার উদাহরণের দ্বারা বেশি ব্যবহৃত হয়

  • কনফিগারেশন ত্রুটি

  • শক্তি ব্যর্থতা

  • ওএস ক্রাশ

যার বেশিরভাগই উপরের শর্তগুলি পূরণ না করে অন্য একটিকে প্রভাবিত করে না।


2

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

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