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"

השוו את הכתובת הזו למאזין שהגדרתם. אי-התאמה פירושה מאזין שני או שם שמתפענח במקום לא צפוי, ושניהם שווים ידיעה לפני שהאתחול הבא יבחן את התיקון שלכם במקומכם. לאחר מכן אתחלו את המארח בלי משתמש מחובר ואמתו שהכריכה מצליחה. הבדיקה האחת הזו היא ההבדל בין מאזין מתוקן לבין מעקף שנכשל בליל העדכונים הבא.