مدیریت AlwaysOn Availability Groups

Failover

Failover می‌تواند Planned/Synchronous یا Forced/Asynchronous باشد. Planned Failover زمانی امن است که Secondary Synchronized باشد و Data Loss رخ ندهد. Failover خودکار فقط برای Replicaهای Synchronous با Automatic Failover و Health مناسب رخ می‌دهد.

Wizard Select New Primary Replica وضعیت Synchronization و Readiness را نشان می‌دهد. DBA باید مطمئن شود Replica هدف Synchronized است و Application/Jobهای Instance-level آماده‌اند.

ALTER AVAILABILITY GROUP [MyAG] FAILOVER;

این دستور روی Secondary هدف اجرا می‌شود و Planned Failover را آغاز می‌کند. Connect to Replica در Wizard Credential/Connection لازم را فراهم می‌کند.

Asynchronous / Forced Failover

ALTER AVAILABILITY GROUP [MyAG] FORCE_FAILOVER_ALLOW_DATA_LOSS;

Forced Failover فقط در Disaster و وقتی Primary در دسترس نیست استفاده می‌شود. عبارت ALLOW_DATA_LOSS واقعی است: Log Blockهای Send نشده ممکن است از بین بروند.

برای کاهش خطا در Forced Failover، کتاب Scriptی برای Safe-state کردن Application Databaseها، بررسی Replica State و آماده‌سازی عملیات Failover می‌سازد. Automation باید حالت‌های Failure را نیز Handle کند.

پس از Failover، Databaseهای جدید Primary ممکن است نیاز به Resume یا Rejoin Replicaهای قبلی داشته باشند. Application باید با Listener دوباره Connect شود و Orphan Transaction/Queueها بررسی شوند.

Synchronizing Uncontained Objects

AG فقط User Database را Sync می‌کند. Login، SQL Agent Job، Credential، Linked Server، Server-level Certificate و سایر Objectهای Instance باید جداگانه Synchronize شوند. SID Loginها باید روی Replicaها یکسان باشد تا Userها Orphan نشوند.

Monitoring

Monitoring شامل Replica Role، Connected State، Synchronization State/Health، Log Send Queue، Redo Queue و Last Hardened/Commit Time است. Dashboard و DMVهای HADR منابع اصلی‌اند.

AlwaysOn Dashboard Database/Replica Health را به‌صورت رنگی نمایش می‌دهد. SYNCHRONIZED، SYNCHRONIZING، NOT SYNCHRONIZING و REVERTING از Stateهای مهم‌اند. State باید همراه با Queue Size و Throughput تفسیر شود.

Cluster Quorum Information در Dashboard امکان مشاهده Node/Quorum/Witness را می‌دهد. مشکل Cluster می‌تواند حتی با Database Sync سالم Failover را مختل کند.

AlwaysOn Health Extended Events

AlwaysOn Health Session Eventهایی درباره Role Change، Lease Timeout، Data Movement و Errorهای HADR ثبت می‌کند. Target Data در SSMS برای Root Cause Analysis Failover مفید است.

Administrative Operations

ALTER AVAILABILITY GROUP [MyAG] REMOVE DATABASE [AppDB];
ALTER DATABASE [AppDB] SET HADR SUSPEND;
ALTER DATABASE [AppDB] SET HADR RESUME;

Suspend کردن Data Movement روی Primary باعث رشد Log Send Queue/عدم Truncation مرتبط می‌شود. عملیات طولانی باید مانیتور شود.

جمع‌بندی

AG علاوه بر Configuration اولیه به عملیات روزانه نیاز دارد: Failover Test، Synchronization Objectهای Instance، Backup Preference، Monitoring Queue و Patch/Upgrade.

Maintenance مانند CHECKDB، Index Rebuild و Backup باید آگاه از Replica Role باشد. Readable Secondary می‌تواند بخشی از بار Read/Backup را منتقل کند، اما Log Transport/Redo و Long-running Transactionهای Secondary نیز باید در Capacity Planning لحاظ شوند.