完全復旧モデルが可用性グループの要件であるのはなぜですか？
すべての本番データベースは単純な復旧モデルで作成されており、RPOとRTOを完全に満たすため、非常に満足しています。
ここで、データベースにAG DRソリューションを実装したいと思います。完全復旧モデルが必須であることがわかりました。
私の質問はなぜですか？理論的には、AGまたはその他のSQL Server DRソリューション（ログ配布、DBミラーリング）が単純な復旧モデルで機能しない技術的な理由はありますか？
単純なリカバリでDRテクノロジーが許可されている場合、HAには意味がありません。トランザクションログは、ポイントインタイムリカバリのmustです。トランザクションログは、DRテクノロジーがLogshipped/mirroredデータベースで行われたトランザクションを再生するために使用するものであり、単純なリカバリではログバックアップができないため、単純なリカバリでHA/DRを構成することもできません。ミラーリングでは、トランザクションログブロックの変更がミラーサーバーに送信されます。ログ配布では、トランザクションログバックアップが送信されます。したがって、ミラーリング/ログシッピング/ AlwayONが機能する基本的な概念はトランザクションログであることがわかります。
トランザクションログはデータベースの最も重要な部分です。これは、データベースへのすべての変更がクラッシュ時に記述されることが保証されている唯一の場所です。単一のトランザクションのログレコードはLSNによってリンクされており、ほとんどタイムスタンプのようなものです。このタイムスタンプは、さまざまなトランザクションをリンクし、DRサーバーで再生するために内部的に使用されます。
DRテクノロジの主な目的は、データ損失をできる限り少なくすることです。これは、トランザクションログが構造的に一貫している場合にのみ達成できます。単純なリカバリでは、トランザクションがコミットするときにトランザクションログが切り捨てられます。つまり、情報は不要であり、古いトランザクションによって占有されていたスペースを使用して、新しいトランザクションを書き込むことができます。その場合、古い情報は失われます。どういうわけかそれを取得したい場合はできません。しかし、完全な回復ではそれを行うことができます。
これらのメソッドはトランザクションログに依存しているためです。トランザクションログ自体は、完全復旧モデルでのみ信頼できます。シンプルリカバリとフルリカバリの違いに関するヒントがいくつかあり、DRにとってフルリカバリが非常に重要である理由について、次のページ全体をお読みください。
単純なリカバリを使用する場合は、完全バックアップと差分バックアップを作成することによってのみDRを達成できます。その場合、ポイントインタイムリカバリが失われます。
大丈夫な場合もありますが、RPO/RTOがわからない場合や、データ損失の許容度、バックアップで使用されるディスク容量などが不明な場合もあります。 1日中、毎分、完全バックアップまたは差分バックアップを作成したい。ログのバックアップは、最適なRPOを達成するためのより速く、より簡単で、より信頼できる方法である傾向があり、私はほとんどの人がその理由ですでに完全復旧を使用していると思います。したがって、このモデルを利用するAlwaysOnおよびその他のテクノロジーの要件は、通常、障害や頭を悩ませるものではありません。しかし、それはが難しい要件であり、理由はどちらかと言えば無関係ですが、おそらく最も基本的な理由の1つは単純なリカバリ（または一括ログに記録されます）セカンダリに出荷されないトランザクションを実際に失い、不整合な状態のままにする可能性があります。
すべてがトレードオフです。トランザクションログに関して対処しなければならない問題が少ないため、多くの人々は単純な回復を好むと感じています（ただし、これらの問題が0に減少するのは神話です）。それは多くのことのようなものです。実際にディスク障害、人為的エラー、またはバックアップに戻る必要があるその他の障害が発生するまで、トレードオフは素晴らしい働きをします。完全復旧では、ログを積極的に管理する必要があります（そうしないと、ディスクを消費します）。障害が発生した場合は、いつでも特定の時点に到達できます。簡単に言うと、これはバックアップにまったく注意を払わないための非常に簡単なゲートウェイのようです。これは単なる意見であり、技術的な事実ではありませんが、非常に大きなサンプルサイズに基づいています。
完全復旧モデルのデータベースで次のクエリを実行するとします。
INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';
完全復旧モデルでは、SQL Serverはトランザクションログに挿入されたデータの表現を書き込みます。これにより、セカンダリデータベースのREDOスレッドがトランザクションログを読み取り、プライマリデータベースで発生したトランザクションをセカンダリデータベースに適用できます。これは、トランザクションログに書き込まれた「JOE SACK」と「SEAN GALLARDY」の一部の表現があるためにのみ可能です。
ここで、データベースの同じクエリをシンプルなリカバリモデルと私の挿入 最小限のログ記録に対応 で実行するとします。
INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';
この場合、SQL Serverは、トランザクションログに挿入されたデータの完全な表現を書き込まない場合があります。代わりに、ページIDまたはエクステントIDのみをログに記録します。この ブログ投稿 は有益です：
最小限のログでは、SQL Serverは個々の行をログに記録せず、ページとエクステントの割り当てのみをログに記録します。したがって、各ページが100行に収まる場合、1つのログレコードに対して100のログレコードを交換することになります。
SQL Serverが必要に応じてロールバックを実行するには、変更されたページIDまたはエクステントIDを知っていれば十分です。ただし、REDOライターがトランザクションをセカンダリデータベースに適用するには、情報が不十分です。プライマリデータベースとセカンダリデータベースはバイト単位のコピーである必要があるため、単純な復旧モデルはAGと互換性がありません。