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"

त्यो ठेगाना तपाईंले कन्फिगर गरेको श्रोतासँग तुलना गर्नुहोस्। नमिल्दो भनेको दोस्रो श्रोता वा अप्रत्याशित ठाउँमा समाधान हुने नाम हो, र अर्को रिबुटले तपाईंको तर्फबाट तपाईंको सुधार परीक्षण गर्नुअघि दुवै जान्न लायक छ। त्यसपछि कुनै प्रयोगकर्ता साइन-इन नगरी होस्ट रिबुट गर्नुहोस् र बाइन्ड सफल भएको पुष्टि गर्नुहोस्। त्यही एक परीक्षण मर्मत गरिएको श्रोता र अर्को प्याच रातमा असफल हुने अस्थायी उपायबीचको फरक हो।