و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
در دنیای امروز که دادهها به قلب تپندهی سازمانها تبدیل شدهاند، دسترسپذیری بالا (High Availability) دیگر یک گزینهی لوکس نیست؛ بلکه ضرورتی حیاتی برای بقا و اعتبار هر کسبوکار است. SQL Server در طول سالها با ارائه قابلیتهایی همچون Failover Cluster Instance (FCI)، Always On Availability Groups (AG) و Database Mirroring، مسیر پایداری را هموار کرده است.
اما در میان این معماریهای پیشرفته، خطری پنهان وجود دارد که در صورت وقوع، میتواند ثانیهای کل زیرساخت داده را به آشوب بکشاند: Split Brain.
Split Brain یا «دوگانگی مغز» وضعیتی است که در آن دو یا چند نود از کلاستر به اشتباه گمان میکنند نود اصلی (Primary) هستند و همزمان اقدام به نوشتن در پایگاه داده میکنند. نتیجه؟ ناسازگاری داده، از بین رفتن تراکنشها و در نهایت، نیاز به بازیابی دستی.
در این مقاله از لاندا، بهصورت تخصصی بررسی میکنیم که دوگانگی مغز دقیقاً چیست، چرا رخ میدهد، چگونه میتوان آن را تشخیص داد، از آن جلوگیری کرد و در صورت وقوع، چگونه بهصورت ایمن آن را مدیریت کرد.
Split Brain چیست و چرا خطرناک است؟
Split Brain زمانی رخ میدهد که مکانیزم Quorum در کلاستر دچار اختلال شود. Quorum در واقع سیستمی است که تصمیم میگیرد کدام نودها «دارای رأی معتبر» برای ادامه فعالیت هستند. وقتی ارتباط بین نودها یا بین نود و Witness از بین برود، هر طرف ممکن است خود را همچنان فعال فرض کند و دادهها را تغییر دهد. این اتفاق به معنای از بین رفتن Consistency و نقض اصل ACID در تراکنشهای SQL Server است.
مثال ساده
فرض کنید دو نود A و B در Always On Availability Group دارید. به دلیل قطع شبکه، هر نود تصور میکند دیگری از کار افتاده و خودش را Primary میداند. اکنون کاربران هر دو نود دادههایی را تغییر میدهند. وقتی ارتباط مجدداً برقرار میشود، سیستم نمیتواند تصمیم بگیرد کدام نسخه از دادهها صحیح است — این دقیقاً همان Split Brain است.
Split Brain در معماریهای مختلف SQL Server
۱. در Always On Availability Groups
در SQL Server 2019 به بعد، AGها بر پایه Windows Server Failover Clustering (WSFC) کار میکنند. اگر ارتباط بین Replicaها قطع شود اما هر دو به نظر خودشان «درست» باشند، ممکن است هر دو بهعنوان Primary عمل کنند.
در نسخههای جدیدتر (SQL Server 2022 + Windows Server 2025)، مکانیزم Lease Timeout و Cluster Heartbeat بهبود یافته است تا جلوی Split Brain گرفته شود. با این حال، در شرایطی مثل تأخیر شدید شبکه یا خطای تنظیم Quorum، همچنان احتمال وقوع وجود دارد.
۲. Failover Cluster Instance (FCI)
در FCI، چون از Shared Storage استفاده میشود، Split Brain کمتر رخ میدهد، اما ممکن است در اثر استفادهی همزمان دو نود از دیسک مشترک یا خرابی Disk Arbitration چنین وضعیتی پیش آید. در این حالت هر نود بهطور همزمان سعی در نوشتن در LUN مشترک دارد که میتواند منجر به تخریب کامل فایلهای MDF و LDF شود.
۳. Database Mirroring و Log Shipping
در Mirroring، اگر Witness و Network دچار قطعی شوند، هر دو طرف ممکن است تصور کنند Primary هستند. در Log Shipping نیز اگر Jobهای Copy و Restore با تأخیر زیاد اجرا شوند، ناسازگاری دادهها قابل مشاهده خواهد بود — هرچند Split Brain به معنای واقعی در این مدل به ندرت رخ میدهد.
علتهای اصلی وقوع Split Brain
- قطع ارتباط شبکه بین نودها (Network Partitioning)
- پیکربندی اشتباه Quorum یا Witness
- خرابی یا تأخیر در Heartbeat
- Failover ناهماهنگ بین Replicaها
- خطای مدیریتی در اجرای دستی Failover
- تغییرات همزمان در تنظیمات کلاستر یا AG Listener
روشهای تشخیص
۱. بررسی لاگهای Windows و SQL Server
در Event Viewer، رخدادهایی با شناسههایی مانند ۱۱۷۷، ۱۵۶۱، ۱۶۴۱ یا ۴۱۰۰۹ معمولاً نشانگر رفتار Split Brain هستند.
در SQL Error Log نیز پیامهایی نظیر
The lease between AG resource and WSFC has expired.
یا
A possible split-brain condition detected in cluster.
نشاندهنده وضعیت بحرانی است.
۲. استفاده از Dynamic Management Views
با اجرای دستورات DMV زیر میتوان وضعیت Replicaها را بررسی کرد:
SELECT replica_id, role_desc, connected_state_desc, synchronization_health_desc
FROM sys.dm_hadr_availability_replica_states;
در صورت مشاهده چند Replica با وضعیت PRIMARY, احتمال Split Brain بسیار زیاد است.
۳. مانیتورینگ Heartbeat
ابزارهایی مانند Failover Cluster Manager, PowerShell cmdlets و SQL Management Studio Dashboard قابلیت نمایش وضعیت Heartbeat بین نودها را دارند.
۴. مانیتورینگ خودکار با ابزارهای لاندا
لاندا با سیستم مانیتورینگ هوشمند خود، Split Brain را از طریق تحلیل رفتار AG Listener و متریکهای شبکه بهصورت Real-Time تشخیص میدهد و پیش از وقوع Failover ناهمزمان هشدار ارسال میکند.
راهکارهای پیشگیری از Split Brain
۱. تنظیم دقیق Quorum
در معماریهای دارای سه نود، استفاده از Node Majority + File Share Witness توصیه میشود. در سناریوهای دو نودی، استفاده از Cloud Witness (در Azure یا S3) باعث افزایش اطمینان میشود.
۲. استفاده از Preferred Owners و Failover Policies
در FCI، حتماً Ownerها را بهصورت محدود تعریف کنید تا در زمان ناپایداری، Failover غیرمجاز رخ ندهد.
۳. کنترل Timeoutها
پارامترهای LeaseTimeout, SameSubnetDelay و CrossSubnetDelay باید متناسب با سرعت شبکه تنظیم شوند. تأخیرهای زیاد بدون تنظیم مناسب میتواند منجر به Split Brain شود.
۴. استفاده از شبکههای Redundant
در HA محیطهای حساس (مثلاً بانکها یا بیمارستانها)، استفاده از دو مسیر مستقل شبکه (Primary و Backup) حیاتی است.
۵. مانیتورینگ مداوم و تست دورهای
بهترین روش پیشگیری، مانیتورینگ پیشگیرانه و تست دستی Failover در محیط آزمایشی است تا نقاط ضعف شناسایی شوند.
روشهای بازیابی و رفع Split Brain
۱. ایزوله کردن نودها
اولین گام در هنگام وقوع Split Brain، قطع ارتباط یکی از نودهای Primary و جلوگیری از دسترسی کاربران است.
۲. بررسی Log Chain
از طریق دستورات زیر میتوان تفاوت لاگها را تحلیل کرد:
DBCC CHECKDB;
RESTORE HEADERONLY;
RESTORE FILELISTONLY;
سپس با RESTORE WITH NORECOVERY، میتوان نود ثانویه را مجدداً همگام کرد.
۳. انتخاب نسخه صحیح داده
در صورت تضاد، نسخهای که بیشترین تراکنش معتبر را دارد (از طریق LSN بررسی شود) بهعنوان نسخه اصلی انتخاب میشود.
۴. بازسازی Replica
پس از هماهنگی داده، Replicaهای جدید ساخته شده و مجدداً به AG اضافه میشوند.
۵. بررسی Root Cause
در پایان، حتماً باید علت اصلی (مانند خطای شبکه، Witness، یا پیکربندی) مشخص و اصلاح شود.
مانیتورینگ Split Brain در سال ۲۰۲۵
ابزارهای جدید مایکروسافت مانند Azure Arc for SQL Server و Microsoft Fabric Data Activator امکان تشخیص خودکار رفتارهای غیرطبیعی در HA را فراهم کردهاند. اما همچنان مانیتورینگ اختصاصی و هوشمند با رویکرد پیشگیرانه، مانند آنچه لاندا در سرویسهای DBA خود پیاده کرده نقش کلیدی دارد.
در لاندا، دادههای حیاتی از طریق Real-Time Telemetry و Behavioral Analytics پایش میشوند و با استفاده از الگوریتمهای مبتنی بر یادگیری ماشین، احتمال Split Brain در سطوح مختلف (Network، Replica و Cluster Layer) پیشبینی میشود.
نتیجهگیری
Split Brain یکی از خطرناکترین و در عین حال پنهانترین تهدیدها برای زیرساختهای High Availability در SQL Server است. با وجود پیشرفتهای فنی در نسخههای جدید (SQL Server 2022 و Windows Server 2025)، همچنان عامل انسانی، تنظیمات اشتباه و ضعف شبکه میتواند منجر به وقوع این بحران شود. مدیریت صحیح Quorum، مانیتورینگ مداوم و طراحی دقیق معماری، کلید جلوگیری از Split Brain هستند. در نهایت، بهترین راهکار، ترکیب تجربه DBAهای خبره با ابزارهای مانیتورینگ هوشمند است؛ همان چیزی که تیم لاندا با آن پایداری دادهها را تضمین میکند.
سوالات متداول (FAQ)
۱. آیا Split Brain فقط در Always On رخ میدهد؟
خیر، هر ساختار HA که از Quorum یا ارتباط بین نودها استفاده کند (از جمله FCI و Mirroring) ممکن است در شرایط خاص دچار Split Brain شود.
۲. آیا SQL Server خودش Split Brain را تشخیص میدهد؟
در نسخههای جدید، WSFC میتواند از طریق Lease Mechanism Split Brain را شناسایی کند، اما رفع آن همچنان نیازمند مداخله DBA است.
۳. آیا استفاده از Cloud Witness قطعاً مانع Split Brain میشود؟
خیر، ولی احتمال آن را بهشدت کاهش میدهد، بهویژه در محیطهایی با دو نود اصلی.
۴. در صورت وقوع Split Brain چه کاری نکنیم؟
هرگز نودها را همزمان آنلاین نکنید یا بهصورت دستی نقش Primary را تغییر ندهید؛ ابتدا باید یکی از نودها ایزوله شود.
۵. آیا مانیتورینگ شبکه میتواند Split Brain را پیشبینی کند؟
بله، سیستمهای هوشمند مثل مانیتورینگ لاندا با تحلیل الگوی تأخیر و Heartbeat قادر به پیشبینی رفتار دوگانگی مغز پیش از وقوع هستند.
خدمات مانیتورینگ و DBA لاندا
اگر زیرساخت SQL Server شما بخشی حیاتی از کسبوکارتان است، زمان آن رسیده از وقوع Split Brain و خطاهای HA پیشگیری کنید. تیم DBA و مانیتورینگ لاندا با بهرهگیری از فناوریهای هوشمند، شبکه، Quorum و Replicaهای شما را بهصورت ۲۴/۷ پایش میکند و پیش از وقوع بحران، هشدار دقیق ارسال میکند.
برای مشاوره تخصصی یا استقرار سیستم مانیتورینگ اختصاصی با لاندا تماس ✆ بگیرید.
نظری داده نشده