প্রথমে নতুন সার্ভার প্রস্তুত ও পরীক্ষা করুন, অ্যাপ্লিকেশন-সমর্থিত সামঞ্জস্য পদ্ধতিতে ডেটা কপি করুন, একটি কাটওভার উইন্ডো নির্ধারণ করুন এবং পুরনো পরিবেশ সংরক্ষণ করুন। রোলব্যাকে নতুন সার্ভারে গৃহীত লেখা হিসাব করতে হবে, শুধু DNS পরিবর্তন নয়।
মেশিন স্থানান্তরের আগে সেবার ইনভেন্টরি করুন
একটি মাইগ্রেশনে অ্যাপ্লিকেশন ফাইলের চেয়ে বেশি কিছু থাকে। ডেটাবেস, আপলোড, নির্ধারিত কাজ, কিউ ওয়ার্কার, সার্টিফিকেট, ডোমেইন, সিক্রেট এবং আউটবাউন্ড ইন্টিগ্রেশন তালিকাভুক্ত করুন। সফটওয়্যার সংস্করণ এবং গুরুত্বপূর্ণ অপারেটিং অনুমান, যেমন ফাইল পারমিশন ও স্টোরেজ পাথ রেকর্ড করুন। একটি নতুন ডেডিকেটেড সার্ভার বছরের পর বছর আগে পুরনো পরিবেশে চুপচাপ ইনস্টল করা একটি ভুলে যাওয়া নির্ভরতা প্রকাশ করতে পারে।
কাটওভার সিদ্ধান্তের জন্য একজন মালিক নির্ধারণ করুন এবং সফলতা কেমন দেখাবে তা নির্ধারণ করুন। ব্যবহারকারী-দৃশ্যমান চেক, ডেটা সামঞ্জস্য এবং অ্যাক্সেস পুনরুদ্ধারের ক্ষমতা অন্তর্ভুক্ত করুন। মাইগ্রেশনের তারিখ ঘোষণার আগে নিশ্চিত করুন যে নতুন কনফিগারেশন সরবরাহ ও ব্যবহারযোগ্য। একটি অর্ডার নিশ্চিতকরণ বা তালিকাভুক্ত হার্ডওয়্যার স্পেসিফিকেশন প্রোডাকশন ডেটা গ্রহণের জন্য প্রস্তুত কার্যকর গন্তব্যের সমান নয়।
গন্তব্যকে আলাদা পরিবেশ হিসেবে তৈরি করুন
প্রয়োজনীয় স্ট্যাক ইনস্টল করুন, প্রশাসন প্রতিষ্ঠা করুন এবং উদ্দিষ্ট ফায়ারওয়াল কনফিগার করুন। সিক্রেট গোপন রাখুন এবং সেবার অনুমতি সচেতনভাবে সেট করুন। পাবলিক ট্রাফিক সরানোর আগে অ্যাপ্লিকেশনের প্রত্যাশিত হোস্টনেম ও সার্টিফিকেট আচরণ যাচাই করুন। Apache-এর ভার্চুয়াল-হোস্ট ডকুমেন্টেশন দেখায় কেন হোস্টনেম রাউটিং সার্ভারের ঠিকানা থেকে আলাদা কনফিগারেশন সিদ্ধান্ত। একটি কার্যকর ডিফল্ট পেজ প্রমাণ করে না যে সঠিক অ্যাপ্লিকেশন হোস্ট কনফিগার করা হয়েছে।
মহড়ার জন্য প্রতিনিধিত্বমূলক পুনরুদ্ধার করা ডেটাসেট ব্যবহার করুন, আউটগোয়িং ইমেইল, পেমেন্ট এবং নির্ধারিত কাজ নিষ্ক্রিয় বা নিরাপদ পরীক্ষা সিস্টেমে পুনঃনির্দেশিত রেখে। এটি পরীক্ষা পরিবেশকে প্রকৃত ব্যবহারকারীদের উপর কাজ করা থেকে বিরত রাখে। লগইন, আপলোড, ব্যাকগ্রাউন্ড কাজ এবং পুনরুদ্ধার অনুশীলন করুন। পদ্ধতি ও তার সময়কাল রেকর্ড করুন যাতে প্রকৃত উইন্ডো আশাবাদের বদলে পর্যবেক্ষিত প্রক্রিয়ার উপর ভিত্তি করে হয়।
একটি সামঞ্জস্যপূর্ণ ডেটা সীমানা বেছে নিন
ডেটাবেস ও অ্যাপ্লিকেশন দ্বারা সমর্থিত ব্যাকআপ বা রেপ্লিকেশন পদ্ধতি ব্যবহার করুন। PostgreSQL SQL ডাম্প, ফাইল-সিস্টেম ব্যাকআপ এবং ধারাবাহিক আর্কাইভিং আলাদা করে, প্রতিটির নিজস্ব অনুমান আছে। এর ডাম্প নির্দেশনা উল্লেখ করে যে ডেটাবেস ডাম্প অভ্যন্তরীণভাবে সামঞ্জস্যপূর্ণ হতে পারে যখন ক্লাস্টার-ব্যাপী রোল ও অন্যান্য বিবরণ আলাদাভাবে পরিচালনা করতে হয়। আপনি যে সিস্টেম চালান তার সঠিক প্রয়োজনীয়তা পড়ুন, খোলা ডেটা ফাইল indiscriminately কপি করার পরিবর্তে।
ডেটাবেস আপলোড ও কিউ অবস্থার সাথে কীভাবে সম্পর্কিত তা পরিকল্পনা করুন। যদি একটি রেকর্ড ভিন্ন সময়ে কপি করা ফাইলের দিকে ইঙ্গিত করে, পুনরুদ্ধার করা অ্যাপ্লিকেশন অসম্পূর্ণ হতে পারে যদিও উভয় কপি আলাদাভাবে সফল হয়েছে। লেখা সংক্ষেপে থামাবেন, পরীক্ষিত রেপ্লিকেশন ব্যবস্থা ব্যবহার করবেন বা অ্যাপ্লিকেশন-নির্দিষ্ট এক্সপোর্ট করবেন তা নির্ধারণ করুন। রানবুকে সেই সামঞ্জস্য সিদ্ধান্ত স্পষ্ট রাখুন।
| পর্যায় | প্রয়োজনীয় প্রমাণ | সিদ্ধান্ত |
|---|---|---|
| মহড়া | অ্যাপ্লিকেশন ও পুনরুদ্ধার করা ডেটা চেক পাস করে | গন্তব্য কাটওভারের জন্য বিবেচনা করা যেতে পারে |
| চূড়ান্ত সমন্বয় | নির্ধারিত সামঞ্জস্যপূর্ণ রিকভারি পয়েন্ট | বোঝা অবশিষ্ট পরিবর্তন নিয়ে এগিয়ে যান |
| ট্রাফিক সুইচ | সঠিক রাউটিং ও সার্টিফিকেট আচরণ | উভয় গন্তব্য মনিটর করুন |
| রোলব্যাক | সমস্ত নতুন গৃহীত লেখার অবস্থান | ট্রাফিক ফেরানোর আগে ডেটা সমন্বয় করুন |
তাৎক্ষণিক পরিবর্তনের প্রতিশ্রুতি ছাড়া ট্রাফিক রাউটিং প্রস্তুত করুন
DNS টাইম-টু-লাইভ নিয়ন্ত্রণ করে রেকর্ড কতক্ষণ ক্যাশে থাকতে পারে, যেমন Cloudflare-এর DNS ডকুমেন্টেশনে ব্যাখ্যা করা হয়েছে। মাইগ্রেশনের অংশ হলে DNS আগে থেকেই TTL পর্যালোচনা করুন, এবং বিদ্যমান ক্যাশে করা রেকর্ড তাদের পূর্ববর্তী সেটিংয়ে পুরনো হতে দিন। কাটওভারের মুহূর্তে মান পরিবর্তন করলে প্রতিটি ক্যাশে করা উত্তর পিছিয়ে সংক্ষিপ্ত করা যায় না। পরিবর্তনের সময় বিভিন্ন ক্লায়েন্ট বিভিন্ন গন্তব্যে পৌঁছাতে পারে।
রাউটিং পরিবর্তন স্থির হওয়ার সময় পুরনো পরিবেশ উপলব্ধ রাখুন, এটি এখনও লেখা গ্রহণ করতে পারে কিনা তার জন্য একটি সচেতন নীতি সহ। অ্যাপ্লিকেশন এটির জন্য ডিজাইন করা না থাকলে ডুপ্লিকেট কিউ কনজিউমার বা নির্ধারিত কাজ চালানো এড়িয়ে চলুন। উভয় দিকে অনুরোধ মনিটর করুন এবং স্বাধীন ক্লায়েন্ট থেকে উদ্দিষ্ট হোস্টনেম, TLS সার্টিফিকেট ও অ্যাপ্লিকেশন সংস্করণ নিশ্চিত করুন।
লেখা শুরু হওয়ার পরে রোলব্যাক নির্ধারণ করুন
নতুন সিস্টেম পরিবর্তন গ্রহণ করার আগে ট্রাফিক ফেরানো তুলনামূলকভাবে সহজ হতে পারে। এর পরে, শুধু একটি DNS বিপরীতকরণ কাজ হারাতে পারে বা দুটি পরস্পরবিরোধী ইতিহাস তৈরি করতে পারে। নতুন তৈরি রেকর্ড ও আপলোড কীভাবে সংরক্ষণ বা সমন্বয় করা হবে তা নির্ধারণ করুন। অ্যাপ্লিকেশন নিরাপদে সেগুলি একত্রিত করতে না পারলে, পুরনো কপিতে তাৎক্ষণিক ফেরার চেয়ে নিয়ন্ত্রিত রক্ষণাবেক্ষণ সময় preferable হতে পারে।
মাইগ্রেশন বিরতি দেওয়ার প্রয়োজনীয় শর্ত নির্ধারণ করুন, এবং সিদ্ধান্তের মালিককে পৌঁছানোর যোগ্য রাখুন। প্রকল্পের ধারণ নিয়মের অধীনে লগ ও উপযোগী প্রমাণ সংরক্ষণ করুন। শুধু হোম পেজ একবার লোড হয়েছে বলে পুরনো মেশিন বা তার স্বাধীন রিকভারি কপি মুছবেন না। ধারণ সময় সম্মত যাচাই ও রোলব্যাক প্রয়োজন কভার করা উচিত।
অপারেশনাল চেক দিয়ে মাইগ্রেশন শেষ করুন
কাটওভারের পরে ব্যাকআপ, সতর্কতা, সার্টিফিকেট নবায়ন, নির্ধারিত কাজ এবং অ্যাক্সেস পুনরুদ্ধার যাচাই করুন। মনিটর করা হোস্ট নতুন গন্তব্য এবং প্রোডাকশনে কোনো পরীক্ষা ইন্টিগ্রেশন নেই তা নিশ্চিত করুন। সাধারণ ট্রাফিকে অ্যাপ্লিকেশন ত্রুটি ও ব্যবহারকারী-দৃশ্যমান সময় পর্যালোচনা করুন। ইনভেন্টরি ও রানবুক আপডেট করুন যাতে পরবর্তী প্রশাসক কী পরিবর্তন হয়েছে তা অনুমান করতে না হয়।
SwissOctet-এর ডেডিকেটেড পরিবারগুলি বিভিন্ন ভৌত কনফিগারেশন দেয়, তবে মাইগ্রেশন কাজ ও পরিচালিত সহায়তা নির্বাচিত সেবার জন্য নিশ্চিত করতে হবে। উপযুক্ত রিসোর্স নির্বাচনের জন্য ক্যাটালগ ব্যবহার করুন, তারপর আপনার অ্যাপ্লিকেশনের ডেটা ঘিরে একটি পরীক্ষিত স্থানান্তর তৈরি করুন। মাইগ্রেশন সম্পূর্ণ হয় যখন সেবা ও তার রিকভারি প্রক্রিয়া গন্তব্যে কাজ করে, শুধু ফাইল স্থানান্তর হয়েছে বলে নয়।
আপনার ব্যবহারিক চেকলিস্ট।
- ডেটা, কাজ, সিক্রেট ও ইন্টিগ্রেশনের ইনভেন্টরি করুন।
- সময়সূচি নির্ধারণের আগে সরবরাহ করা গন্তব্য যাচাই করুন।
- নিরাপদ বাহ্যিক ইন্টিগ্রেশন দিয়ে মহড়া দিন।
- ডেটাবেস ও আপলোড সামঞ্জস্য নির্ধারণ করুন।
- রাউটিং পরিবর্তন ও ডুপ্লিকেট-কাজ প্রতিরোধ পরিকল্পনা করুন।
- নতুন লেখার জন্য রোলব্যাক নির্দিষ্ট করুন।
- কাটওভারের পরে ব্যাকআপ ও মনিটরিং যাচাই করুন।
যে বিবরণগুলো গুরুত্বপূর্ণ।
অ্যাপ্লিকেশন ডিরেক্টরি কপি করে মাইগ্রেট করতে পারি?+
শুধু যদি তা সেবার প্রয়োজনীয় সবকিছু ধারণ করে এবং সামঞ্জস্য বজায় রাখে। ডেটাবেস, আপলোড, কাজ, সিক্রেট ও কনফিগারেশনের সাধারণত আলাদা মনোযোগ প্রয়োজন।
DNS TTL কমানো কি কাটওভার তাৎক্ষণিক করে?+
না। আগে ক্যাশে করা উত্তর তাদের পূর্ববর্তী জীবনকাল শেষ হওয়া পর্যন্ত থাকতে পারে, এবং ক্লায়েন্টরা বিভিন্ন সময়ে আপডেট হতে পারে।
রোলব্যাক কি শুধু DNS পুরনো সার্ভারে নির্দেশ করা?+
নতুন সার্ভার লেখা গ্রহণ করার পরে নয়। ট্রাফিক ফেরানোর আগে সেই রেকর্ড ও ফাইল হিসাব করতে হবে।
সূত্রে যান।
এই রেফারেন্সগুলি এই গাইডের প্রযুক্তিগত ধারণাগুলি সমর্থন করে। একটি উৎপাদন সিস্টেম পরিবর্তন করার আগে বর্তমান ডকুমেন্টেশন অনুসরণ করুন।
- PostgreSQL: ব্যাকআপ এবং পুনরুদ্ধার www.postgresql.org
- PostgreSQL: SQL ডাম্প সামঞ্জস্য ও পুনরুদ্ধার www.postgresql.org
- Apache: ভার্চুয়াল হোস্ট ডকুমেন্টেশন httpd.apache.org
- Cloudflare DNS: টাইম টু লাইভ developers.cloudflare.com
SwissOctet দ্বারা সম্পাদকীয় নির্দেশনা। উদাহরণগুলি উদাহরণমূলক। সেবা স্পেসিফিকেশন, উপলব্ধ অপশন এবং চুক্তিভিত্তিক শর্তগুলি আলাদাভাবে যাচাই করতে হবে।