VPN বিচ্ছেদের পর MySQL রেপ্লিকেশন: আগে দুই ধাপই পড়ুন

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

দুই ধাপ, দুইটি আলাদা উত্তর

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

রিসিভারের পুনরুদ্ধার বলে দেয় পথ চালু আছে। এটি বলে না অ্যাপ্লায়ার কত পিছিয়ে, বা সংযোগ বিচ্ছিন্ন থাকার সময় কোনো ত্রুটিতে পড়েছিল কি না।

সঠিক স্টেটমেন্ট দিয়ে চ্যানেল পড়ুন

MySQL 8.4-এ SHOW REPLICA STATUS প্রতিটি কনফিগার করা চ্যানেলের জন্য একটি সারি ফেরত দেয়, তাই তালিকাভুক্ত প্রথম সারির বদলে আপনি যে চ্যানেল চান তার সারি পড়ুন। Replica_IO_Running সংযুক্ত রিসিভারকে সংযোগ-রত বা থেমে যাওয়া রিসিভার থেকে আলাদা করে, আর Replica_SQL_Running অ্যাপ্লায়ারকে বর্ণনা করে। এর পাশাপাশি ত্রুটির কলামগুলো পড়ুন, কারণ যে রিসিভার আবার সংযোগ করে সঙ্গে সঙ্গে ব্যর্থ হয় সে এমন বার্তা রেখে যায় যা কোনো স্টেটাস ফ্ল্যাগ দেখাবে না। পুরোনো সংস্করণে কলামের নাম আলাদা, তাই কেবল কমান্ডের নাম বদলে পুরোনো রেসিপি অনুবাদ করবেন না।

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

শূন্য ল্যাগ সংখ্যা কেন মিথ্যা বলতে পারে

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

বরং সম্পাদিত লেনদেনকে সোর্সের কাছে যা আছে তার সঙ্গে তুলনা করুন। এই তুলনা থেমে যাওয়া রিসিভারেও টিকে থাকে।

প্রকৃত পুনরুদ্ধার সময়সীমা ঠিক করে রিটেনশন

ধরে নিতে হলে সোর্সকে রেপ্লিকার প্রয়োজনীয় লেনদেনগুলো এখনও ধরে রাখতে হবে। সেগুলো মুছে ফেলার পর রেপ্লিকা আর সেগুলো আনতে পারে না, আর কতবার পুনঃসংযোগ করলেও তা বদলায় না।

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

সূচকের রং নয়, ধরে নেওয়াটাই যাচাই করুন

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

নিশ্চিত করুন অ্যাপ্লায়ার সোর্সের বর্তমান অবস্থানে পৌঁছেছে, কেবল পুরোনো ব্যাকলগের শেষে নয়। দেখুন অ্যাপ্লায়ারে কোনো ত্রুটি অপেক্ষা করছে না, কারণ একটি ব্যর্থ ইভেন্ট অগ্রগতি থামায়, অথচ রিসিভার সংযুক্ত থাকার কথা জানাতে থাকে। তারপর প্রমাণ লিপিবদ্ধ করুন: চ্যানেলের নাম, দুই ধাপের অবস্থা, সম্পাদিত অবস্থান এবং সময়। সবুজ সূচক একটি দাবি; অবস্থান একটি তথ্য।