Đọc một dòng nhật ký SQL Server về liên kết thất bại trong khi dịch vụ vẫn đang chạy, và bạn đã tìm ra phụ thuộc vào thứ tự khởi động chứ không phải sự cố. Chính sự kết hợp đó là manh mối: công cụ khởi động trước khi địa chỉ mà nó được lệnh lắng nghe tồn tại trên máy. Bộ điều hợp VPN xuất hiện sau khi đăng nhập là điều kiện tiên quyết tồi cho dịch vụ cơ sở dữ liệu không có người giám sát, nên hãy theo dõi lỗi theo thứ tự mà công cụ nhìn thấy.

Bắt đầu từ nhật ký khởi động, không phải từ máy khách

Mở nhật ký lỗi của phiên bản và đọc các mục quanh quá trình khởi tạo mạng, không chỉ dòng cuối. Công cụ báo cáo những địa chỉ nào đã thử và giao thức nào đã bật, và bản ghi đó có từ trước khi bất kỳ máy khách nào kết nối. Bây giờ hãy xem hiện tại có gì trên máy chủ. Nếu giao diện sở hữu địa chỉ đã cấu hình chỉ xuất hiện sau khi người dùng đăng nhập và khởi chạy máy khách, thì địa chỉ đã vắng mặt lúc khởi động và lỗi liên kết được giải thích đầy đủ.

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

Điều chỉnh đường dẫn phiên bản theo bản cài đặt của bạn, và đọc danh sách giao diện trước khi kết luận. Một địa chỉ tồn tại nhưng thuộc bộ điều hợp sai là vấn đề khác với địa chỉ chưa tồn tại.

Đi theo thứ tự liên kết mà công cụ thực sự tuân theo

Công cụ đọc cấu hình trình lắng nghe rồi yêu cầu hệ điều hành liên kết. Nếu địa chỉ không phải cục bộ vào lúc đó, liên kết cho địa chỉ đó thất bại trong khi phần còn lại của phiên bản có thể tiếp tục bình thường. Đó là lý do các giao thức hoặc địa chỉ khác vẫn có thể hoạt động, và đó là lý do „SQL Server bị sập“ là bản tóm tắt sai. Giữ nguyên điểm cuối chính xác từ nhật ký: địa chỉ, cổng và giao thức, vì cách sửa phụ thuộc vào việc cái nào trong ba cái sai.

Khởi động lại dịch vụ sau khi bộ điều hợp xuất hiện thường sẽ làm trình lắng nghe thành công, và đó chính là cái bẫy. Nó chứng minh sự phụ thuộc thay vì loại bỏ nó, và cắt mọi người dùng đang kết nối mỗi khi đường hầm kết nối lại.

Đọc trình lắng nghe như cách công cụ đọc nó

Trong SQL Server Configuration Manager, mở thuộc tính TCP/IP của phiên bản và để ý cài đặt Listen All trước khi chỉnh sửa từng địa chỉ. Khi Listen All là Yes, các giá trị Enabled theo từng địa chỉ bị bỏ qua, nên chỉnh sửa chúng không thay đổi gì mà trình lắng nghe sử dụng. Ghi lại ba điều theo thứ tự: địa chỉ bạn định phục vụ, cổng, và liệu trình lắng nghe có bao phủ mọi địa chỉ hay chỉ một. Sau đó áp dụng thay đổi qua quy trình khởi động lại được hỗ trợ và đọc nhật ký khởi động tiếp theo để xác nhận công cụ đã liên kết đúng như bạn yêu cầu.

Lắng nghe trên mọi địa chỉ không phải là kiểm soát truy cập. Nếu thực sự cần một trình lắng nghe rộng, mỗi giao diện có thể tiếp cận cần quyết định riêng về tường lửa và ủy quyền cơ sở dữ liệu, kể cả bất kỳ giao diện nào hướng ra internet.

Cấp cho máy khách một đích đến ổn định

Máy khách không cần máy chủ cơ sở dữ liệu mang địa chỉ từ nhóm. Thiết kế định tuyến hoạt động khi máy chủ lắng nghe trên địa chỉ riêng ổn định của nó trong khi cổng VPN chuyển tiếp lưu lượng của máy khách đến nó và mang phản hồi trở lại.

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

Nếu máy khách đến được 10.80.0.15, đường đi đã được chứng minh và cơ sở dữ liệu chỉ cần ủy quyền cho máy khách đó. Nếu không, hãy sửa định tuyến và DNS trước khi chạm lại vào trình lắng nghe, vì sự cố liên kết trên máy chủ chưa bao giờ là lý do máy khách không tìm thấy nó. Thêm một địa chỉ nhóm giả vào máy chủ, hoặc một cổng mặc định thứ hai để làm hài lòng trình lắng nghe, tạo ra vấn đề mạng mới chồng lên vấn đề cũ. Giữ địa chỉ máy chủ tĩnh và để đường hầm đưa máy khách đến với nó.

Xác minh điểm cuối mà máy khách đã dùng

Kết thúc bằng kiểm tra ở mức ứng dụng thay vì kiểm tra cổng. Kết nối từ máy khách bằng tài khoản mà ứng dụng sử dụng và đọc chi tiết kết nối phía máy chủ, cho thấy địa chỉ cục bộ mà phiên của bạn đã hạ cánh.

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"

So sánh địa chỉ đó với trình lắng nghe bạn đã cấu hình. Sự không khớp nghĩa là có trình lắng nghe thứ hai hoặc một tên được phân giải ở nơi không mong đợi, và cả hai điều đáng biết trước khi lần khởi động lại tiếp theo kiểm tra bản sửa của bạn thay bạn. Sau đó khởi động lại máy chủ mà không có người dùng đăng nhập và xác nhận liên kết thành công. Chính bài kiểm tra duy nhất đó là khác biệt giữa một trình lắng nghe đã sửa và một giải pháp tạm thời thất bại trong đêm vá lỗi tiếp theo.

Bài viết liên quan