خطای 35206 SQL Server: حل مشکل قطع اتصال به رپلیکای اصلی Always On
SQL Server Always On Availability Groups (AGs) یکی از قدرتمندترین ویژگی‌های SQL Server برای اطمینان از دسترسی بالا (High Availability) و بازیابی از فاجعه (Disaster Recovery) است. این قابلیت به سازمان‌ها امکان می‌دهد تا چندین کپی از پایگاه‌های داده را در سرورهای مختلف نگهداری کنند، که به آنها “رپلیکا” (Replica) گفته می‌شود. یکی از این رپلیکاها، “رپلیکای اصلی” (Primary Replica) است که تمام عملیات نوشتن روی آن انجام می‌شود و سایر رپلیکاها، “رپلیکاهای ثانویه” (Secondary Replicas) هستند که داده‌ها را از رپلیکای اصلی دریافت کرده و به صورت همزمان یا غیرهمزمان با آن هماهنگ می‌شوند. این همگام‌سازی تضمین می‌کند که در صورت بروز مشکل برای رپلیکای اصلی، یک رپلیکای ثانویه بتواند نقش اصلی را به عهده بگیرد و سرویس‌دهی بدون وقفه یا با حداقل وقفه ادامه یابد.
خطای 35206 SQL Server با توضیحات “Connection to primary replica is not active” یک پیام حیاتی است که نشان می‌دهد ارتباط بین یک رپلیکای ثانویه و رپلیکای اصلی در یک Availability Group قطع شده یا غیرفعال است. این خطا به طور مستقیم بر سلامت Availability Group و قابلیت آن در حفظ دسترسی بالا تأثیر می‌گذارد. هنگامی که این ارتباط قطع می‌شود، رپلیکای ثانویه نمی‌تواند تراکنش‌ها را از رپلیکای اصلی دریافت کرده و همگام‌سازی داده‌ها متوقف می‌شود. این وضعیت می‌تواند منجر به عقب‌ماندگی قابل توجه (data lag) در رپلیکای ثانویه شود و در صورت نیاز به Failover (انتقال نقش اصلی به رپلیکای ثانویه)، ممکن است از دست رفتن داده‌ها (data loss) رخ دهد، به خصوص اگر گروه در حالت همگام‌سازی همزمان (synchronous-commit) پیکربندی شده باشد اما همگام‌سازی متوقف شده باشد. بنابراین، درک علت و روش‌های رفع این خطای SQL Server برای مدیران پایگاه داده (DBAs) که با Always On کار می‌کنند، از اهمیت بالایی برخوردار است. این خطا می‌تواند به دلیل مشکلات مختلفی از جمله مشکلات شبکه، منابع سرور، مسدود شدن تراکنش‌ها یا حتی پیکربندی نادرست Always On رخ دهد.
علل بروز خطای 35206 در SQL Server
خطای 35206 “Connection to primary replica is not active” معمولاً ریشه‌های متعددی دارد که شناسایی دقیق آنها برای عیب‌یابی موفقیت‌آمیز ضروری است. درک این علل به ما کمک می‌کند تا رویکردی ساختاریافته برای رفع این مشکل Availability Group اتخاذ کنیم. برخی از رایج‌ترین دلایل بروز این خطای SQL Server عبارتند از:
* **مشکلات شبکه (Network Issues):** این یکی از شایع‌ترین دلایل است. قطع شدن یا ناپایداری شبکه بین رپلیکای اصلی و رپلیکای ثانویه می‌تواند باعث قطع ارتباط شود. این مشکلات می‌توانند شامل موارد زیر باشند:
* **نوسانات یا قطعی‌های موقت شبکه:** کابل‌های شبکه معیوب، سوئیچ‌های خراب یا مشکلات عمومی زیرساخت شبکه.
* **مسدود شدن پورت فایروال (Firewall Blockage):** پورت TCP/IP که SQL Server برای ارتباطات Always On استفاده می‌کند (معمولاً پورت 5022)، توسط فایروال بین سرورها مسدود شده باشد.
* **تأخیر بالای شبکه (High Network Latency):** حتی اگر ارتباط کاملاً قطع نشود، تأخیر زیاد در شبکه می‌تواند باعث شود که رپلیکای ثانویه نتواند به سرعت کافی داده‌ها را از رپلیکای اصلی دریافت کند و در نهایت منجر به قطع ارتباط شود.
* **اشباع پهنای باند شبکه (Network Bandwidth Saturation):** اگر حجم زیادی از داده‌ها در حال انتقال باشد و پهنای باند شبکه کافی نباشد، ارتباط Always On تحت تأثیر قرار می‌گیرد.
* **فشارهای منابع سرور (Server Resource Exhaustion):**
* **مصرف بالای CPU:** اگر رپلیکای اصلی یا ثانویه با مصرف CPU بسیار بالا مواجه باشد، ممکن است نتواند به درخواست‌های ارتباطی پاسخ دهد.
* **کمبود حافظه (Memory Pressure):** کمبود حافظه RAM می‌تواند باعث عملکرد کند SQL Server و عدم توانایی در مدیریت ارتباطات شود.
* **مشکلات دیسک I/O:** کندی دیسک‌ها یا حجم بالای عملیات ورودی/خروجی (I/O) بر روی رپلیکای اصلی یا ثانویه، می‌تواند منجر به کندی یا قطع همگام‌سازی و در نتیجه غیرفعال شدن اتصال شود.
* **مسدود شدن و بن‌بست‌های تراکنشی (Blocking and Deadlocks):**
* تراکنش‌های طولانی‌مدت یا بن‌بست‌های شدید بر روی رپلیکای اصلی می‌توانند باعث ایجاد گلوگاه شوند و از ارسال سریع تغییرات به رپلیکاهای ثانویه جلوگیری کنند. این تأخیر می‌تواند در نهایت به قطع ارتباط منجر شود.
* **مشکلات سرویس SQL Server (SQL Server Service Issues):**
* اگر سرویس SQL Server روی رپلیکای اصلی یا ثانویه متوقف، راه‌اندازی مجدد یا دچار مشکل شود، ارتباط Always On نیز قطع خواهد شد.
* **پیکربندی نادرست Always On (Incorrect Always On Configuration):**
* **EndPoints:** عدم پیکربندی صحیح Endpoints (مانند عدم تخصیص مجوز CONNECT برای حساب سرویس SQL Server به Endpoint Always On) یا فعال نبودن Endpoint می‌تواند باعث مشکل شود.
* **Listener:** مشکلات در Listener Name (نام شنونده) یا IP Address آن نیز می‌تواند بر ارتباطات تأثیر بگذارد.
* **اشکالات سیستم عامل (Operating System Issues):**
* مشکلات در سطح سیستم عامل، مانند به‌روزرسانی‌های ناگهانی، راه‌اندازی مجدد سرور بدون اطلاع قبلی، یا خطاهای هسته سیستم عامل می‌تواند منجر به قطع ارتباط Always On شود.
* **رشد نامتعارف Transaction Log (Excessive Transaction Log Growth):**
* اگر فایل لاگ تراکنش (Transaction Log) روی رپلیکای اصلی به سرعت رشد کند و مدیریت نشود، می‌تواند باعث افزایش فشار I/O و کندی عملکرد SQL Server شود که در نهایت بر همگام‌سازی تأثیر می‌گذارد.
* **حجم کاری بالا (Heavy Workload):**
* حجم بالای عملیات نوشتن در رپلیکای اصلی که رپلیکاهای ثانویه قادر به پردازش و همگام‌سازی آن با سرعت کافی نباشند، به خصوص در صورت کمبود منابع در رپلیکای ثانویه، می‌تواند منجر به عقب‌ماندگی و سپس قطع اتصال شود.
شناسایی دقیق عامل اصلی از طریق بررسی دقیق لاگ‌های خطا، مانیتورینگ منابع و ابزارهای عیب‌یابی شبکه، کلید حل مشکل خطای 35206 SQL Server است.
راهکارهای رفع خطای 35206 SQL Server (گام به گام)
رفع خطای 35206 SQL Server نیازمند رویکردی سیستماتیک و مرحله‌ای است. در اینجا، گام‌های عملی برای عیب‌یابی و حل مشکل “Connection to primary replica is not active” ارائه می‌شود:
1. بررسی وضعیت Always On Availability Group در SSMS
اولین گام، بررسی وضعیت کلی Availability Group از طریق SQL Server Management Studio (SSMS) است.
* **باز کردن Dashboard:** در SSMS، به قسمت AlwaysOn High Availability بروید، Availability Groups را گسترش دهید، بر روی نام AG خود راست کلیک کنید و گزینه “Show Dashboard” را انتخاب کنید.
* **تجزیه و تحلیل Dashboard:** Dashboard اطلاعات مهمی در مورد سلامت هر رپلیکا و وضعیت همگام‌سازی آنها نشان می‌دهد. به ستون‌های “Connection State” و “Synchronization Health” توجه کنید. اگر “Connection State” برای رپلیکای ثانویه “Disconnected” یا “Not Connected” باشد، این همان مشکلی است که به دنبال حل آن هستیم. همچنین، “Synchronization Health” ممکن است “Not Healthy” یا “Resolving” باشد. این ابزار دید کلی از وضعیت AG به شما می‌دهد.
2. بررسی SQL Server Error Log
لاگ خطای SQL Server منبعی غنی از اطلاعات تشخیصی است.
* **موقعیت لاگ:** این لاگ را هم در رپلیکای اصلی و هم در رپلیکای ثانویه بررسی کنید.
* **جستجوی کلیدواژه‌ها:** به دنبال خطای 35206 و هرگونه پیام خطای دیگر مرتبط با Always On، شبکه، یا Endpoints باشید. به خصوص به زمان دقیق وقوع خطا و پیام‌های قبل و بعد از آن دقت کنید. این لاگ‌ها اغلب سرنخ‌های مستقیمی در مورد علت اصلی مشکل ارائه می‌دهند.
3. تست اتصال شبکه (Network Connectivity)
از آنجایی که مشکلات شبکه یکی از شایع‌ترین علل هستند، باید اتصال بین رپلیکاها را بررسی کنید.
* **پینگ (Ping):** ابتدا از دستور `ping` برای اطمینان از وجود ارتباط اولیه بین سرورهای رپلیکا استفاده کنید.
“`sql
ping YourSecondaryReplicaIP
“`
یا
“`sql
ping YourPrimaryReplicaIP
“`
اگر پینگ ناموفق بود، مشکل در لایه‌های پایین‌تر شبکه است.
* **Telnet یا Test-NetConnection:** سپس، اتصال پورت SQL Server Endpoint را تست کنید (معمولاً 5022).
“`sql
telnet YourPrimaryReplicaIP 5022
“`
یا (برای PowerShell)
“`sql
Test-NetConnection -ComputerName YourPrimaryReplicaName -Port 5022
“`
اگر `telnet` نتواند به پورت متصل شود یا `Test-NetConnection` وضعیت `TcpTestSucceeded` را False نشان دهد، احتمالاً فایروال (Windows Firewall یا فایروال شبکه) یا مشکل در Endpoint SQL Server مانع از اتصال است. اطمینان حاصل کنید که پورت 5022 (یا پورت دیگری که برای Endpoint Always On پیکربندی کرده‌اید) در هر دو جهت (ورودی و خروجی) در فایروال‌های محلی سرورها و فایروال‌های شبکه باز است.
4. بررسی فشار منابع سرور (Resource Pressure)
مصرف بالای منابع (CPU, RAM, Disk I/O) می‌تواند ارتباطات را مختل کند.
* **مانیتورینگ عملکرد (Performance Monitor/Perfmon):** از ابزارهای مانیتورینگ برای بررسی مصرف CPU، حافظه، و دیسک I/O در هر دو رپلیکای اصلی و ثانویه استفاده کنید. به خصوص به Counterهای مربوط به SQL Server، مانند “SQLServer:Buffer Manager\Page life expectancy” (PLR) و “SQLServer:SQL Statistics\Batch Requests/sec” توجه کنید.
* **DMV های SQL Server:** از Dynamic Management Views (DMVs) برای شناساییquery های با مصرف منابع بالا یا Wait Stats (آمار انتظار) استفاده کنید.
برای بررسی query های با مصرف CPU بالا:
SELECT TOP 10 total_worker_time/1000 AS [CPU Time (ms)],
total_elapsed_time/1000 AS [Elapsed Time (ms)],
reads, writes, logical_reads,
sql_handle, statement_start_offset, statement_end_offset,
plan_handle, query_plan
FROM sys.dm_exec_query_stats
ORDER BY [CPU Time (ms)] DESC;
GO
این کوئری لیستی از 10 کوئری برتر را بر اساس زمان CPU مصرفی نشان می‌دهد، که به شما کمک می‌کند کارهایی که باعث افزایش بار CPU می‌شوند را شناسایی کنید.
برای بررسی Wait Stats و شناسایی گلوگاه‌ها:
SELECT wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms,
CASE
WHEN waiting_tasks_count > 0 THEN (wait_time_ms * 1.0 / waiting_tasks_count)
ELSE 0
END AS avg_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN
('BROKER_RECEIVE_WAITFOR', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'SQLTRACE_BUFFER_FLUSH',
'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'ONDEMAND_TASK_QUEUE',
'CHECKPOINT_QUEUE', 'DIRTY_PAGE_POLL', 'HADR_FILESTREAM_REQUEST', 'SP_SERVER_DIAGNOSTICS_SLEEP')
ORDER BY wait_time_ms DESC;
GO
این کوئری آمار انتظار SQL Server را نشان می‌دهد. Wait Type هایی مانند `PAGELATCH_EX`, `LCK_M_X`, `WRITELOG`, `IO_COMPLETION`, `NETWORK_IO` می‌توانند نشان‌دهنده مشکلات دیسک، قفل‌ها یا شبکه باشند.
5. بررسی و رفع مشکلات Endpoints Always On
Endpoints نقاط ارتباطی SQL Server برای Always On هستند و پیکربندی صحیح آنها حیاتی است.
* **وضعیت Endpoint:**
SELECT name, state_desc FROM sys.endpoints WHERE name = 'Hadr_endpoint';
GO
اطمینان حاصل کنید که `state_desc` برای Endpoint Always On (که معمولاً `Hadr_endpoint` نام دارد) روی `STARTED` تنظیم شده باشد. اگر نه، آن را با دستور `ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;` راه‌اندازی کنید.
* **مجوزهای Endpoint:** حساب سرویس SQL Server (و احتمالا اکانت‌های دیگر) باید مجوز `CONNECT` به Endpoint را داشته باشند.
SELECT sp.name AS [principal_name], sp.type_desc AS [principal_type],
perms.permission_name, perms.state_desc AS [permission_state]
FROM sys.server_principals sp
JOIN sys.server_permissions perms ON sp.principal_id = perms.grantee_principal_id
WHERE perms.class = 105 AND perms.major_id = (SELECT endpoint_id FROM sys.endpoints WHERE name = 'Hadr_endpoint')
AND perms.permission_name = 'CONNECT';
GO
اطمینان حاصل کنید که حساب سرویس SQL Server شما دارای مجوز `CONNECT` به `Hadr_endpoint` است. در صورت نیاز، مجوز را اضافه کنید:
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [YourDomain\SQLServiceAccount];
GO
حساب سرویس SQL Server در هر دو رپلیکا باید این مجوز را داشته باشد.
6. بررسی مشکلات Blocking و Deadlock
Blocking شدید می‌تواند مانع از همگام‌سازی شود.
* **شناسایی Blocking:** از DMV ها برای شناسایی session های مسدود شده استفاده کنید:
SELECT session_id, blocking_session_id, wait_type, wait_duration_ms, last_wait_type,
resource_description, command, percent_complete
FROM sys.dm_exec_requests
WHERE blocking_session_id 0;
GO
اگر تعداد زیادی session مسدود شده وجود دارد، باید query های اصلی را بهینه کنید یا به دنبال root cause blocking باشید.
7. مدیریت Transaction Log
رشد غیرقابل کنترل Transaction Log می‌تواند باعث مشکلات عملکردی شود.
* **اندازه لاگ:** بررسی کنید که فایل‌های لاگ تراکنش در رپلیکای اصلی و ثانویه چقدر بزرگ شده‌اند.
* **بررسی VLF ها (Virtual Log Files):**
DBCC LOGINFO;
GO
تعداد VLF های بسیار زیاد می‌تواند عملکرد Log Writer را کاهش دهد.
* **پشتیبان‌گیری از لاگ:** اطمینان حاصل کنید که پشتیبان‌گیری از لاگ تراکنش به صورت منظم انجام می‌شود تا فضای استفاده شده آزاد شود.
* **تنظیم Auto-growth:** تنظیمات auto-growth برای فایل‌های لاگ باید به گونه‌ای باشد که از رشد بیش از حد کوچک یا بیش از حد بزرگ جلوگیری کند.
8. راه‌اندازی مجدد سرویس SQL Server (با احتیاط)
در برخی موارد، راه‌اندازی مجدد سرویس SQL Server روی رپلیکای ثانویه (و در صورت لزوم رپلیکای اصلی) می‌تواند ارتباطات را بازنشانی کند. این کار باید با دقت انجام شود زیرا باعث قطع شدن سرویس می‌شود.
9. بررسی Windows Event Logs
Event Viewer در ویندوز می‌تواند خطاهای سیستمی مربوط به شبکه، دیسک یا خود SQL Server را نشان دهد. به خصوص به بخش‌های Application و System logs توجه کنید.
10. برنامه‌ریزی برای Maintenance و بهینه‌سازی
* **بازسازی و سازماندهی ایندکس‌ها:**fragmentation بالای ایندکس‌ها می‌تواند عملکرد I/O را کاهش دهد.
* **بهینه‌سازی Query ها:** query های غیربهینه که منابع زیادی مصرف می‌کنند، باید شناسایی و بهینه‌سازی شوند.
با پیگیری این گام‌ها به صورت منظم و دقیق، می‌توانید علت اصلی خطای 35206 SQL Server را شناسایی و آن را برطرف کنید، و به این ترتیب از پایداری و دسترسی بالای Always On Availability Groups خود اطمینان حاصل نمایید. در صورت لزوم، این مراحل را برای هر دو رپلیکای اصلی و ثانویه تکرار کنید تا هرگونه مشکل در هر دو طرف شناسایی و حل شود.
