セカンダリ読み取り専用データベースとしてのAlways On可用性グループ
私は、データウェアハウジング用のprod DBのセカンダリコピー、および他のプロセスのオフロードやレポート作成に使用できるもののセットアップに取り組んでいます。基本的には、読み取り専用の製品コピーです。問題は、ある時点でのバックアップ戦略を打ち破り、20 TBデータを確実に処理できるオプションです。
この投稿 を読んだ後、Always On可用性グループは有望に見えます。しかし、いくつか質問があります。DBAは初めてで、この件に関するMicrosoftのドキュメントのほとんどは、現時点では別の言語です。
- Always On可用性グループは、データベースが基本的にミラーリングされ、そのサーバーを使用して重いレポートをオフロードできることを意味しますか？
- そのブレークポイントインタイムのトランザクションログは本番サーバーのバックアップを記録していますか？
- これは本番サーバーに負担をかける可能性がありますか？
- これにより、prodトラフィックがこのサーバーにリダイレクトされますか？これをHA DBサーバーにしたくないのですが、いくつかの製品DBの読み取り専用コピーが欲しいだけです。
1. Always On可用性グループは、データベースが基本的にミラーリングされ、そのサーバーを使用して重いレポートをオフロードできることを意味しますか？
データベースの完全なコピーになります。ミラーリングされていると考えることもできますが、実際には同じではありません。
2.そのブレークポイントインタイムトランザクションログは製品サーバーのバックアップですか？
番号。
3.これにより、prodサーバーに負担がかかりますか？
かもしれない。これは、多くのレイテンシと利用可能な帯域幅、サーバーハードウェア、トランザクション負荷（およびスタイル）、コミットモードなどのさまざまな項目に依存します。非同期が必要なように聞こえますが、レイテンシ、やり直し、およびクエリの開始時期に依存するデータの鮮度について、特定の保証はありません。
4.これにより、prodトラフィックがこのサーバーにリダイレクトされますか？これをHA DBサーバーにしたくないのですが、いくつかの製品DBの読み取り専用コピーが欲しいだけです。
その場合、2017を実行しているか、2017にアップグレードできる場合は、クラスターが不要な 読み取りスケール可用性グループ があります。
セカンダリは読み取り専用として使用できます。データはほぼリアルタイムでセカンダリに追加されていることに注意してください。
トランザクションログのバックアップは、プライマリAGインスタンスに対して実行されます。
セカンダリがトランザクションの量に対応できない場合、プライマリのトランザクションログがいっぱいになり、増加し続ける可能性があります。
プライマリが使用できなくなった場合、トラフィックはセカンダリに転送されます。これが可用性グループのポイントです。
データベースのコピーでレポートを実行するだけの場合は、別のインスタンスへのログ配布の設定を検討する必要があります。 AGより安価でシンプルなソリューションです。