Always On可用性グループでの手動フェールオーバーのリスク
私の環境では、SQL 2014で、データベースのAlways On可用性グループが非同期であり、手動フェールオーバーが行われています。
1つのプライマリレプリカと2つのセカンダリレプリカ、secondary1とsec2があります。
プライマリからセカンダリへのフェイルオーバーを実行する必要があります1。強制フェイルオーバーであるため、一部のデータが失われることがわかっています。
私の質問：
- これには何が必要でしょうか？
- 忙しい時間帯でも、忙しい時間帯でもできますか？
- フェイルオーバー中にリスクはありますか？.
フェイルオーバーを初めて行うときの提案に感謝します。
テスト環境はありますか？そうでない場合は、$ 200の無料Azureクレジットを取得し、そこに環境を設定して（同じサービスパックレベル）、試してみてください。これは、自信を得てEdgeケースを見つけるための最良の方法の1つです。経験を除いて、好きな環境をテストすることに勝るものはありません。また、Microsoftの公式 support docs も確認してください。
ドキュメントごとに、次のようないくつかの項目を確認する必要があります。
セカンダリレプリカのフェールオーバーの準備状況を確認するには、sys.dm_hadr_database_cluster_states動的管理ビューのis_failover_ready列をクエリするか、Always On Groupダッシュボードの[Failover Readiness]列を確認します。
ただし、この質問に答えるために、AlwaysOnフェイルオーバーはサービスが両方のインスタンスで実行されており、リスナーが新しいホストを指すため、非常に高速です。ホストがマシンのIPではなくリスナーに接続していることを確認します。
したがって、テストして環境で適切に実行すると、繁忙時にFCI（フェールオーバークラスターインスタンス）よりもはるかに高速になります。 AlwaysOnはデータベースごとにのみ機能し、サーバーごとには機能しないため、新しいプライマリレプリカ、ユーザー、権限/ SIDでジョブが正しく設定されていることを確認する必要があります。データベースの同期を維持する必要がある場合は、確実に実行する必要があります。それはどういうわけか、もう一方ではなく一方をフェイルオーバーする前に。また、MSDTCをクロスデータベーストランザクションに使用する場合は、同じインスタンス内でクロスDBトランザクションを使用する多くの場合に修復不可能なデータ破損を引き起こす可能性があるため、非常に注意する必要があります。
おそらく、ショーンがあなたのスレッドを見れば、直面する可能性のある問題の多くを提供できるでしょう。
同期されていないセカンダリレプリカにフェイルオーバーすると、データが失われます。失われたデータの量は、その分にどれだけの待ち時間があるかによって異なります。データの損失は保証されていません-その可能性だけです。たとえば、データベースがアイドル状態の場合、非同期セカンダリレプリカmightは同期しているため、データが失われることはありません。
AGデータベースのいずれかにデータの損失がある場合（そうです、AGの一部のDBでのみデータの損失が発生する可能性があります）、それらのデータベースは、データの損失を伴うフェイルオーバー後にレプリカ間のデータ移動を再開できません。データの移動を再開するには、これらのデータベースを破棄してAGに再初期化する必要があります。
計画的なフェイルオーバーを行う場合は、次の手順を実行するだけです。
- セカンダリレプリカを同期に切り替える
- データ移動が追いつくのを待つ
- データ損失ゼロでフェイルオーバー
- 非同期モードに切り替えます
Derik Hammerは、PowerShellを使用してこのプロセスを実行（および自動化）するブログを公開しています。 http://www.sqlhammer.com/availability-group-fail-over-test-with-powershell/
可用性グループの強制的な手動フェールオーバーの実行に関しては、いくつかの推奨事項があります。下記を参照してください。
プライマリレプリカの実行中にフェイルオーバーを強制しないでください。フェイルオーバーを強制する前に、クライアントが元のプライマリレプリカにアクセスできないようにすることを強くお勧めします。それ以外の場合は、フェイルオーバーが強制された後、元のプライマリデータベースと現在のプライマリデータベースが互いに独立して更新される可能性があります。