গিটে কোনও মাইএসকিউএল ডাটাবেস ব্যাক আপ করা কি ভাল ধারণা?


57

আমি আমার অ্যাপ্লিকেশনটির ব্যাকআপ পরিস্থিতি উন্নত করার চেষ্টা করছি। আমার কাছে জ্যাঙ্গো অ্যাপ্লিকেশন এবং মাইএসকিউএল ডাটাবেস রয়েছে। আমি গিটে ডাটাবেস ব্যাক আপ করার পরামর্শ দিয়ে একটি নিবন্ধ পড়েছি।

একদিকে আমি এটি পছন্দ করি কারণ এটি ডেটা এবং কোডের একটি অনুলিপি সিঙ্কে রাখবে।

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

(ডাম্প ফাইলটি বর্তমানে 100 এমবি সঙ্কুচিত, যখন বিজিপ করা হয় তখন 5.7 এমবি))

সম্পাদনা করুন: কোড এবং ডাটাবেস স্কিমা সংজ্ঞাগুলি ইতিমধ্যে গিতে রয়েছে, এটি এখনই ব্যাক আপ করার বিষয়ে আমি উদ্বিগ্ন ডেটা।


13
যদি আপনার সংস্থার আইটি (অপ্স) বিভাগ থাকে তবে তাদের উচিত এটি পরিচালনা করা।
মাইকেল হ্যাম্পটন

1
অ্যাপ্লিকেশন এর ডেটা অংশ, বা অ্যাপ্লিকেশন মাধ্যমে তৈরি করা হয়?
উইনস্টন ইওয়ার্ট

1
গিটটি যখন আপনি চালাবেন তখন সমস্ত ফাইলগুলিকে git gcআলাদা করার চেষ্টা করবে (বা এটি অন্তর্নিহিত git repack; গিটটি কনফিগারযোগ্য ডিফল্ট দ্বারা মাঝে মাঝে এটি স্বয়ংক্রিয়ভাবে চালিত হবে)। এটি সর্বদা তাদের অপসারণ করবে , তাই এগুলিকে সঙ্কুচিত না রেখে সংরক্ষণ করা ভাল।
জান হুডেক

1
এটি কোন ধরণের ডাটাবেস: এটি উত্পাদন বা বিকাশ ডাটাবেস?
el.pescado

6
viget.com/extend/backup- আপনার- ডেটাবেস- ইন- গীত , তিনি একজন "সিনিয়র বিকাশকারী"।
wobbily_col

উত্তর:


101

আপনি কোনও ডেটা হারানোর আগে আমাকে এই প্রশ্নের একটি সিসাদমিন দৃষ্টিভঙ্গি প্রবর্তন করার চেষ্টা করা যাক।

আমরা ব্যাকআপগুলি তৈরি করার একটি মাত্র কারণ রয়েছে: যখন কোনও সমস্যা ঘটে তখন পুনরুদ্ধার করা সম্ভব হয়, যেমন এটি অবিচ্ছিন্নভাবে ঘটবে। এই হিসাবে, একটি যথাযথ ব্যাকআপ সিস্টেমে প্রয়োজনীয়তা থাকে যা গিটটি যথাযথভাবে পরিচালনা করতে পারে তার চেয়ে অনেক বেশি go

গিটে আপনার ডাটাবেসটিকে ব্যাকআপ করার চেষ্টা করার সাথে আমি আগে থেকেই যে বিষয়গুলি দেখতে পাচ্ছিলাম তা এখানে রয়েছে:

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

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


এটিই সেরা উত্তর হ'ল মাইকেল ধারাবাহিকতার বিষয়গুলি coveredেকে রেখেছে। ডাটাবেসের আকার এবং ব্যবহারের উপর নির্ভর করে একটি স্ন্যাপশট নির্ভরযোগ্যভাবে সময় নির্দিষ্টভাবে ডেটা পুনরুত্পাদন করতে পারে না এবং আপনি সীমাবদ্ধতার সমস্যাতে চলে আসার সম্ভাবনা রয়েছে। প্রতিলিপি এমন কিছু হতে পারে যা আপনি দেখতে চান - dev.mysql.com/doc/refman/5.0/en/replication.html
অ্যারন নিউটন

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

2
@JimmyShelter আছে চিন্তার একটা স্কুল DevOps মানে না যে দেব এবং অপস ঘনিষ্ঠভাবে একসাথে কাজ, কিন্তু যে দেব আসলে আছে অপস। এটি সাধারণত ভাল কাজ করে না, তবে এটি লোকেদের চেষ্টা করে থামায় না।
মাইকেল হ্যাম্পটন

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

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

39

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

আমি ধরে নিই যে আপনি এই সম্পর্কে কেন চিন্তা করছেন তার মূল কারণটি হ'ল "ডেটা এবং কোডটির একটি অনুলিপি সিঙ্কে রাখা", এবং এর অর্থ আপনি চিন্তিত যে আপনার কোডের ২.০ সংস্করণটির সংস্করণ ১.০ এর চেয়ে আলাদা ডাটাবেস স্কিমা দরকার । একটি সহজ সমাধান হ'ল ডেটাবেস স্কিমা, CREATEস্টেটমেন্ট সহ এসকিউএল স্ক্রিপ্টগুলির সেট হিসাবে আপনার গিট সংগ্রহস্থলের উত্স কোড সহ store তারপরে, আপনার ইনস্টলেশন পদ্ধতির একটি অংশ হ'ল পূর্বে ইনস্টল করা ডাটাবেস সার্ভারে সেই স্ক্রিপ্টগুলি কার্যকর করা।

এইমাত্র সুনির্দিষ্ট-টেবিলগুলির আসল সামগ্রীগুলিরCREATE আপনার উত্স কোডের সংস্করণটির সাথে কোনও সম্পর্ক নেই। কল্পনা করুন যে আপনি নিজের সফ্টওয়্যার, সংস্করণ 1.0, সার্ভার এ এবং সার্ভার বি তে ইনস্টল করেছেন, যা বিভিন্ন টিম দ্বারা বিভিন্ন সংস্থায় ব্যবহৃত হয়। কিছু সপ্তাহ পরে, টেবিলের বিষয়বস্তু খুব আলাদা হবে, যদিও স্কিমাগুলি একই রকম।

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

সম্পাদনা :

প্রশ্নটি উত্সাহিত মূল পোস্টটি পড়ার পরে , আমি এটি আরও সন্দেহজনক ধারণা পেয়েছি find মূল বিষয়টি হ'ল mysqldumpকমান্ডটি ডিবি-র বর্তমান অবস্থাকে এসকিউএল INSERTস্টেটমেন্টের একটি সিরিজে রূপান্তরিত করে এবং কেবলমাত্র আপডেট হওয়া সারণী সারিগুলি পেতে জিআইটি তাদের আলাদা করতে পারে।

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


2
আমি নিশ্চিত নই যে আমি সংস্করণ নিয়ন্ত্রণে ডেটা ছাড়াই ডাটাবেস স্কিমা সংরক্ষণ করার কোনও পয়েন্ট দেখতে পাচ্ছি। ডেটা সর্বাধিক গুরুত্বপূর্ণ জিনিস এবং এটিই আমি ব্যাক আপ নিতে চাই। আমি তবে বর্তমান সফ্টওয়্যার সংস্করণ দিয়ে ডাটাবেস ব্যাকআপ ট্যাগ করার ধারণাটি পছন্দ করি। আমি এরকম কিছু বাস্তবায়নের চেষ্টা করব।
wobbily_col 26'14

10
ডেটা ছাড়াই স্কিমা সংরক্ষণ করার বিষয়টি হ'ল, ইনস্টলেশন করার ঠিক পরে, আপনার সফ্টওয়্যারটি "ব্যবহারের জন্য প্রস্তুত" হওয়া উচিত। এটি যদি উইকি হয় তবে উইকি পৃষ্ঠাগুলি তৈরি করা এবং সেগুলিতে কিছু লেখা শুরু করা উচিত। যদি আপনি স্কিমা এবং সামগ্রীগুলি ইনস্টল করেন তবে আপনার উইকিটি ইন্সটল হওয়ার পরে এক্স উইকি পৃষ্ঠাগুলিতে ইতিমধ্যে পূর্ণ হয়ে গেছে ... এটি হ'ল "আমাদের বিষয়বস্তু লেখার জন্য উইকি সিস্টেম ইনস্টল করা" নয়, "কোথাও একটি উইকি এটি পড়ার জন্য অনুলিপি করা" ।
লগ

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

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

3
@ রাদুমার্জিয়া: আমি মনে করি এটি নীতি সম্পর্কিত প্রশ্ন is একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থা উত্স কোড পরিচালনা করার জন্য ডিজাইন করা হয়েছে, এবং বাইনারি নয়, এগুলিই। এটি আকারের প্রশ্ন নয়। না, ডাটাবেস ডাম্পগুলি সংগ্রহস্থলের মধ্যে চেক ইন করা উচিত নয়, যেমন প্রশিক্ষণ ভিডিওগুলিতেও চেক করা উচিত নয়। তবে কেউ আপনাকে তা করতে বাধা দিচ্ছে না। :)
লগ

7

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

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

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

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


সম্ভবত ডাউনভাইটারটি ব্যাখ্যা করবে যে সে কেন তাকে নিম্নচাপ দিয়েছিল ..
আলবার্তো সোলানো

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

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

আমি মনে করি বেশিরভাগ ব্যবহারকারীরা প্রথম কয়েকটি বাক্য এবং ডাউনভোট পড়েন, কারণ মনে হয় আপনি এটির ব্যবহার ঠিক করেছেন।

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

1

গিটে আপনার বাইনারি ডেটা সংরক্ষণ করা উচিত নয় - বিশেষত ডাটাবেস।
কোড পরিবর্তন এবং ডাটাবেস ডিএমএল পরিবর্তনগুলি সম্পূর্ণ আলাদা জিনিস।

মাইএসকিউএল এবং ওরাকল সময়মত যে কোনও পয়েন্টে পুনরুদ্ধার করার উদ্দেশ্যে সংরক্ষণাগার লগগুলি লিখতে পারে। নিরাপদে কোথাও এই লগগুলি ব্যাকআপ করুন এবং আপনি ঠিক থাকবেন।

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


1
মাইএসকিউএল দ্বারা নির্মিত এই "সংরক্ষণাগার লগগুলি" ব্যাক আপ করার জন্য কেন কেউ গিট ব্যবহার করবেন না?
gnat

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

1
ঘোরানো লগগুলিকে কেন বিরক্ত করবেন, যদি আপনি সমস্ত কিছুর অনুলিপি রাখতে চান? পাশাপাশি কেবল একটি দৈত্য লগ ফাইল রাখুন।
wobbily_col
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.