কেন আপনার সিঙ্ক্রোনাস SQL কমিট VPN রাউন্ড ট্রিপের জন্য অপেক্ষা করে

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

প্রাথমিকটি আসলে কীসের জন্য অপেক্ষা করে

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

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

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

ব্যান্ডউইথ রাউন্ড-ট্রিপ বিলম্ব নয়

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

তাই একটি «দ্রুত» টানেল অনেক ছোট অনুক্রমিক লেনদেনে গড়া লেখা-ভারী কাজের চাপে দৃশ্যমান জরিমানা যোগ করতে পারে। একই মোট বাইট হাজার কমিটে ভাগ হলে রাউন্ড ট্রিপের দাম দেয় হাজার বার; একটি বাল্ক স্থানান্তর তা দেয় একবার।

প্রতিনিধিত্বমূলক লোডের অধীনে রেপ্লিকা রুটের উপরেই বিলম্ব ও ক্ষতি মাপতে নেটওয়ার্ক মালিককে বলুন। অফিসের ল্যাপটপ থেকে VPN গেটওয়েতে পিং, বা কাছের নোডে স্পিড টেস্ট, লগ যে পথে সত্যিই যায় তাতে প্রায় কিছুই আরোপ করে না। মাপার সময়সীমা যেন ধীর লেখার ঘণ্টাগুলোর সঙ্গে মিলে যায় তা নিশ্চিত করুন।

কিছু বদলানোর আগে রেপ্লিকার অবস্থা পড়ুন

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

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

প্রথম ফলাফল লগ পরিবহনকে রিডু থেকে আলাদা করে। log_send_queue_size বাড়ছে আর redo_queue_size সমান থাকছে মানে লগ পৌঁছায়নি; উল্টোটা মানে এটি পৌঁছেছে আর রিপ্লে পিছিয়ে আছে। শুধু প্রথম ক্ষেত্রেই কমিটের পথে বসে।

দ্বিতীয় ফলাফল নিশ্চিত করে কোন রেপ্লিকাগুলো সত্যিই আপনার ধারণা অনুযায়ী কনফিগার করা, কারণ আগের কোনো ঘটনার সময় বদলানো মোড প্রায়ই বদলানো ও নথিবিহীন অবস্থায় থেকে যায়। গ্রুপ ডিফল্টের বদলে যে সারিটি আপনার দরকার সেটি পড়ুন: availability_mode_desc এবং failover_mode_desc প্রতি রেপ্লিকায়। secondary_lag_seconds শুধু SQL Server 2016 ও পরবর্তীতে আছে, তাই পুরোনো বিল্ড আপনাকে শুধু সেন্ড ও রিডু সারি কলাম দিয়েই রেখে যায়।

তারপর ড্যাশবোর্ডের গড়ে ভরসা না করে একটি প্রতিনিধিত্বমূলক লেখা মাপুন। নিচের ব্লকটি প্রাপ্যতা ডেটাবেসে চালান, তারপর একই ইনস্ট্যান্সে গ্রুপের বাইরের একটি ডেটাবেসে একই টেবিল আকৃতির বিপরীতে আবার চালান। দুই সময়কালের ফারাক দূরবর্তী লগের মোটামুটি দাম, আর নেটওয়ার্ক দলের সঙ্গে তর্কে এটি গ্রাফের চেয়ে অনেক ভালো টেকে। এরপর একবারে একটি চলক বদলান, নইলে ফারাকের আর অর্থ থাকে না।

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

অ্যাসিঙ্ক্রোনাস কমিট কী দেয়, আর কী নেয়

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

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

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

পরে যা রক্ষা করতে পারবেন এমন সমাধান বেছে নিন

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

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

পরিবর্তন রেকর্ডে আগে-পরে পাঠ সংরক্ষণ করুন। নইলে ধীর লেখা দেখে পরের ব্যক্তি তদন্ত শুরু থেকে পুনরাবৃত্তি করে আবার টানেলকেই দোষ দিয়ে শুরু করে।