STANDBYのログ配布されたセカンダリをAlwaysOnグループに参加させる際の問題
1つのデータベースが、災害復旧サイトでホストされている3つの異なるサーバーにログ配布される構成になっています。これらの3つの障害回復サーバーは、同じAlwaysOn可用性グループ（AG）に参加しています。
フェイルオーバーが発生した場合は、AGのプライマリレプリカとして機能するサーバー上のデータベースを回復し、[結合のみ]同期オプションを使用してデータベースをAGに追加します。セカンダリレプリカ上のデータベースは既に回復されていない状態にあるため、操作は成功し、AG全体でデータベースが同期されます。これは100％素晴らしいです。
新しい問題：データベースが読み取り可能な状態にない場合、監視ソフトウェアはそれを気に入らない。したがって、プライマリサイトにいて、災害復旧サイトのNORECOVERYセカンダリにログ配布している間、監視ソフトウェアは、セカンダリデータベースがダウンしていると判断するため（優先度の高いチケットを読み取ることができないため）、優先度の高いチケットを開きます。
セカンダリをNORECOVERYからSTANDBYに切り替えることでセカンダリを読み取り可能にすると、この問題は解決しますが、新しいセカンダリが作成されます。災害復旧サイトにフェイルオーバーし、データベースをAGに追加しようとすると（上記のとおり）、AGに正常に参加するにはセカンダリレプリカのデータベースがNORECOVERYである必要があるため、失敗します。
AGにデータベースを追加する前にこれらのデータベースをSTANDBYからNORECOVERYに切り替えると、AGに参加するためにセカンダリレプリカ上のデータベースが十分に復元されず、参加が失敗したというメッセージが表示されます。この時点で、プライマリレプリカ上のデータベースのトランザクションログバックアップを作成し、それをNORECOVERYを使用してセカンダリに適用すると、結合手順を正常に再開できます。
セカンダリをSTANDBYからNORECOVERYに変更すると、データベースが同期していないとエンジンが判断したように見えますが、私の人生では理由を理解できません。誰かアイデアはありますか？私が考えることができる唯一のことは、プライマリデータベース自体を回復する行為はそれらを同期から外すのに十分であったということですが、これが本当なら、セカンダリをNORECOVERYのままにして開始するだけの場合もそうではありません（私たちの元の計画のように）？
復元時WITH STANDBY SQL Serverは、コミットされていないトランザクションを元に戻す必要があります（関連するデータページは、指定した元に戻すファイルに書き込まれます）。 NORECOVERYオプションは、データベースがリカバリされた場合に発生する可能性のあるログの状態、または潜在的なロールバックの実行を考慮しません。 2つではDBの状態が異なるため、最終的なトランザクションログを再適用する必要がありますWITH NORECOVERY良好な状態にするため。 https://askmesql.blogspot.com/2011/01/log-shipping-norecovery-vs-standby-mode.html に、これに関する優れた記事があります。
監視ソフトウェアについては、特定のデータベース、またはAGのセットアップ中にインスタンスを一時的に除外して、これらの偽のアラートが表示されないようにすることをお勧めします。
問題の説明に基づくと、実際の問題は、使用しているSQL Serverレプリケーションソリューションではなく、監視ソフトウェアの構成にあります。監視ソフトウェアを変更/修正する方法を理解するか、それを破棄します。データベースのHA/DRの機能を変更して、監視ソフトウェアを "提供"することは絶対にしないでください。