Oracle Data Guard Switchover ও Failover: একটি প্রোডাকশন রোল-ট্রানজিশন রানবুক

একটি standby ডেটাবেজ থাকা আর চাপের মুহূর্তে সেটি কীভাবে ব্যবহার করতে হয় তা জানা - এক জিনিস নয়। যে মুহূর্তে আপনার primary বিপদে পড়ে - কিংবা পরিকল্পিত রক্ষণাবেক্ষণের জন্য তা সরাতে হয় - সেটি কমান্ড খুঁজে বেড়ানোর সময় নয়। এটিই সেই রানবুক: পরিকল্পিত switchover আর জরুরি failover-এর স্পষ্ট পার্থক্য, যে প্রি-চেকগুলো একটি রোল-ট্রানজিশন ভুল হওয়া ঠেকায়, প্রতিটির জন্য নির্ভুল DGMGRL ধাপ, পরে পুরনো primary কীভাবে ফিরিয়ে আনতে হয়, আর Fast-Start Failover কীভাবে পুরো ব্যাপারটি স্বয়ংক্রিয় করে। ধরে নেওয়া হচ্ছে আপনার ইতিমধ্যেই একটি কার্যকর Data Guard কনফিগারেশন আছে; ধারণাগুলো আগে দরকার হলে সম্পূর্ণ Data Guard গাইড দিয়ে শুরু করুন।

১. Switchover বনাম Failover - কোনটি করছেন জানুন

সংকটের সময় এই দুটি শব্দ পরস্পরের বদলে ব্যবহার হয়, কিন্তু এগুলো খুবই আলাদা অপারেশন, আর গুলিয়ে ফেললে ভুল হয়।

একটি switchover পরিকল্পিত এবং ডেটা-হারানো ছাড়া। primary ও standby পরিচ্ছন্নভাবে রোল বদল করে - পুরনো primary হয় standby, পুরনো standby হয় primary - কোনো ডেটা না হারিয়ে। পরিকল্পিত রক্ষণাবেক্ষণ, হার্ডওয়্যার সরানো, বা আপনার DR প্রস্তুতি টেস্ট করার জন্য এটি ব্যবহার করেন।

একটি failover অপরিকল্পিত। primary চলে গেছে - ক্র্যাশ করেছে, পৌঁছানো যাচ্ছে না, ধ্বংস হয়েছে - আর সেবা ফিরিয়ে আনতে আপনি standby-কে primary-তে প্রমোট করেন। আপনার protection mode এবং কতটা redo standby-তে পৌঁছেছিল তার ওপর নির্ভর করে failover-এ সামান্য পরিমাণ ডেটা হারাতে পারে। পুরনো primary স্বয়ংক্রিয়ভাবে standby হিসেবে ফিরে আসে না; একে reinstate করতে হয়।

২. যেকোনো রোল-ট্রানজিশনের আগে প্রি-চেক

পরিকল্পিত হোক বা না হোক, লাফ দেওয়ার আগে দেখে নিন। Broker এটি দ্রুত করে দেয়।

-- Connect to the broker
dgmgrl sys/password@primary

-- Overall health - everything should be SUCCESS
SHOW CONFIGURATION;

-- Detail on the standby you intend to promote, including apply lag
SHOW DATABASE VERBOSE 'standby_db';

-- Validate that the standby is ready to take the primary role
VALIDATE DATABASE 'standby_db';

VALIDATE DATABASE সেই কমান্ড যা অনেক DBA বাদ দিয়ে যান। এটি জানায় টার্গেট primary হওয়ার জন্য প্রস্তুত কিনা - redo পাওয়া গেছে কিনা, apply স্ট্যাটাস, flashback, এবং যেকোনো সতর্কতা - কমিট করার আগে। switchover-এর জন্য আপনি শূন্য lag চান; failover-এর জন্য যত redo পৌঁছেছে ততই মেনে নেন।

৩. Switchover রানবুক (পরিকল্পিত)

Broker দিয়ে একটি সুস্থ switchover মূলত একটি কমান্ড, তবে আশপাশের ধাপগুলোও গুরুত্বপূর্ণ।

1. নিশ্চিত করুন অ্যাপ্লিকেশনগুলো সংক্ষিপ্ত ট্রানজিশন সহ্য করতে পারে এবং standby lag শূন্য।
2. টার্গেটে VALIDATE DATABASE চালান এবং যেকোনো সতর্কতা সমাধান করুন।
3. switchover সম্পাদন করুন; Broker দুটি ডেটাবেজ সমন্বয় করে।
4. নতুন রোল এবং redo transport উল্টে গেছে কিনা যাচাই করুন।

-- One command; the broker does the rest
SWITCHOVER TO 'standby_db';

-- Afterwards, confirm the swap
SHOW CONFIGURATION;      -- roles are now reversed, status SUCCESS

পুরনো primary স্বয়ংক্রিয়ভাবে standby হয়ে যায় এবং নতুন primary থেকে redo গ্রহণ শুরু করে। switchover-এর জন্য কোনো reinstatement লাগে না - এটি পরিকল্পিত ও পরিচ্ছন্ন হওয়ার পুরো উদ্দেশ্যই তো এটাই।

৪. Failover রানবুক (অপরিকল্পিত)

primary যখন সত্যিই চলে গেছে, তখন আপনি standby-কে প্রমোট করেন। মূল সিদ্ধান্তটি ইতিমধ্যেই আপনার protection mode-এ গাঁথা আছে: Maximum Protection ও Maximum Availability redo standby-তে পৌঁছানো নিশ্চিত করে শূন্য ডেটা-হারানোর লক্ষ্য রাখে, আর Maximum Performance primary-এর গতিকে অগ্রাধিকার দেয় এবং failover-এ শেষ কয়েকটি ট্রানজেকশন হারাতে পারে।

-- Connect the broker to the SURVIVING standby
dgmgrl sys/password@standby_db

-- Promote it to primary
FAILOVER TO 'standby_db';

-- Confirm it is now the primary and open
SHOW CONFIGURATION;

Failover-এর পর অ্যাপ্লিকেশন কানেক্টিভিটি নতুন primary-তে ফিরিয়ে আনুন। আপনি যদি একটি role-aware সার্ভিস এবং সঠিকভাবে কনফিগার করা ক্লায়েন্ট connect string ব্যবহার করেন, সেশনগুলো স্বয়ংক্রিয়ভাবে নতুন primary-তে পুনরায় সংযুক্ত হয়। ঠিক এই ধরনের ঘটনাই আলোচনা করা হয়েছে রাত ৩টায় ডেটাবেজ ফেল করলে কী করবেন লেখায় - রানবুকই আতঙ্ককে পদ্ধতিতে পরিণত করে।

৫. পুরনো Primary পুনরায় যুক্ত করা (Reinstate)

Failover-এর পর ব্যর্থ ডেটাবেজটি - আবার সচল হলে - নতুন primary-এর পেছনে পড়ে থাকে এবং সহজে পুনরায় যুক্ত হতে পারে না। একে standby হিসেবে reinstate করতে হয়। আপনার যদি Flashback Database চালু থাকত (আর থাকা উচিত), Broker একে সঠিক পয়েন্টে flash back করে স্বয়ংক্রিয়ভাবে standby-তে পরিণত করতে পারে।

-- Start the old primary in MOUNT, then from the broker:
REINSTATE DATABASE 'old_primary';

-- It flashes back and becomes a standby of the new primary
SHOW CONFIGURATION;   -- both databases healthy again

এটিই Flashback Database চালু রাখার একটি সুনির্দিষ্ট কারণ: এটি ছাড়া পুরনো primary reinstate করা মানে সাধারণত একটি নতুন কপি দিয়ে standby আবার শূন্য থেকে তৈরি করা, যা অনেক ধীর।

৬. Snapshot Standby - বাস্তব ডেটায় টেস্ট করুন, তারপর ফিরিয়ে নিন

কখনও কখনও আপনি standby-কে read-write খুলতে চান - প্রোডাকশন-সদৃশ ডেটার বিপরীতে একটি পরিবর্তন টেস্ট করতে - কিন্তু DR সুরক্ষা না হারিয়ে। একটি snapshot standby ঠিক তা-ই করে। এটি standby-কে read-write-এ রূপান্তর করে, redo গ্রহণ করতে থাকে (কিন্তু এখনও apply করে না), আর আপনি যখন একে আবার রূপান্তর করেন, তখন আপনার টেস্টের পরিবর্তনগুলো বাতিল করে পিছিয়ে থাকা redo ধরে ফেলে।

-- Open the standby for read-write testing
CONVERT DATABASE 'standby_db' TO SNAPSHOT STANDBY;
-- ... run your tests; changes here are temporary ...

-- Discard changes and resume being a standby
CONVERT DATABASE 'standby_db' TO PHYSICAL STANDBY;

প্রোডাকশন না ছুঁয়ে এবং আলাদা clone না বানিয়ে বাস্তবসম্মত ডেটার বিপরীতে একটি অ্যাপ্লিকেশন রিলিজ বা ঝুঁকিপূর্ণ ডেটা ফিক্স যাচাই করার জন্য এটি অমূল্য।

৭. Fast-Start Failover - জরুরি অবস্থা স্বয়ংক্রিয় করা

ম্যানুয়াল failover একজন মানুষের লক্ষ্য করা ও সাড়া দেওয়ার ওপর নির্ভর করে। Fast-Start Failover (FSFO) সংকটজনক পথ থেকে মানুষকে সরিয়ে দেয়। observer নামের একটি হালকা প্রসেস অবিরাম দুটি ডেটাবেজই পর্যবেক্ষণ করে; primary যদি নির্ধারিত threshold-এর বেশি সময় পৌঁছানো না যায়, observer কয়েক সেকেন্ডের মধ্যে standby-তে স্বয়ংক্রিয় failover ঘটায়, এবং পরে পুরনো primary ফিরে এলে স্বয়ংক্রিয়ভাবে তাকে reinstate করে।

-- Enable Fast-Start Failover and start an observer (on a third host)
EDIT DATABASE 'standby_db' SET PROPERTY FastStartFailoverThreshold = 30;
ENABLE FAST_START FAILOVER;
START OBSERVER;

SHOW FAST_START FAILOVER;   -- confirm enabled + observer present

observer একটি তৃতীয় মেশিনে চালানো উচিত, দুটি ডেটাবেজ থেকেই আলাদা, যাতে সে একটি মৃত primary আর একটি নেটওয়ার্ক স্প্লিটের পার্থক্য বুঝতে পারে। ব্যবসার যখন হাত না লাগিয়ে সেকেন্ড-পর্যায়ের রিকভারি দরকার, FSFO-ই সেই কনফিগারেশন যার লক্ষ্য রাখা উচিত।

৮. সাধারণ সমস্যা ও সেগুলো কীভাবে সামলাবেন

• Switchover একটি সতর্কতা দিয়ে অস্বীকার করছে: প্রায় সবসময়ই apply lag বা একটি ওপেন ব্লকিং সেশন। gap পরিষ্কার করুন এবং VALIDATE DATABASE আবার চালান; একটি বাস্তব সতর্কতা পেরিয়ে জোর করবেন না।
• standby-তে redo gap: অনুপস্থিত archived log মানে standby পিছিয়ে আছে। switchover-এর আগে gap সমাধান করুন (Broker সাধারণত স্বয়ংক্রিয়ভাবে তা নিয়ে আসে)।
• পুরনো primary reinstate হচ্ছে না: Flashback বন্ধ ছিল বা flashback log-গুলো বয়সের কারণে বাদ পড়ে গেছে - আপনাকে একটি নতুন কপি দিয়ে standby আবার তৈরি করতে হবে, যেমন RMAN DUPLICATE দিয়ে।
• অ্যাপ্লিকেশন নতুন primary অনুসরণ করছে না: connect string বা ডেটাবেজ সার্ভিস role-aware ছিল না। একটি Data Guard-aware সার্ভিস ব্যবহার করুন যাতে ট্রানজিশনে সংযোগগুলো স্বয়ংক্রিয়ভাবে সরে যায়।

৯. একটি বাস্তব ট্রানজিশন: একটি ব্যাংক standby-তে পরিচ্ছন্ন DR ড্রিল

একটি ব্যাংকিং ক্লায়েন্টকে অডিটরদের কাছে প্রমাণ করতে হয়েছিল যে তারা তাদের DR সাইটে চলতে পারে - লাইভ সিস্টেমকে ঝুঁকিতে না ফেলে। আমরা একটি শান্ত সময়ে একটি পরিকল্পিত switchover নির্ধারণ করি: শূন্য lag ও একটি পরিচ্ছন্ন standby নিশ্চিত করতে SHOW CONFIGURATION ও VALIDATE DATABASE চালাই, Broker-এর মাধ্যমে DR ডেটাবেজে SWITCHOVER TO সম্পাদন করি, এবং রোল উল্টে গেছে ও redo transport উল্টো দিকে বইছে তা নিশ্চিত করি। role-aware সার্ভিস ব্যবহার করা অ্যাপ্লিকেশনগুলো স্বয়ংক্রিয়ভাবে DR সাইটে পুনরায় সংযুক্ত হয়। ব্যাংক নির্ধারিত সময় ধরে DR-তে চলে, তারপর একইভাবে আবার ফিরে যায়। যেহেতু সবকিছু প্রি-ভ্যালিডেশনসহ Broker-এর মধ্য দিয়ে গিয়েছিল, ড্রিলটি ছিল ঘটনাহীন - যা, একটি DR টেস্টের জন্য, ঠিক সেটাই লক্ষ্য। এই অপারেশনাল শৃঙ্খলা সম্পূর্ণ Data Guard গাইডে আলোচিত ডিজাইন এবং একটি মজবুত ব্যাকআপ ভিত্তির ওপর দাঁড়িয়ে থাকে।

সাধারণ জিজ্ঞাসা (FAQ)

Data Guard switchover ও failover-এর মধ্যে পার্থক্য কী?

Switchover পরিকল্পিত এবং ডেটা-হারানো ছাড়াই - রক্ষণাবেক্ষণ বা DR টেস্টিংয়ের জন্য primary ও standby পরিচ্ছন্নভাবে রোল বদল করে, আর পুরনো primary স্বয়ংক্রিয়ভাবে standby হয়ে যায়। Failover হলো primary চলে গেলে standby-কে জরুরি ভিত্তিতে প্রমোট করা; protection mode অনুযায়ী এতে সামান্য ডেটা হারাতে পারে, আর পুরনো primary-কে পরে reinstate করতে হয়।

কীভাবে একটি Data Guard switchover করব?

Data Guard Broker দিয়ে এটি মূলত একটি কমান্ড। DGMGRL দিয়ে কানেক্ট করুন, SHOW CONFIGURATION ও VALIDATE DATABASE চালিয়ে নিশ্চিত করুন standby শূন্য lag নিয়ে প্রস্তুত, তারপর SWITCHOVER TO 'standby_db' চালান। broker দুটি ডেটাবেজ সমন্বয় করে এবং redo transport উল্টে দেয়; নতুন রোল SHOW CONFIGURATION দিয়ে নিশ্চিত করুন।

Failover-এর পর পুরনো primary কীভাবে ফিরিয়ে আনব?

শুধু রিস্টার্ট নয়, একে reinstate করতে হয়। পুরনো primary-কে MOUNT অবস্থায় স্টার্ট করুন এবং broker থেকে REINSTATE DATABASE চালান। Flashback Database চালু থাকলে broker একে সঠিক পয়েন্টে flash back করে স্বয়ংক্রিয়ভাবে standby-তে রূপান্তর করে। Flashback ছাড়া সাধারণত একটি নতুন কপি থেকে standby আবার তৈরি করতে হয়।

Fast-Start Failover কী?

Fast-Start Failover (FSFO) একটি observer প্রসেস দিয়ে failover স্বয়ংক্রিয় করে যা দুটি ডেটাবেজই পর্যবেক্ষণ করে। নির্দিষ্ট threshold-এর বেশি সময় primary পৌঁছানো না গেলে observer কয়েক সেকেন্ডের মধ্যে standby-তে স্বয়ংক্রিয় failover ঘটায় এবং পুরনো primary ফিরে এলে পরে তাকে reinstate করে। observer একটি তৃতীয় হোস্টে চালানো উচিত যাতে সে মৃত primary ও নেটওয়ার্ক স্প্লিটের পার্থক্য বুঝতে পারে।

Snapshot standby কী কাজে লাগে?

Snapshot standby আপনাকে standby-কে read-write খুলে প্রোডাকশন-সদৃশ ডেটার বিপরীতে টেস্ট করতে দেয়, যখন সে redo গ্রহণ করতে থাকে। আপনি একে snapshot standby-তে রূপান্তর করেন, টেস্ট চালান, তারপর আবার physical standby-তে রূপান্তর করেন, যা টেস্টের পরিবর্তনগুলো বাতিল করে redo apply আবার শুরু করে। প্রোডাকশন না ছুঁয়ে বা আলাদা clone না বানিয়ে একটি রিলিজ যাচাই করার জন্য এটি আদর্শ।