SQL Server বুটের সময় অনুপস্থিত VPN ঠিকানায় বাইন্ড হয়

সার্ভিস চলমান থাকা অবস্থায় ব্যর্থ বাইন্ড সম্পর্কে SQL Server লগের একটি লাইন পড়ুন, আর আপনি ক্র্যাশ নয়, বুট-ক্রমের নির্ভরতা খুঁজে পাবেন। ওই সমন্বয়টাই সূত্র: ইঞ্জিন এমন সময় চালু হয়েছিল যখন যে ঠিকানায় শুনতে বলা হয়েছিল তা মেশিনে ছিল না। সাইন-ইনের পরে ওঠা VPN অ্যাডাপ্টার তদারকিহীন ডেটাবেস সার্ভিসের জন্য দুর্বল পূর্বশর্ত, তাই ইঞ্জিন যেভাবে ব্যর্থতা দেখে সেই ক্রমে এগোন।

ক্লায়েন্ট থেকে নয়, স্টার্টআপ লগ থেকে শুরু করুন

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

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

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

ইঞ্জিন আসলে যে বাইন্ড ক্রম অনুসরণ করে তা ধাপে ধাপে দেখুন

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

অ্যাডাপ্টার আসার পরে সার্ভিস রিস্টার্ট করলে লিসেনার সাধারণত সফল হয়, আর এটাই ঠিক ফাঁদ। এটি নির্ভরতাটি প্রমাণ করে, সরায় না, এবং টানেল প্রতিবার পুনঃসংযুক্ত হলে প্রতিটি সংযুক্ত ব্যবহারকারীকে বিচ্ছিন্ন করে।

ইঞ্জিন যেভাবে পড়ে সেভাবেই লিসেনার পড়ুন

SQL Server Configuration Manager-এ ইন্সট্যান্সের TCP/IP বৈশিষ্ট্য খুলুন এবং আলাদা ঠিকানা সম্পাদনার আগে Listen All সেটিং লক্ষ্য করুন। Listen All যখন Yes, তখন প্রতি-ঠিকানার Enabled মান উপেক্ষিত হয়, তাই সেগুলো সম্পাদনা করলে লিসেনার যা ব্যবহার করে তা বদলায় না। ক্রমানুসারে তিনটি জিনিস লিখুন: যে ঠিকানায় সেবা দিতে চান, পোর্ট, এবং লিসেনার সব ঠিকানা না কেবল একটি কভার করবে। তারপর সমর্থিত রিস্টার্ট প্রক্রিয়ায় পরিবর্তনটি প্রয়োগ করুন এবং পরের স্টার্টআপ লগ পড়ে নিশ্চিত করুন যে ইঞ্জিন আপনার চাওয়া ঠিকানায় বাইন্ড করেছে।

প্রতিটি ঠিকানায় শোনা অ্যাক্সেস নিয়ন্ত্রণ নয়। সত্যিই বিস্তৃত লিসেনার দরকার হলে প্রতিটি পৌঁছানোযোগ্য ইন্টারফেসের নিজস্ব ফায়ারওয়াল ও ডেটাবেস অনুমোদন সিদ্ধান্ত লাগবে, ইন্টারনেটমুখী যেকোনো ইন্টারফেসসহ।

ক্লায়েন্টকে একটি স্থিতিশীল গন্তব্য দিন

ডেটাবেস হোস্টকে পুল ঠিকানা পরতে হবে না। রাউটেড ডিজাইনে সার্ভার তার স্থিতিশীল প্রাইভেট ঠিকানায় শোনে, আর VPN গেটওয়ে ক্লায়েন্টের ট্রাফিক তার কাছে পাঠিয়ে উত্তর ফেরত আনে।

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

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

ক্লায়েন্ট যে এন্ডপয়েন্ট ব্যবহার করেছে তা যাচাই করুন

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

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

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